VDI error 1010 and Varning 300

mliumliu Posts: 26
edited March 21, 2007 11:53PM in SQL Backup Previous Versions
Hi,

Lately, we have received both the warning and error message from the primary server where the backup files are created. Below is the error log from one of the files:

SQL Backup log file
3/13/2007 9:45:00 AM: Backing up db (transaction log) to:
E:\SQLBackup\SQLData\LOG_(local)_db_20070313_094500.sqb

3/13/2007 9:45:00 AM: BACKUP LOG [db] TO DISK = 'E:\SQLBackup\SQLData\LOG_(local)_db_20070313_094500.sqb' WITH NAME = '<AUTO>', DESCRIPTION = '<AUTO>', PASSWORD = 'XXXXXXXXXX', KEYSIZE = 256, ERASEFILES = 7, MAILTO_ONERROR = '[email protected]', COPYTO = '\\Crm-custdb\SQLShareNEW', COPYTO = '\\bdgsp-svr\Backup\CRMBackup\HourlyLogbackup', COMPRESSION = 1, THREADS = 1

3/13/2007 9:45:00 AM: VDI error 1010: Failed to get configuration from server. Check that the SQL Server instance is running, and that you have the SQL Server Systems Administrator server role. Error code: (-2139684860: An abort request is preventing anything except termination actions.)
3/13/2007 9:45:01 AM: SQL error 3013: BACKUP LOG is terminating abnormally.
3/13/2007 9:45:01 AM:
3/13/2007 9:45:01 AM: Memory profile
3/13/2007 9:45:01 AM: Type Maximum Minimum Average Blk count Total
3/13/2007 9:45:01 AM:





3/13/2007 9:45:01 AM: Commit 891092992 4096 597107 3141 1875513344
3/13/2007 9:45:01 AM: Reserve 4128768 16384 423715 130 55083008
3/13/2007 9:45:01 AM: Free 6463488 4096 91912 2359 216821760
3/13/2007 9:45:01 AM: Private 891092992 4096 3251870 567 1843810304
3/13/2007 9:45:01 AM: Mapped 1019904 4096 26432 2261 59764736
3/13/2007 9:45:01 AM: Image 5750784 4096 60996 443 27021312
3/13/2007 9:45:01 AM:
3/13/2007 9:45:01 AM: Warning 300: Backup failed. Retry attempt: 1
3/13/2007 9:45:03 AM: BACKUP LOG [db] TO DISK = 'E:\SQLBackup\SQLData\LOG_(local)_calyxprod_app_20070313_094500.sqb' WITH NAME = 'Database (db), 3/13/2007 9:45:00 AM', DESCRIPTION = 'Backup on 3/13/2007 9:45:00 AM Server: CRM-CUSTDB Database: db', INIT, PASSWORD = 'XXXXXXXXXX', KEYSIZE = 256, ERASEFILES = 7, MAILTO_ONERROR = '[email protected]', COPYTO = '\\Crm-custdb\SQLShareNEW', COPYTO = '\\bdgsp-svr\Backup\CRMBackup\HourlyLogbackup', COMPRESSION = 1, THREADS = 1

3/13/2007 9:45:03 AM: Backup data size : 1.438 MB
3/13/2007 9:45:03 AM: Compressed data size: 225.500 KB
3/13/2007 9:45:03 AM: Compression rate : 84.68%

Processed 110 pages for database 'db', file 'db' on file 1.
BACKUP LOG successfully processed 110 pages in 0.055 seconds (16.244 MB/sec).
3/13/2007 9:45:05 AM: Deleting old backup file: E:\SQLBackup\SQLData\LOG_(local)_db_20070306_084500.sqb
3/13/2007 9:45:08 AM: Copied E:\SQLBackup\SQLData\LOG_(local)_db_20070313_094500.sqb to \\Crm-custdb\SQLShareNEW\LOG_(local)_db_20070313_094500.sqb.
3/13/2007 9:45:08 AM: Copied E:\SQLBackup\SQLData\LOG_(local)_calyxprod_app_20070313_094500.sqb to \\bdgsp-svr\Backup\CRMBackup\HourlyLogbackup\LOG_(local)_db_20070313_094500.sqb.
3/13/2007 9:45:08 AM: Mail sent successfully to: [email protected]


When we checked to see whether the restore process, it seems to be working just fine as we can see the backed up log files are generated, and they are being restored. This happens to both the log shipping backup process as well as the full backup that's done daily.

What could be casuing this warning message? How could we resolve this?

Thanks

