FAQs about Database dumps and loads

核心提示：FAQs about Database dumps and loads This TechNote answers frequently asked questions about Sybase SQL Server and Adaptive Server Enterprise dumps and loads. Thi

FAQs about Database dumps and loads 

This TechNote answers frequently asked questions about Sybase SQL Server and Adaptive Server Enterprise dumps and loads. 


This document answers frequently asked questions about database dump and loads with Adaptive Server Enterprise and Sybase SQL Server 11.0.x. It comprises the following sections:

Logs

Dumps and Loads

Backups and Maintenance


Logs

What information is tracked by the logptr column in master..sysdatabases?

The logptr column points to the first data page in the transaction log. This column is necessary for the dump tran with no_truncate command to function.


If the transaction log is kept on a separate physical device, you can use the dump tran with no_truncate command to dump the current transaction log even if the database itself has become inaccessible. This feature lets you rebuild a database to its state at the moment it was lost due to media failure.

WARNING!　Do not use the dump tran with no_truncate command with a database that is in use. For more information, see the Sybase Adaptive ServerTM Enterprise System Administration Guide.
 


Media recovery from the current log is possible because the logptr column is located outside the user database, in the master database.


Why does my log grow during dump, even with trunc log on chkpt option?

A database is configured to have trunc log on chkpt. During a dump of that database, the syslogs table continues to grow until the dump is finished. Why doesn't the log truncate?


The log cannot truncate because the checkpoint process occurs only at the start and at the completion of the database dump.


Dumps and Loads

What effect does select into/bulkcopy have on dump transaction?

Why are dump transaction commands not allowed for a database when it has the select into/bulkcopy option set? Trying to do so generates Error 4207.


This happens only when a minimally logged operation occurred and the select into/bulkcopy option is set. When the select into/bulkcopy option is set in a database, rows added with fast bulkcopy are not logged. Only the space allocated during the fast bulkcopy is logged. The transaction log is not complete and could not be used for load transaction.


To perform a dump transaction for that database, the following must be true: 

select into/bulkcopy option must be disabled with sp_dboption.

The database must be dumped with dump database before you dump the transaction log.

See the Sybase Adaptive ServerTM Enterprise Reference Manual and the Sybase Adaptive ServerTM Enterprise System Administration Guide for details.


What is the effect of a database's growth on dump database time?

As the number of pages used by a database increases, does the time for a dump increase because the dump database command has to check all the pages in that database or does it remain constant?


The time required for dumping a database increases as the number of pages increases. The dump process dumps only the allocated pages being used in that database. The dump does not need to check every page, only the allocated pages. 


What are the differences between dump transaction and dump transaction with no_truncate?

When a dump transaction command is issued, the server makes a copy of all the inactive transactions that occurred on a particular database up to the point of the actual time of dump, and those transactions are removed from the log. When thedump transaction with no_truncate command is issued, the server makes a copy of the inactive transactions but does not remove those transactions from the log.


Therefore, if successive transaction log dumps are performed using dump transaction with no_truncate, the log will grow in size and will eventually have to be purged either via dump transaction or dump transaction with truncate_only. 

Note:　The dump transaction with truncate_only command does not make a copy of the log, but purges the log of all inactive transactions.
 


What are the differences between dump transaction with truncate_only and dump transaction with no_log?

Neither dump transaction with truncate_only nor dump transaction with no_log make a copy of the log records. Both reduce the space used in syslogs whenever possible. 


The dump transaction command adds checkpoint records and log-deallocation records to the log even when just truncating the log, except when using the with no_log option. Use dump transaction with no_log only when dump transaction with truncate_only fails because syslogs lacks room for dump transaction's checkpoint and deallocation records. See dump transaction in the Sybase Adaptive ServerTM Enterprise System Administration Guide.

WARNING!　You must dump the database immediately after performing either of these options. If corruption occurs while using dump transaction with no_log or dump transaction with truncate_only, you will be unable to recover because there will be no log information.
 


Will databases retain dbid value with dump and load?

A database is dumped from one server and loaded onto another. Will that database have the same dbid after the load?


No, because the dbid of a database is determined at the time the database is created and a row is added to sysdatabases. The dbid of the database that is loaded is the dbid of the database into which it is loaded.


Why does suid change in a database being loaded to match sysdatabases?

During the load of a database, the following error messages may display:

Error 3115 Severity 10: User %.*s in database %.*s has suid %d, which is the same as the suid of the DBO (as defined in Sysdatabases). User %.*s will be given suid %d. 

Error 3116 Severity 10: When all load transactions have been completed for database %.*s, user %.*s should be given a unique suid.


These errors occur due to a condition that causes inconsistency in the user information between source and target databases. The load attempts to update sysusers..suid for the target database to match the source suid. However, doing this would cause duplicate suids in sysusers, which is not allowed because there is a uniqueness requirement for suid.

Example 1

This example shows sysusers before the load and after:


sysusers
 suid
 uid
 name
 
Before Load
 23
 1
 dbo sa_user
 
　1
 2
　 
　　　　
