Comments
Sort by recent activity
Hi DonMan,
The installer works with the Microsoft clustering service to determine the shared drive assigned to the chosen SQL instance. Since you're using a different clustering provider (I'm not familiar with PolyServe) I expect the installer chose the default path and overwrote any existing datapath value. However, if the key already exists its value could be respected.
I've raised your scenario as a bug, with the intent that future versions of the installer will not initialise the datapath if an existing value can be found.
I'm sorry to hear that you had this problem with the upgrade. Thanks for reporting this.
Regards, / comments
Hi DonMan,
The installer works with the Microsoft clustering service to determine the shared drive assigned to the chosen SQL instance. Since you're using a different clustering provider (I'm not f...
Hi astreet,
For the backup job step, FILEOPTIONS 3 should have the same effect as FILEOPTIONS 1 on the COPYTO directory. I have raised this as a bug and will look into this.
However, if you created the log shipping jobs via the GUI then the restore job step will contain a MOVETO command, which takes processed files and moves them to another directory out of reach of the backup job's erase files functionality.
As a temporary workaround you can create an additional job step to perform the file purge. The following syntax may be of use:
EXEC master..sqbutility 1032, <database name>, <path>, <backup type>, <retention value>, <password>, @count OUT, @error OUT
where
<path> is the list of paths to delete files from. Multiple paths should be separated by |
<backup type> is either D (full), I (differential) or L (log)
<retention value> is as per ERASEFILES syntax i.e. a numerical value indicates days to keep, 2h = 2 hours, 2b = 2 backup sets @count is the number of files deleted @error is the error message (if any)
E.g. syntax:
DECLARE @count int
DECLARE @error varchar(1024)
EXEC master..sqbutility 1032, 'pubs', 'e:\temp\test', 'D', '5b', 'turtwig', @count OUT, @error OUT
SELECT @count, @error
NOTE: Even though the backup sets may not be encrypted, if you want the @count and @error return values, you must pass an empty string for the password parameter.
/ comments
Hi astreet,
For the backup job step, FILEOPTIONS 3 should have the same effect as FILEOPTIONS 1 on the COPYTO directory. I have raised this as a bug and will look into this.
However, if you created...
Thanks for pointing this out - I'll try to reproduce and fix this in the next release. Edit: Fixed in 6.4. / comments
Thanks for pointing this out - I'll try to reproduce and fix this in the next release. Edit: Fixed in 6.4.
Hi,
Some of the extended stored procedures are for use by the UI and would not be directly useful. For example, the procedures containing the word 'test' are called by the compression analyser utility.
Although they can be handy for support purposes I don't think they'll be fully detailed in the documentation.
For reference: sqbdir : a file browser interface, e.g. sqbdir 'C:\' would return the contents of the C drive. Permissions used are those of the user logged into SQL Server. This is used by the UI for browsing the remote server over a SQL connection. sqbdata : SQL access to the activity history database. sqbutility : miscellaneous functions (some in documentation) such as error dumping, manual invocation of 'delete old backups' routine.
Regards,
Robin Edit: looks like Linda beat me to it! / comments
Hi,
Some of the extended stored procedures are for use by the UI and would not be directly useful. For example, the procedures containing the word 'test' are called by the compression analyser util...
Hi SQL_GUY,
You can use the 'install to all nodes' feature and ignore the fact that it will attempt to install the service on the remaining node (installation on non-SQL nodes will fail if there is not a similarly named SQL instance present - but this shouldn't be a concern). This way, you'll get the benefit of the installer configuring the SQL Backup cluster resource entry. The cluster resource group will already be set previously (either by yourself or the SQL Server installer) to exclude the remaining node as a potential host for the contained resources.
If you would prefer more control over the installation then please copy SQBServerSetup.exe to the active SQL handling node and install without 'install to all nodes' selected and follow as per the help file. Care should be taken to ensure that SQL Backup's data and log files are located on the SQL Server shared drive (you'll be prompted by the install wizard to confirm the location of these files).
Regards, / comments
Hi SQL_GUY,
You can use the 'install to all nodes' feature and ignore the fact that it will attempt to install the service on the remaining node (installation on non-SQL nodes will fail if there is...
The SQL Backup agent must be running on the same host as the instance of SQL Server it's responsible for.
Because of this dependency, it naturally makes sense to keep it in the same group as SQL Server.
Hope this helps, / comments
The SQL Backup agent must be running on the same host as the instance of SQL Server it's responsible for.
Because of this dependency, it naturally makes sense to keep it in the same group as SQL Se...
I should add that any clustered service will be monitored by the clustering service which will automatically try to restart it if it's seen to have failed. To prevent this and turn off such a service you have to do it from cluster failover manager (right click the SQL Backup resource and click 'take offline').
The issue with the red 'X' is being looked at (this glitch has been seen to occur on very new / fast computers). / comments
I should add that any clustered service will be monitored by the clustering service which will automatically try to restart it if it's seen to have failed. To prevent this and turn off such a servi...
Hi,
On a cluster the data.sdf will be on the shared disk resource. It's exact location is referenced by
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Red Gate\SQL Backup\BackupSettingsGlobal\[INSTANCE]
(on a 32-bit machine, remove "Wow6432Node\").
As per your email, the relevant MSDB table names are:
msdb.dbo.backupfile
msdb.dbo.backupfilegroup
msdb.dbo.backupmediafamily
msdb.dbo.backupmediaset
msdb.dbo.backupset
msdb.dbo.restorefile
msdb.dbo.restorefilegroup
msdb.dbo.restorehistory
Regards, / comments
Hi,
On a cluster the data.sdf will be on the shared disk resource. It's exact location is referenced by
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Red Gate\SQL Backup\BackupSettingsGlobal\[INSTANCE]
(...
Hi,
What was the message given to you when you tried to alter the file? If it's a lock, the Process Explorer application linked above should tell you what's currently locking the file. You can then decide to either terminate that process or if possible work around as best you know (i.e. if it's anti virus, configure to leave data.sdf alone).
Regards, / comments
Hi,
What was the message given to you when you tried to alter the file? If it's a lock, the Process Explorer application linked above should tell you what's currently locking the file. You can then...
Hi,
I received your email this morning depicting the grey bars. These represent backup or restore operations that are too close together in time to represent with the current scale. If you zoom in far enough, they should eventually resolve into one or more green, blue or red coloured markers as appropriate. E.g. [image] [image]
I suspect that the UI is functioning correctly and it is the server-side data store that is problematically returning additional, erroneous activity history. If two operations are reported as happening at the same time, then naturally no amount of zooming will reveal the contents of the greyed operations.
SQL Backup also inspects SQL Server's backup history tables (e.g. msdb.dbo.backupfile, ...restorefile, etc) which, for whatever reason, may contain entries SQB is not familiar with.
If you could email or link me a compressed backup of your msdb and a copy of the data.sdf from one of your servers this might allow me to set up an instance that displays the same problems you're experiencing.
To temporarily alleviate the problem, you can purge the history by deleting the following (in order). This should not interfere with log shipping.
1) the contents of the five backup related tables and three restore related tables in MSDB
2) the data.sdf (whilst the SQB service is not running)
3) the local cache on any workstations with the UI installed
Regards, / comments
Hi,
I received your email this morning depicting the grey bars. These represent backup or restore operations that are too close together in time to represent with the current scale. If you zoom in ...