Comments

  • peteypetey Posts: 2,358 New member
    When SQL Backup runs a backup, it requires SQL Server to have a certain amount of contiguous free memory. If SQL Server is unable to service the request, the backup process is aborted and reattempted, with a smaller amount of contiguous free memory. If SQL Server is able to service that request, the backup proceeds. However, a warning (300) is logged to inform you that SQL Server may be running into a low memory condition.

    In your case, the maximum contiguous free memory was about 6.2 MB, which was inadequate for the default SQL Backup settings. SQL Backup then reattempted the backup with smaller memory settings, and that was successful.

    You can configure SQL Backup to request a lower amount of memory initially, by using the MAXTRANSFERSIZE option. The help file has details on this.
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
  • Hello.

    We have something similar. On our cluster, we had the following failure last night.

    This is a dedicated SQL Server 2000, sp3, hotfixed up to 8.00.923. It is running on a windows 2003 box (Build 3790: Service Pack 1), and has 3.8GB Memory, where SQL Server is allowed to grab 2.1GB for itself.

    Around this time (according to our perfmon stats), there is a very small beat on Memory\Page Faults/sec, but it does not seem to be out of the ordinary compared to other days.
    SQL Backup log file
    21/03/2007 9:00:19 PM: Backing up DATABASE_NAME (full database) to:
    E:\Backups\Database\DATABASE_NAME.sqb

    21/03/2007 9:00:19 PM: BACKUP DATABASE [DATABASE_NAME] TO DISK = 'E:\Backups\Database\DATABASE_NAME.sqb' WITH NAME = 'Complete Backup - DATABASE_NAME', DESCRIPTION = '<AUTO>', INIT, PASSWORD = 'XXXXXXXXXX', KEYSIZE = 256, COMPRESSION = 1

    21/03/2007 9:00:34 PM: VDI error 1010: Failed to get configuration from server. Check that the SQL Server instance is running, and that you have the SQL Server Systems Administrator server role. Error code: (-2139684861: The api was waiting and the timeout interval had elapsed.)
    21/03/2007 9:00:35 PM: SQL error 3013: BACKUP DATABASE is terminating abnormally.
    21/03/2007 9:00:35 PM:
    21/03/2007 9:00:35 PM: Memory profile
    21/03/2007 9:00:35 PM: Type Maximum Minimum Average Blk count Total
    21/03/2007 9:00:35 PM:





    21/03/2007 9:00:35 PM: Commit 231751680 4096 0 5669 -1450278912
    21/03/2007 9:00:35 PM: Reserve 4911104 8192 41126 4552 187207680
    21/03/2007 9:00:35 PM: Free 167907328 4096 822886 230 189263872
    21/03/2007 9:00:35 PM: Private 231751680 4096 0 9515 -1340833792
    21/03/2007 9:00:35 PM: Mapped 4128768 4096 167310 72 12046336
    21/03/2007 9:00:35 PM: Image 9928704 4096 103653 634 65716224
    21/03/2007 9:00:35 PM:
    21/03/2007 9:00:35 PM:
    21/03/2007 9:00:35 PM: Warning 300: Backup failed. Retry attempt: 1
    21/03/2007 9:00:37 PM: BACKUP DATABASE [DATABASE_NAME] TO DISK = 'E:\Backups\Database\DATABASE_NAME.sqb' WITH NAME = 'Complete Backup - DATABASE_NAME', DESCRIPTION = 'Backup on 21/03/2007 9:00:19 PM Server: SERVER_NAME Database: DATABASE_NAME', INIT, PASSWORD = 'XXXXXXXXXX', KEYSIZE = 256, COMPRESSION = 1

    21/03/2007 9:27:26 PM: Backup data size : 62.539 GB
    21/03/2007 9:27:26 PM: Compressed data size: 15.981 GB
    21/03/2007 9:27:26 PM: Compression rate : 74.45%

    Processed 8154728 pages for database 'DATABASE_NAME', file 'DATABASE_NAME_Primary' on file 1.
    Processed 42223 pages for database 'DATABASE_NAME', file 'DATABASE_NAME_LOG' on file 1.
    BACKUP DATABASE successfully processed 8196951 pages in 1606.758 seconds (41.791 MB/sec).
    Verifying the file will only make the "verify process" hang... in other words it does nothing.

    Any ideas? From what I can tell, SQL Server is not running low on memory (?)

    Regards,
    Martin
  • peteypetey Posts: 2,358 New member
    No, it does not appear to be a low memory issue. One possibility is that the SQL Server was busy at that instant, and was unable to serve the BACKUP request.

    When you verify the file, could you pls run the sqbstatus extended stored procedure from another connection and tell me at what numbers do they remain static?

    Thanks.
    Peter Yeoh
    SQL Backup Consultant Developer
    Associate, Yohz Software
    Beyond compression - SQL Backup goodies under the hood, updated for version 8
  • Solved (!)

    I did copy the "corrupt" backup file to another server to run the verify process again, and this time it went thorugh fine, something I looked upon with a mix of happiness and fear.

    It was then I realized that our "verify process" had been running for more than 31 hours... in other words, the verify process was still running when the backup started, and I assume that created a clash with a warning message as a result.

    This leaves the question of why the verify process did not complete, but I will investigate that further the next few days.

    Thanks for your help.

    Regards,
    Martin
Sign In or Register to comment.