After Load
 1
 1
 dbo sa_user
 
　-99
 2
　 


In this case, another user owned the database that was dumped but had the "sa" role as a user in the database. The destination database for the load was created by the "sa". The sysusers row for "dbo" should be changed at the end of the load. There is a unique index on suid, so the row for sa_user has its suid changed to -99.


Why do I get Error 3114 after loading dump of master to another machine?

You may encounter this error:

Error 3114, Severity: 21, State: 1 Database does not have an entry in Sysdatabases.

Cannot recover the master database, exiting.

The master database contains references to the devices and databases that are loaded onto the first machine. The second machine contains the wrong references, causing the error. Sybase recommends using the same machine for dumps and loads of the master database.


Backups and Maintenance

Why should I run dbcc commands on a database before dumping?

It is often possible to dump a database that is not consistent. The dbcc checkalloc, dbcc checkdb, dbcc checkcatalog, and dbcc checkstorage commands perform different tests of the database's consistency; they are briefly described in the chapter, "Checking Database Consistency" in the Sybase Adaptive ServerTM Enterprise System Administration Guide. When it is not practical to run all these commands before each dump of a very large database, they should all be run periodically as part of a preventive maintenance program

Note:　dbcc checkstorage, introduced in Adaptive Server 11.5, requires its own database, dbccdb.
 


How often should I perform dbcc?

How often depends on how much data you are willing to lose in a worst-case scenario. In general, the more important your data, the more often you should run dbccs.


If yours is not a 24-hour organization, and dbccs will complete during your down-time, perform them nightly with the output redirected to a file. Perform a grep on the file for the keywords "Err," "err," and "Msg" to catch most errors that dbcc would report. Scan the output occasionally to catch anything else that might be reported.


Mission-critical enterprises often use a second server as a "warm backup." Instead of running dbcc commands on the production server, dumps are taken, loaded on the warm backup, and dbccs are run there. If errors are discovered, attempts are made to correct it on production server.


Sites with very large databases sometimes use a rotating schedule of dbcc tablealloc and dbcc checktables, rather than the all-at-once dbcc checkalloc and dbcc checkdbs. Additionally, a new command, dbcc checkstorage, allows you to check a database that is in use with little impact on performance. See the Sybase Adaptive ServerTM Enterprise System Administration Guide.


How often should I dump and load the database?

In case of catastrophe (such as disk failure), how much processing are you willing to lose? If the answer is 1 hour's worth, you probably should dump the database at least daily, and dump the log at least hourly. 


Generally, you load the database to recover from catastrophe. However, Sybase recommends you occasionally perform a database dump and load in a test environment to ensure that the dump process is working and you are familiar with how to do it.

Note:　Do not perform these tests on your production database. If something is wrong with your dump, and you load it on top of your database, then you have lost your data.
 


Which utility should I use for nightly tape backups?

In addition to the server commands dump database and dump tran, you can use third-party tools such as SQL-BacktrackTM.


Which media drivers are compatible with the server?

Because of the number of media drivers, Sybase does not test compatibility for every driver. Contact your vendor for driver-compatibility information.


What if I don't have enough time for a full backup?

You can shorten the required backup-time by: 

Truncating the log just before performing dump database. A database dump includes all log pages, regardless of whether they are committed records. By truncating the log, only uncommitted records will be included.

Stripe the dump over as many dump devices as possible. Backup Server can handle up to 32 dump devices.

If neither of these measures help, you can still perform full backups. Backup Server is designed to minimize interference with server operation. Therefore, you can perform dumps during periods of normal load, although performance would be affected.


How do I back up to tape using isql?

Log in to isql and issue the following: 

1> dump database <dbname> to "<devicename>"
2> go

You can save and execute this script through an automated scheduler such as cron, if you know that your dump tape will be in that particular tape drive when the scheduler job executes. Otherwise, you risk overwriting the wrong tape.


For larger databases, you may have to stripe across several tape drives to perform this automatically. For information on striping, see the Sybase Adaptive ServerTM Enterprise System Administration Guide


When should I perform checkpoints, or does the server automatically perform checkpoint before a backup?

Adaptive Server checkpoints the databases automatically at the beginning of dump command. At other times, checkpoint frequency is controlled by the "recovery interval" parameter (sp_configure) and the amount of activity in the database. Otherwise, perform a manual checkpoint after making direct updates to system tables and as part of changing parameters with sp_dboption. 


Why did my backups stop working after upgrade?

Unless the Backup Server is correctly defined, it cannot run. This often occurs when users rename the Backup Server from the default name. To determine whether this is your problem, run the following isql statement: 

1> select * from master..sysservers
2> go

If the srvnetname column does not list the name you use for your Backup Server, change it by performing one of the following: 

Create an alias in your Backup Server RUN_SERVER file

-S<your_backup_server_name>
Modify the network name in the interfaces file using the installation utility for your platform.

Use sp_addserver to update the network name for SYB_BACKUP.

1> sp_dropserver SYB_BACKUP
2> go
1> sp_addserver SYB_BACKUP, null, <your_backup_server_name>
2> go