The best time to prepare for a disaster is before it happens.
Review the procedures in this chapter before an actual disaster occurs, such as a power failure, hard disk crash, or other severe problem that could cause the loss of your master device, your master database, or other vital system resource. Here are some hints for making these procedures the most effective:
Create and keep backups of complete, detailed scripts to re-create your system exactly as it existed before the disaster and to perform recovery as efficiently as possible. In particular, your scripts should contain the following information:
Copies of key system tables in the master database, particularly sysdatabases, sysdevices, sysusages, sysconfigures, syscharsets , syslogins, sysremotelogins, sysresourcelimits, and systimeranges. You can make copies of these tables by using bcp with the -c option.
Records of disk init, disk reinit, create database, alter database, sp_addsegment, and sp_extendsegment commands.
Records of all changes made to syslogins and sysloginroles. You may want to keep an ongoing script of all the sp_addlogin and sp_droplogin commands.
Records of creations and modifications of system and user databases, particularly for structural changes, and particularly for master.
SQL records. Even if you are adding only a single disk device or a couple of logins, it is good system administration practice to save all this information in scripts and hard copy.
Take steps to prevent other users logging into Adaptive Server while you are working with the master database or device. To do this always start Adaptive Server using the -m option. You can also temporarily use a different interfaces file (unix) or sql.ini file (Windows), or entry with a different port number and name, so that other users will not find the server you are working on.
Use dump database to back up the master database frequently; this helps simplify solving problems with the master database. Back it up after any changes to system tables, especially changes to sysusages, sysdatabases, sysdevices, syslogins, sysloginroles, sysservers, and sysconfigures.
Truncate the master database log frequently.
Keep statistics on how much time and space are required for dumps and loads.
Avoid keeping user databases on the master device, as it complicates recovery scenarios.
Always issue a dump database command after the following:
bcp (fast version)
create index
select into
dump transaction with no_log
dump transaction with truncate_only
Where appropriate, automate the use of operating system threshold procedures and scripts that run backups.
Verify that your interfaces file (unix) or sql.ini file (Windows) is correct.
Catalog and label your backup media carefully.
Try to run dbcc commands at the time you make dumps to ensure that the dump is not corrupted.
Different versions of the configuration file are maintained on disk in $SYBASE directory for reference.
Refer to
“Developing a Backup and Recovery Plan” in the System Administration Guide
Avoiding Disaster through Good DBA Practices in Encyclopedia of Tasks
to learn more about the procedures described in this chapter so that you are ready for an emergency.
