6.3 always asks to upgrade cache, & wipes all server History
PDinCA
Posts: 642 Silver 1
Running 6.3.0.48 on Windows 7 against SS2008 SP1 under WS2008 and SS2008 under WS2003 and SS2000 under WS2003.
Each time I fire up the UI, I get the request to upgrade the cache, which I do.
When the UI presents the servers, there is absolutely NO History for any of the servers.
I know that the Jobs are running as I'm monitoring each server with SQL Response and one job just failed, but that's not visible via SQL Backup, but is visible in the JOB History via SSMS.
This is a brand new W7 install, thereby a fresh install of SQL Backup, having added 2 Groups and the relevant Production and Development servers to each (3 Prod, 3 Dev for now).
What's up?
Each time I fire up the UI, I get the request to upgrade the cache, which I do.
When the UI presents the servers, there is absolutely NO History for any of the servers.
I know that the Jobs are running as I'm monitoring each server with SQL Response and one job just failed, but that's not visible via SQL Backup, but is visible in the JOB History via SSMS.
This is a brand new W7 install, thereby a fresh install of SQL Backup, having added 2 Groups and the relevant Production and Development servers to each (3 Prod, 3 Dev for now).
What's up?
Jesus Christ: Lunatic, liar or Lord?
Decide wisely...
Decide wisely...
Comments
The first thing I'd do is have a look to see if anything is happening to those files via Process Explorer's handle search or a similar tool.
Regards,
Development
Red-Gate Software
I am concerned that SQL Backup should have issues every time I use it. I only have Microsoft's Security Essentials running, alongside Windows Defender. I do not have Symantec's products, like I had when this box was an XP Pro machine. I have excluded C:\Users\<<user>>\AppData\Local\Red Gate\ and the child \SQL Backup folder from monitoring by Essentials.
These actions have had no effect at all.
On firing up SQL Backup, again, I chose "Later" on the latest invoke of the UI and now have 1.dat, 2.dat, 3.dat and the localDataCache.dat files in the \Server Data folder. Within the UI:
1. Expanded the 64-bit Server node. It initially displayed the history in green with what appeared to be correct icon-heights (transaction log backup - short and green). NOTE: Correction - It appears that "History" presentation is "inconsistent", SQLB doesn't always "wipe server history". 2. The node automatically refreshed. Now the markers are full height, and grey, and each says I have 2 items that were successful against every database that should have activity. However, there were NOT 2 items, just ONE, and "grey" means "what?" 3. I closed the UI. 4. I opened the UI -
IT EXCEPTIONED!!!:THIS PRODUCT IS BROKEN!
"Process Explorer" is a black box to me. What EXACTLY is one supposed to do to "...see if anything is happening to those files via Process Explorer's handle search or a similar tool."?
Also, frequently, when I expand my Production Group, the 64-bit SQL Cluster shows a red-X, and I get:
System.NullReferenceException: Object reference not set to an instance of an object.
at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
at RedGate.Shared.SQL.Server.SQLServer.GetDatabasesEx(Boolean forceRefresh)
at RedGate.Shared.SQL.Server.SQLServer.GetDatabasesEx(String server, Boolean integratedSecurity, String username, String password, Boolean forceRefresh)
at RedGate.SQLBackup.Engine.Server.a()
at RedGate.SQLBackup.Engine.Server.RefreshDatabases()
at RedGate.SQLBackup.Engine.Server.RefreshServerInformation()
at RedGate.SQLBackup.Engine.Server.OpenConnection(Boolean updateData)
It appears to clean itself up almost immediately, but surely this is not correct behavior...
Decide wisely...
I'm sorry that you're experiencing all this. The second exception I presume is of the form that does terminate the application and instead appears in the error explanation popup if you click the red X? If this is the case, then an unexpected communication break between SQB and SQL Server occurred.
Since the other issue affects you more prominently, we should try to understand that first.
Process Explorer is a Microsoft Sysinternals tool that gives you an overview of the processes running on your computer. It acts as a sort of extreme version Task Manager and the feature I find most useful is its handle search. It does not require installation to run (it comes as just an .exe pretty much) and the handle search can be accessed by pressed CTRL-F. This pops up a search dialogue where you can enter a filename (such as localDataCache.dat, 1.dat etc.). In the results panel you'll see the full list of processes that currently have that file open, including internal windows processes like svchost.exe. If there are any processes other than SQL Backup accessing the local data store, then this might explain the undesirable behaviour.
Since, even with a fresh install, the UI pulls history from the remote SQL Backup Agent it might also be worth checking the validity of those records. The easy way to do that would be to install the UI on another workstation and seeing if it can display the backup history as expected. If it cannot, then we know that the backup history of one or more of your servers is not in a state that SQL Backup can currently handle. The data.sdf (SQB Agent's datastore) might be corrupted or have confusing entries. In this case, you should delete this store and try again.
As for the unexpected grey entries, could you please provide a screenshot?
Regards,
Development
Red-Gate Software
ftp://support.red-gate.com/utilities/Re ... aStore.zip
Second, I have also observed that sometimes, the console cannot connect to a server when it is first started, but this clears up when a refresh occurs. This happens when querying the server for database names, and for some strange reason a query result (most likely a database name) comes up blank:
SELECT name, cmptlevel, sid, status FROM dbo.sysdatabases ORDER BY name
To know for sure what value is missing, we would probably need to run a debugger against SQL Backup UI. I can tell you how if you're interested.
I copied the utility to the SQL cluster and invoked the .exe. NO instances were listed, which is concerning as there definitely is a Production SS2008 instance on the box. I overtyped the instance area with (local) and hit Verify:
I'm obviously doing something wrong! The cluster is 64-bit BTW.
Decide wisely...
The Exception I copied re the failure to open the database file DOES result in a complete failure of the UI. Perhaps, rather than exception and die, the UI should "give an informational status area, perhaps in the UI's status area at the foot of the window, and retry the operation"??? To die like this is rather unfriendly in light of the problem being an "unexpected communication break" (to quote you), which we all experience from time to time... "Fix pending" perhaps?
Decide wisely...
Grey-full-height occurs on first and subsequent refreshes of an expanded Server - ANY server.
Decide wisely...
You can do the same things using SSMS if you have SQL Server 2005, but if you try to open the SDF as a SQL Compact database with SSMS2008, it will try to upgrade the data store and you don't want to do that!
If your tech squad would like to remote in, like last time, I'm happy to oblige...
Enjoy the weekend.
Decide wisely...
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.
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,
Development
Red-Gate Software
Decide wisely...
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,
Development
Red-Gate Software
Step 2 of your "temporary" solution is being blocked... I stopped the SQL Backup Agent and went to the C:\ProgramData\Red Gate\SQL Backup\Data\(LOCAL) folder to rename the data.sdf but was prevented. How does one free up the file as I'm stymied trying to access the Compact Edition in any way in an effort to, perhaps, run some DELETEs... Obvious lack of CE knowledge exhibited here :?
Decide wisely...
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,
Development
Red-Gate Software
DISABLING Restart means that any scheduled SQL Backup Job will CRASH! Is there opportunity here for a more friendly message, as in "The SQL Backup Service is not running on the Server, backups cannot be performed."...?
Anyway, the UI on the 64-bit cluster appears to be showing correct information now.
HOWEVER, the UI on my Windows7 box just barfed (a.k.a., DIED), again, despite my having deleted all local cache files just after I deleted them from the cluster: To be clear:
1. Followed each step of your "temporary" fix. 2. Step 3 was executed on the cluster, then on the W7 box. 3. The SQB Service was restarted. 4. The UI was started on the cluster, waited until activity occurred and verified the presentation was correct. 5. Closed all programs on the cluster for my session and logged off. 6. Opened the UI on my W7 box. 7. The "usual" red-X appeared on the cluster (the one I'd just successfully fixed). 8. The UI Exceptioned.
Decide wisely...
The issue with the red 'X' is being looked at (this glitch has been seen to occur on very new / fast computers).
Development
Red-Gate Software