Comments
Sort by recent activity
In case anyone is interested, this turned out to be a write permission problem -- not to the drive\folder where I was writing the backup file but to the folder where SQL Backup resides (yep -- C:\Program files (x86)\...). Once I allowed write permission there, the problem disappeared. I conjecture that there is some sort of log file written by a Full backup (remember that TLog backups were working fine). Go figure... / comments
In case anyone is interested, this turned out to be a write permission problem -- not to the drive\folder where I was writing the backup file but to the folder where SQL Backup resides (yep -- C:\P...
By the way, I checked the versions of the SQLVDI.dll (saw that mentioned as a possible problem elsewhere on the forum) -- there are 4 instances installed (two 32-bit, two 64). All are 2000.85.2312.0
Please help -- I have GOT to get a compressed backup made and SQL Backup is really letting me down.
thx -- john / comments
By the way, I checked the versions of the SQLVDI.dll (saw that mentioned as a possible problem elsewhere on the forum) -- there are 4 instances installed (two 32-bit, two 64). All are 2000.85.2312...
No problem -- it's a small thing; mostly I just wanted to be certain I wasn't doing anything stupid like running the same job twice... / comments
No problem -- it's a small thing; mostly I just wanted to be certain I wasn't doing anything stupid like running the same job twice...
So, you're saying that if a log file is corrupted, there is no way to salvage any of the data. The database cannot be taken out of the restoring state because it thinks a restore is in progress and there is nothing to do but delete the database. That's pretty drastic -- but ok. / comments
So, you're saying that if a log file is corrupted, there is no way to salvage any of the data. The database cannot be taken out of the restoring state because it thinks a restore is in progress an...
Thanks Matthew!!
Checking the SQL Backup Agent serivce LogOn account was what I needed. None of these machines are in a domain. I discovered that my test machine was running SQL Backup Agent under a specific username/password and the destination machine was using the same username/password (I guess I had figured this out some time ago when getting the test machine to work). As soon as I added the same login & password to my production machine and changed the SQL Backup Agent service on that machine to run under it, my problem went away.
Suggestion: you might consider a help popup for the Log Shipping Network Share test button that says something like "The SQL Backup Agent service must be running under the same account on both machines. If the machines are not in the same domain, SQL Backup Agent must be running under a local account with the same username and password on both machines."
Thanks again for pointing me to the right place!
john / comments
Thanks Matthew!!
Checking the SQL Backup Agent serivce LogOn account was what I needed. None of these machines are in a domain. I discovered that my test machine was running SQL Backup Agent unde...
thx for the reply. Yes, I know I can monitor manually every day or week. I have 75 large databases to keep track of and was hoping you guys had some better approach. It is surprisingly difficult to find out how fast a database is growing over time, let alone consolidating that across multiple databases and projecting so as to plan storage upgrades.
This would be a great opportunity for a new "Capacity Planning" product for RedGate. You could use the SQL Backup history to get the historical file growth but we also need to understand growth within the size allocated to the various filegroups. Idera is the only vendor I've found that advertises that feature (I have not tried it...yet).
As a long-time RedGate customer, I'll volunteer to share our workflows with the developers and be a beta if you decide to pursue this. / comments
thx for the reply. Yes, I know I can monitor manually every day or week. I have 75 large databases to keep track of and was hoping you guys had some better approach. It is surprisingly difficult...