Would it be possible for you to try uninstalling the server components for this instance, and then installing them afresh?
RE: Issue with Server Component registration v7.3.2.3
↧
↧
SQBCoreservice consuming 80 - 90% cpu
Hello - i did post this ealier but i think it went into the wrong section of the web site so apologies if your re-reading this/.
We use backup 7 to do nightly backups (1am) and we backup the transaction logs every 10 mins on certain databases.
When ever i get a cpu alert (resource can be anywhere between 80 -100%) i look at the most costly cpu proccess and it is always the SQBCoresercvice which is taking all of the cpu.
I have checked the log backups from the point in time where the cpu max's out using the msdb..backupset and the results returned dont show any exdroindary large transaction log backups - just the same size on average as the rest of the day.
We also have transactional replication - could this be the smoking gun ?
Users are starting to complain of unresponsive systems whilst this cpu is pegged at 80 - 100%
Any ideas ?
We use backup 7 to do nightly backups (1am) and we backup the transaction logs every 10 mins on certain databases.
When ever i get a cpu alert (resource can be anywhere between 80 -100%) i look at the most costly cpu proccess and it is always the SQBCoresercvice which is taking all of the cpu.
I have checked the log backups from the point in time where the cpu max's out using the msdb..backupset and the results returned dont show any exdroindary large transaction log backups - just the same size on average as the rest of the day.
We also have transactional replication - could this be the smoking gun ?
Users are starting to complain of unresponsive systems whilst this cpu is pegged at 80 - 100%
Any ideas ?
↧
RE: Issue with Server Component registration v7.3.2.3
Thanks Chris.
I can confirm that after re-installing the agent and updating it to use the correct account to run the service that the SQL Backup Pro UI now correctly shows in the properties as the "SQL Backup version" being '7.3.2.12'
Cheers
Joe
I can confirm that after re-installing the agent and updating it to use the correct account to run the service that the SQL Backup Pro UI now correctly shows in the properties as the "SQL Backup version" being '7.3.2.12'
Cheers
Joe
↧
RE: SQBCoreservice consuming 80 - 90% cpu
Could you please post the SQL Backup command(s) that you are using, that causes the CPU utilization to hit 80%-90%? Are there are scheduled SQL Backup processes that run simultaneously? Is there a specific interval where the backups cause the CPU utilization to max out, or does it happen with every transaction log backup?
Thanks.
Thanks.
↧
Full Text not observing MOVE on a RESTORE
Running into an issue when restoring a backup to an alternate server. This server contains multiple restores at any given time.
To get around file conflicts, we move files to appropriate places or names using the MOVE option. While restoring, everything appears okay, but once done, the files disappear and/or are moved one directory level higher, but with original naming (causing naming conflicts on other restores).
We did not see this issue with 6.4 version.
Trying this with 7.4 SQL Backup, Windows Server 2008 R2, SQL Server 2008 R2 SP1.
Here is command example generated by UI. Added some <CR> to make it easier to read:
EXECUTE master..sqlbackup
'-SQL "RESTORE DATABASE [sandbox_s4]
FROM DISK = ''\\BackupServer\DatabaseBackups\s4\FULL_s4_20130729_004816.sqb''
WITH PASSWORD = ''<password>'', RECOVERY,
MOVE ''db_Data'' TO ''C:\DBC1\I7\DATA\sandbox_s4.mdf'',
MOVE ''sysft_KBIndex'' TO ''C:\DBC1\I7\LOG\FullText\KBIndex_sandbox_s4'',
MOVE ''sysft_FieldValueIndex'' TO ''C:\DBC1\I7\LOG\FullText\FieldValueIndex_sandbox_s4'',
MOVE ''sysft_HistoryIndex'' TO ''C:\DBC1\I7\LOG\FullText\HistoryIndex_sandbox_s4'',
MOVE ''db_Log'' TO ''C:\DBC1\I7\LOG\sandbox_s4_log.ldf'', REPLACE, ORPHAN_CHECK"'
In this case, the sysft files are left as more generic names in the FullText directory and not within their respective MOVE directories.
For example, sysft_KBIndex would be expected to be contained in C:\DBC1\I7\LOG\FullText\KBIndex_sandbox_s4 with all it's related files, however, we instead see just this:
C:\DBC1\I7\LOG\FullText\ftrow_KBIndex.ndf
Tried adding a filename even to the MOVE command and that was ignored as well.
To get around file conflicts, we move files to appropriate places or names using the MOVE option. While restoring, everything appears okay, but once done, the files disappear and/or are moved one directory level higher, but with original naming (causing naming conflicts on other restores).
We did not see this issue with 6.4 version.
Trying this with 7.4 SQL Backup, Windows Server 2008 R2, SQL Server 2008 R2 SP1.
Here is command example generated by UI. Added some <CR> to make it easier to read:
EXECUTE master..sqlbackup
'-SQL "RESTORE DATABASE [sandbox_s4]
FROM DISK = ''\\BackupServer\DatabaseBackups\s4\FULL_s4_20130729_004816.sqb''
WITH PASSWORD = ''<password>'', RECOVERY,
MOVE ''db_Data'' TO ''C:\DBC1\I7\DATA\sandbox_s4.mdf'',
MOVE ''sysft_KBIndex'' TO ''C:\DBC1\I7\LOG\FullText\KBIndex_sandbox_s4'',
MOVE ''sysft_FieldValueIndex'' TO ''C:\DBC1\I7\LOG\FullText\FieldValueIndex_sandbox_s4'',
MOVE ''sysft_HistoryIndex'' TO ''C:\DBC1\I7\LOG\FullText\HistoryIndex_sandbox_s4'',
MOVE ''db_Log'' TO ''C:\DBC1\I7\LOG\sandbox_s4_log.ldf'', REPLACE, ORPHAN_CHECK"'
In this case, the sysft files are left as more generic names in the FullText directory and not within their respective MOVE directories.
For example, sysft_KBIndex would be expected to be contained in C:\DBC1\I7\LOG\FullText\KBIndex_sandbox_s4 with all it's related files, however, we instead see just this:
C:\DBC1\I7\LOG\FullText\ftrow_KBIndex.ndf
Tried adding a filename even to the MOVE command and that was ignored as well.
↧
↧
RE: Full Text not observing MOVE on a RESTORE
Could you please post the contents of the SQL Backup log file for that restore process? The default folder where the logs are stored is C:\ProgramData\Red Gate\SQL Backup\Log\<instance name>.
Thanks.
Thanks.
↧
RE: Full Text not observing MOVE on a RESTORE
Here are log files contents:
===============================================
SQL Backup log file 7.4.0.23
-SQL "RESTORE DATABASE sandbox_S4 FROM DISK='\\BackupServer\DatabaseBackups\P5\S4\FULL_s4_20130729_004816.sqb' WITH REPLACE, MOVE 'db_data' TO 'C:\DBC1\I7\DATA\sandbox_S4.mdf', MOVE 'db_log' TO 'C:\DBC1\I7\LOG\sandbox_S4_log.ldf', MOVE 'sysft_KBIndex' TO 'C:\DBC1\I7\LOG\FullText\KBIndex_sandbox_S4', MOVE 'sysft_FieldValueIndex' TO 'C:\DBC1\I7\LOG\FullText\FieldValueIndex_sandbox_S4', MOVE 'sysft_HistoryIndex' TO 'C:\DBC1\I7\LOG\FullText\HistoryIndex_sandbox_S4', PASSWORD='XXXXXXXXXX' "
----------------------- PROCESSES COMPLETED SUCCESSFULLY --------------------
7/31/2013 11:42:51 AM: Restoring sandbox_S4 (database) on I7 instance from:
7/31/2013 11:42:51 AM: \\BackupServer\DatabaseBackups\P5\S4\FULL_s4_20130729_004816.sqb
7/31/2013 11:42:51 AM: RESTORE DATABASE [sandbox_S4] FROM VIRTUAL_DEVICE = 'SQLBACKUP_67B9237E-4DF4-47AA-B059-5B2D4EEF055A', VIRTUAL_DEVICE = 'SQLBACKUP_67B9237E-4DF4-47AA-B059-5B2D4EEF055A01', VIRTUAL_DEVICE = 'SQLBACKUP_67B9237E-4DF4-47AA-B059-5B2D4EEF055A02' WITH BUFFERCOUNT = 18, BLOCKSIZE = 65536, MAXTRANSFERSIZE = 1048576 , RECOVERY, MOVE 'db_data' TO 'C:\DBC1\I7\DATA\sandbox_S4.mdf', MOVE 'db_log' TO 'C:\DBC1\I7\LOG\sandbox_S4_log.ldf', MOVE 'sysft_KBIndex' TO 'C:\DBC1\I7\LOG\FullText\KBIndex_sandbox_S4', MOVE 'sysft_FieldValueIndex' TO 'C:\DBC1\I7\LOG\FullText\FieldValueIndex_sandbox_S4', MOVE 'sysft_HistoryIndex' TO 'C:\DBC1\I7\LOG\FullText\HistoryIndex_sandbox_S4', REPLACE
7/31/2013 11:48:23 AM: Processed 2578912 pages for database 'sandbox_S4', file 'db_Data' on file 1.
7/31/2013 11:48:23 AM: Processed 172 pages for database 'sandbox_S4', file 'db_Log' on file 1.
7/31/2013 11:48:23 AM: Processed 122442 pages for database 'sandbox_S4', file 'sysft_KBIndex' on file 1.
7/31/2013 11:48:23 AM: Processed 46413 pages for database 'sandbox_S4', file 'sysft_FieldValueIndex' on file 1.
7/31/2013 11:48:23 AM: Processed 72707 pages for database 'sandbox_S4', file 'sysft_HistoryIndex' on file 1.
7/31/2013 11:48:23 AM: Converting database 'sandbox_S4' from version 611 to the current version 661.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 611 to version 621.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 621 to version 622.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 622 to version 625.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 625 to version 626.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 626 to version 627.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 627 to version 628.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 628 to version 629.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 629 to version 630.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 630 to version 631.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 631 to version 632.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 632 to version 633.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 633 to version 634.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 634 to version 635.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 635 to version 636.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 636 to version 637.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 637 to version 638.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 638 to version 639.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 639 to version 640.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 640 to version 641.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 641 to version 642.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 642 to version 643.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 643 to version 644.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 644 to version 645.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 645 to version 646.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 646 to version 647.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 647 to version 648.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 648 to version 649.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 649 to version 650.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 650 to version 651.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 651 to version 652.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 652 to version 653.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 653 to version 654.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 654 to version 655.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 655 to version 660.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 660 to version 661.
7/31/2013 11:48:23 AM: RESTORE DATABASE successfully processed 2820644 pages in 302.444 seconds (72.860 MB/sec).
7/31/2013 11:48:24 AM: SQL Backup process ended.
===============================================
SQL Backup log file 7.4.0.23
-SQL "RESTORE DATABASE sandbox_S4 FROM DISK='\\BackupServer\DatabaseBackups\P5\S4\FULL_s4_20130729_004816.sqb' WITH REPLACE, MOVE 'db_data' TO 'C:\DBC1\I7\DATA\sandbox_S4.mdf', MOVE 'db_log' TO 'C:\DBC1\I7\LOG\sandbox_S4_log.ldf', MOVE 'sysft_KBIndex' TO 'C:\DBC1\I7\LOG\FullText\KBIndex_sandbox_S4', MOVE 'sysft_FieldValueIndex' TO 'C:\DBC1\I7\LOG\FullText\FieldValueIndex_sandbox_S4', MOVE 'sysft_HistoryIndex' TO 'C:\DBC1\I7\LOG\FullText\HistoryIndex_sandbox_S4', PASSWORD='XXXXXXXXXX' "
----------------------- PROCESSES COMPLETED SUCCESSFULLY --------------------
7/31/2013 11:42:51 AM: Restoring sandbox_S4 (database) on I7 instance from:
7/31/2013 11:42:51 AM: \\BackupServer\DatabaseBackups\P5\S4\FULL_s4_20130729_004816.sqb
7/31/2013 11:42:51 AM: RESTORE DATABASE [sandbox_S4] FROM VIRTUAL_DEVICE = 'SQLBACKUP_67B9237E-4DF4-47AA-B059-5B2D4EEF055A', VIRTUAL_DEVICE = 'SQLBACKUP_67B9237E-4DF4-47AA-B059-5B2D4EEF055A01', VIRTUAL_DEVICE = 'SQLBACKUP_67B9237E-4DF4-47AA-B059-5B2D4EEF055A02' WITH BUFFERCOUNT = 18, BLOCKSIZE = 65536, MAXTRANSFERSIZE = 1048576 , RECOVERY, MOVE 'db_data' TO 'C:\DBC1\I7\DATA\sandbox_S4.mdf', MOVE 'db_log' TO 'C:\DBC1\I7\LOG\sandbox_S4_log.ldf', MOVE 'sysft_KBIndex' TO 'C:\DBC1\I7\LOG\FullText\KBIndex_sandbox_S4', MOVE 'sysft_FieldValueIndex' TO 'C:\DBC1\I7\LOG\FullText\FieldValueIndex_sandbox_S4', MOVE 'sysft_HistoryIndex' TO 'C:\DBC1\I7\LOG\FullText\HistoryIndex_sandbox_S4', REPLACE
7/31/2013 11:48:23 AM: Processed 2578912 pages for database 'sandbox_S4', file 'db_Data' on file 1.
7/31/2013 11:48:23 AM: Processed 172 pages for database 'sandbox_S4', file 'db_Log' on file 1.
7/31/2013 11:48:23 AM: Processed 122442 pages for database 'sandbox_S4', file 'sysft_KBIndex' on file 1.
7/31/2013 11:48:23 AM: Processed 46413 pages for database 'sandbox_S4', file 'sysft_FieldValueIndex' on file 1.
7/31/2013 11:48:23 AM: Processed 72707 pages for database 'sandbox_S4', file 'sysft_HistoryIndex' on file 1.
7/31/2013 11:48:23 AM: Converting database 'sandbox_S4' from version 611 to the current version 661.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 611 to version 621.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 621 to version 622.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 622 to version 625.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 625 to version 626.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 626 to version 627.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 627 to version 628.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 628 to version 629.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 629 to version 630.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 630 to version 631.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 631 to version 632.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 632 to version 633.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 633 to version 634.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 634 to version 635.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 635 to version 636.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 636 to version 637.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 637 to version 638.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 638 to version 639.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 639 to version 640.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 640 to version 641.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 641 to version 642.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 642 to version 643.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 643 to version 644.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 644 to version 645.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 645 to version 646.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 646 to version 647.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 647 to version 648.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 648 to version 649.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 649 to version 650.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 650 to version 651.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 651 to version 652.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 652 to version 653.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 653 to version 654.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 654 to version 655.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 655 to version 660.
7/31/2013 11:48:23 AM: Database 'sandbox_S4' running the upgrade step from version 660 to version 661.
7/31/2013 11:48:23 AM: RESTORE DATABASE successfully processed 2820644 pages in 302.444 seconds (72.860 MB/sec).
7/31/2013 11:48:24 AM: SQL Backup process ended.
↧
RE: Full Text not observing MOVE on a RESTORE
I could not reproduce your error using SQL Backup 7.4.0.23. It doesn't make sense why there is a secondary data file named ftrow_KBIndex.ndf in the target full-text folder.
Could you please try restoring this backup on another server, and see if you get the same results?
Thanks.
Could you please try restoring this backup on another server, and see if you get the same results?
Thanks.
↧
red gate activity history constant refresh state
I'd like to review the activity history for one of my servers but no matter how long I leave the window it will never display the activity history for one my of sql servers. I have already checked the log activity directory and cleaned it out. Any suggestions?
↧
↧
RE: SQBCoreservice consuming 80 - 90% cpu
Hi Peter.
We have 2 different databases on the server(s) that had the problem,both getting transaction log backups every 10mins. Looking at the graph in sql backup they seem to occur at the same time.
I have grabbed the sql the sql backup tool generates for the job and added it to the end of this reply.
In answer to your last question:
'Is there a specific interval where the backups cause the CPU utilization to max out, or does it happen with every transaction log backup?'
No there is no specific interval where the backups cause a problem - its very random as to when the issue occurs on different servers. As I mentioned - all servers have 2 databases which have tranaction log backups every 10 mins.
----------------------------------------------------------------------------
sql text
DECLARE @exitcode int
DECLARE @sqlerrorcode int
EXECUTE master..sqlbackup '-SQL "BACKUP LOGS [dataA,dataB] TO DISK = ''S:\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\<AUTO>.sqb'' WITH ERASEFILES_ATSTART = 1, ERASEFILES_REMOTE = 3, FILEOPTIONS = 4, CHECKSUM, DISKRETRYINTERVAL = 30, DISKRETRYCOUNT = 10, COMPRESSION = 4, COPYTO = ''\\Server1\TransactionLogBackups\Server11\'', INIT, THREADCOUNT = 2, VERIFY"', @exitcode OUT, @sqlerrorcode OUT
IF (@exitcode >= 500) OR (@sqlerrorcode <> 0)
BEGIN
RAISERROR ('SQL Backup failed with exit code: %d SQL error code: %d', 16, 1, @exitcode, @sqlerrorcode)
END
We have 2 different databases on the server(s) that had the problem,both getting transaction log backups every 10mins. Looking at the graph in sql backup they seem to occur at the same time.
I have grabbed the sql the sql backup tool generates for the job and added it to the end of this reply.
In answer to your last question:
'Is there a specific interval where the backups cause the CPU utilization to max out, or does it happen with every transaction log backup?'
No there is no specific interval where the backups cause a problem - its very random as to when the issue occurs on different servers. As I mentioned - all servers have 2 databases which have tranaction log backups every 10 mins.
----------------------------------------------------------------------------
sql text
DECLARE @exitcode int
DECLARE @sqlerrorcode int
EXECUTE master..sqlbackup '-SQL "BACKUP LOGS [dataA,dataB] TO DISK = ''S:\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Backup\<AUTO>.sqb'' WITH ERASEFILES_ATSTART = 1, ERASEFILES_REMOTE = 3, FILEOPTIONS = 4, CHECKSUM, DISKRETRYINTERVAL = 30, DISKRETRYCOUNT = 10, COMPRESSION = 4, COPYTO = ''\\Server1\TransactionLogBackups\Server11\'', INIT, THREADCOUNT = 2, VERIFY"', @exitcode OUT, @sqlerrorcode OUT
IF (@exitcode >= 500) OR (@sqlerrorcode <> 0)
BEGIN
RAISERROR ('SQL Backup failed with exit code: %d SQL error code: %d', 16, 1, @exitcode, @sqlerrorcode)
END
↧
RE: red gate activity history constant refresh state
What version of the tool are you on?
Can you try updating to the latest version of the tool?
If you continue to experience the issue.
The first thing to try is to clear the Activity Cache or *.dat files as follows:
1. Close the GUI connections.
2. Navigate to this directory on the machine where the SQL backup GUI is installed:
C:\Users\<username>\AppData\Local\Red gate\SQL Backup\ServerData
3. In this folder you will find one or more .dat files, for example 1.dat, 31.dat, localDataCache.dat.
4. Delete all the *.dat files in the ServerData folder.
5. Now re-open the GUI. The *.dat files deleted in the previous step will be recreated. This may take awhile while the files are rebuilt. Are you now able to view the Activity History?
For a majority of customers the above resolves the issue.
However there are tiny few whose Local Data Store corrupts for some reason, so need to follow the steps below. These include repeating the above plus more.
1. Close the SQL Backup GUI
2. Navigate to this directory on the machine where the SQL backup GUI is installed:
C:\Users\<username>\AppData\Local\Red gate\SQL Backup\ServerData
3. In this folder you will find one or more .dat files, for example 1.dat, 31.dat, localDataCache.dat.
4. Delete all the *.dat files in the ServerData folder.
5. On the machine where the SQL Instance is located stop the SQL Backup Agent service.
6. Locate the SQL BackupLocal Data Store. The default path is as follows:
C:\ProgramData\Red Gate\SQL Backup\Data\<SQL Instance name>
7. Rename the existing data.sdf file to OLDdata.sdf.
8. Restart the SQL Backup Agent Service, this step will create a new data.sdf.
9. Now re-open the GUI. The *.dat files deleted in step 4 will be recreated. Are you now able to view the Activity History? Depending how much activity history there is you may need to wait for a while.
Some users have also reported that reducing the amount of data in the activity cache can improve the time it takes to populate the history.
https://documentation.red-gate.com/display/SBU73/Activity+cache+location
Can you try updating to the latest version of the tool?
If you continue to experience the issue.
The first thing to try is to clear the Activity Cache or *.dat files as follows:
1. Close the GUI connections.
2. Navigate to this directory on the machine where the SQL backup GUI is installed:
C:\Users\<username>\AppData\Local\Red gate\SQL Backup\ServerData
3. In this folder you will find one or more .dat files, for example 1.dat, 31.dat, localDataCache.dat.
4. Delete all the *.dat files in the ServerData folder.
5. Now re-open the GUI. The *.dat files deleted in the previous step will be recreated. This may take awhile while the files are rebuilt. Are you now able to view the Activity History?
For a majority of customers the above resolves the issue.
However there are tiny few whose Local Data Store corrupts for some reason, so need to follow the steps below. These include repeating the above plus more.
1. Close the SQL Backup GUI
2. Navigate to this directory on the machine where the SQL backup GUI is installed:
C:\Users\<username>\AppData\Local\Red gate\SQL Backup\ServerData
3. In this folder you will find one or more .dat files, for example 1.dat, 31.dat, localDataCache.dat.
4. Delete all the *.dat files in the ServerData folder.
5. On the machine where the SQL Instance is located stop the SQL Backup Agent service.
6. Locate the SQL BackupLocal Data Store. The default path is as follows:
C:\ProgramData\Red Gate\SQL Backup\Data\<SQL Instance name>
7. Rename the existing data.sdf file to OLDdata.sdf.
8. Restart the SQL Backup Agent Service, this step will create a new data.sdf.
9. Now re-open the GUI. The *.dat files deleted in step 4 will be recreated. Are you now able to view the Activity History? Depending how much activity history there is you may need to wait for a while.
Some users have also reported that reducing the amount of data in the activity cache can improve the time it takes to populate the history.
https://documentation.red-gate.com/display/SBU73/Activity+cache+location
↧
RE: SQBCoreservice consuming 80 - 90% cpu
Th most likely cause of the high CPU utilization is the use of compression level 4. Could you please try using compression level 2 instead to see if it reduces the CPU utilization?
↧
RE: SQBCoreservice consuming 80 - 90% cpu
I will try that however that doesnt really explain why this is happening.
We have always used level 4 with no issues.
As i mentioned the cpu pressure is high even when no backups are occuring on the system at the end of business hours. When nobody is using the server at night the cpu is at around 50% and that 50% is being used by the process sqbcoreservice. So how would compression levels effect an idle server ?
We have always used level 4 with no issues.
As i mentioned the cpu pressure is high even when no backups are occuring on the system at the end of business hours. When nobody is using the server at night the cpu is at around 50% and that 50% is being used by the process sqbcoreservice. So how would compression levels effect an idle server ?
↧
↧
RE: SQBCoreservice consuming 80 - 90% cpu
My apologies, I did not know that the SQBCoreService was running the CPU at 50% even when no backups were being performed.
The next time that you find this happening, could you please run the following:
to generate a SQBCoreService activity log file, and send me the file? This file is named SQBCoreService_<instance name>_bugreport.txt, and is located in 'C:\Documents and Settings\All Users\Application Data\Red Gate\SQL Backup\Log\' on Windows 2003 and older, and 'C:\ProgramData\Red Gate\SQL Backup\Log\' on Windows Vista and newer.
Thanks.
The next time that you find this happening, could you please run the following:
| Code: |
| EXEC master..sqbutility 9997 |
to generate a SQBCoreService activity log file, and send me the file? This file is named SQBCoreService_<instance name>_bugreport.txt, and is located in 'C:\Documents and Settings\All Users\Application Data\Red Gate\SQL Backup\Log\' on Windows 2003 and older, and 'C:\ProgramData\Red Gate\SQL Backup\Log\' on Windows Vista and newer.
Thanks.
↧
RE: SQBCoreservice consuming 80 - 90% cpu
Hi - My apologies also as i think i mentioned the no activity bit on another post !!!!
I have ran the query on the server but i cant find the location. It is on Windows Sever 2008.
c:\program files\red gate\sql backup 7\local
In the local i can see SQBCoreService - application, sqlbackupC - application, unins000.dat, unins000 -application and zlib1.dll
There is also a x64 folder with xp_sqlbackupdll
but no text file !
I have ran the query on the server but i cant find the location. It is on Windows Sever 2008.
c:\program files\red gate\sql backup 7\local
In the local i can see SQBCoreService - application, sqlbackupC - application, unins000.dat, unins000 -application and zlib1.dll
There is also a x64 folder with xp_sqlbackupdll
but no text file !
↧
RE: SQBCoreservice consuming 80 - 90% cpu
sorry - ive got it !
↧
SQL Backup File Converter crashes with 7.4
I have just upgraded my backup installation to 7.4.0.186 and have tried to use the SQL Backup ConverterGUI on a backup file created with version 7.1
It crashes with the error:
"SQBConverterGUI has stopped working"
"A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available"
I have successfully converted the same backup file on a colleagues machine so I know it is not a corrupt backup file.
Has anyone else come across this issue?
It crashes with the error:
"SQBConverterGUI has stopped working"
"A problem caused the program to stop working correctly. Windows will close the program and notify you if a solution is available"
I have successfully converted the same backup file on a colleagues machine so I know it is not a corrupt backup file.
Has anyone else come across this issue?
↧
↧
Backup jobs (FULL or DIFFs) disconnect LUNs on a Cluster
Here are the typical Os errors, before SQL fails over to the passive node:
-Connection to the target was lost. The initiator will attempt to retry the connection.
-The initiator could not send an iSCSI PDU. Error status is given in the dump data.
-\Device\MPIODisk25 is currently in a degraded state. One or more paths have failed, though the process is now complete.
Has anyone seen this issue before?
This is a two node SQL2012 SP1 Cluster running on Windows2008r2 SP1 Os.
PS: we currently have a SAN bottleneck and latency issue, I am fully aware of it, but the backups were running before. They were hitting the SAN really hard, but the RedGate FULL backup job never did anything harm.
-Connection to the target was lost. The initiator will attempt to retry the connection.
-The initiator could not send an iSCSI PDU. Error status is given in the dump data.
-\Device\MPIODisk25 is currently in a degraded state. One or more paths have failed, though the process is now complete.
Has anyone seen this issue before?
This is a two node SQL2012 SP1 Cluster running on Windows2008r2 SP1 Os.
PS: we currently have a SAN bottleneck and latency issue, I am fully aware of it, but the backups were running before. They were hitting the SAN really hard, but the RedGate FULL backup job never did anything harm.
↧
RE: SQL Backup File Converter crashes with 7.4
There is indeed a bug with the release version of the SQL Backup GUI converter. Please download the patched version using the following URL:
ftp://support.red-gate.com/patches/sql_backup/SQBConverterGUI_7.4.100.zip
Replace the existing files in your SQL Backup installation folder with the files in the archive.
ftp://support.red-gate.com/patches/sql_backup/SQBConverterGUI_7.4.100.zip
Replace the existing files in your SQL Backup installation folder with the files in the archive.
↧
RE: SQL Backup File Converter crashes with 7.4
That worked fine. Thanks!
↧
More Pages to Explore .....
