Venice Systems www.venicesystems.

com

Sybase System 11
Steps Before Backing up the Database
We highly recommend that that you run a set of these following database validation commands when there are minimal or no activity on the database before you take a backup. dbcc checkdb or dbcc checktable dbcc checkalloc or dbcc indexalloc and dbcc tablealloc dbcc checkcatalog

Command and Option Checktable checkdb

Level Page chains, sort order, data rows for all indexes

Checktable checkdb with skip_ncindex

Page chains, sort order, data rows for tables and clustered indexes Page chains

Locking and Performance Shared table lock; dbcc checkdb locks one table at a time and releases the lock after it finishes checking that table Same as above

Speed Slow

Thoroughness High

Checkalloc

Tablealloc full indexalloc full

Page chains

Tablealloc optimized indexalloc optimized

Allocation pages

Tablealloc fast indexalloc fast Checkcatalog

OAM pages Rows in system tables

No locking; performs a lot of I/O and may saturate the I/O calls; only allocation pages are cached Shared table lock; performs a lot of I/O; only allocation pages are cached Shared table lock; performs a lot of I/O; only allocation pages are cached Shared table lock Shared page locks on system catalogs; releases lock after each page is checked;

Up to 40% faster than without the skip_nc ndex option Slow

Medium

High

Slow

High

Moderate

Medium

Fastest

Low

Page 1 of 11 Copyright 1999,2000 RFD & Associates, Inc. - www.rfdinc.com

Venice Systems www.venicesystems.com very few pages cached

If your SQL Server is used primarily between the hours of 8:00 a.m. and 5:00 p.m., Monday through Friday, you can run dbcc checks at night and on weekends so that the checks do not have a significant impact on your users. If your tables are not extremely large, you can run a complete set of dbcc commands fairly frequently. If your SQL Server is heavily used 24 hours a day, 7 days a week, you may want to schedule a cycle of checks on individual tables and indexes using dbcc checktable, dbcc tablealloc, and dbcc indexalloc. At the end of the cycle, when all tables have been checked, you can run dbcc checkcatalog and back up the database.

Using the Dump and Load Commands In case of media failure, such as a disk crash, you can restore your databases if and only if you have been making regular backups of the databases and their transaction logs. Full recovery depends on the regular use of the dump database and dump transaction commands to back up databases and the load database and load transaction commands to restore them. The dump database, dump transaction, load database, and load transaction commands have parallel syntax. Routine dumps and loads require the name of a database and at least one dump device. The commands can also include the following options: at server_name to specify the remote Backup Server density, blocksize, and capacity to specify tape storage characteristics dumpvolume to specify the volume name of the ANSI tape label file = file_name to specify the name of the file to dump to or load from stripe on stripe_device to specify additional dump devices dismount, unload, init, and retaindays to specify tape handling notify to specify whether Backup Server messages are sent to the client that initiated the dump or load or to the operator_console

Backing Up a Database or Log Database name Dump devicedump {database | tran} database_name to stripe_device [at server_name] [density = density, blocksize = number_bytes, capacity = number_kilobytes, dumpvolume = volume_name, file = file_name] [stripe on stripe_device [at server_name] [density = density, blocksize = number_bytes, capacity = number_kilobytes, dumpvolume = volume_name, file = file_name, [nodismount | dismount ], [nounload | unload], retaindays = number_days, [noinit | init], [notify = {client | operator_console}]}]

Loading a Database or Log load {database | tran} database_name from stripe_device [at server_name][density = density,blocksize = number_bytesdumpvolume = volume_namefile = file_name][stripe on stripe_device[at server_name][density = density,blocksize = number_bytes,dumpvolume = volume_name,file = file_name] ...] [with{ density = density, blocksize = number_bytes, dumpvolume = volume_name, file = file_name, [nodismount | dismount ], [nounload | unload], [notify = {client | operator_console

Page 2 of 11 Copyright 1999,2000 RFD & Associates, Inc. - www.rfdinc.com

Venice Systems www.venicesystems.com

Rules for Specifying Dump Devices

Use the following rules when specifying the dump device: You can specify the dump device as a literal, a local variable, or a parameter to a stored procedure. You cannot dump to or load from the "null device" (on UNIX, /dev/null; on OpenVMS, any device name beginning with NL; not applicable to PC platforms ). When dumping to or loading from a local device, you can use any of the following forms to specify the dump device:

- An absolute path name - A relative path name - A logical device name from the sysdevices system table The Backup Server resolves relative path names using SQL Server's current working directory. When dumping or loading across the network: - You must specify the absolute path name of the dump device. (You cannot use a relative path name or a logical device name from the sysdevices system table.) - The path name must be valid on the machine on which the Backup Server is running. - If the name includes any characters except letters, numbers or the underscore (_), you must enclose it in quotes. Examples The following examples use a single device for dumps and loads. (It is not necessary to use the same device for dumps and loads.)

On UNIX: dump database pubs2 to "/dev/nrmt4" load database pubs2 from "/dev/nrmt4" On OpenVMS: dump database pubs2 to "MTA0:" load database pubs2 from "MTA0:"

Avoiding volume changes during backup and recovery When you dump the master database, be sure that the entire dump fits on a single volume, unless you have more than one SQL Server able to communicate with your Backup Server. You must start SQL Server in single-user mode before loading the master database. This does not allow a separate user connection to respond to Backup Server's volume change messages during the load. Since master is usually small in size, placing its backup on a single tape volume is typically not a problem.

Recovering the master Database This section describes the step to recover the master database in two situations:

Page 3 of 11 Copyright 1999,2000 RFD & Associates, Inc. - www.rfdinc.com

Venice Systems www.venicesystems.com

When the database is corrupt but the master device has not been damaged. This process does not affect the model database. Recovering model is covered later in the white paper. When the master device is damaged, and you must restore the entire device. You can also use these procedures to move your master database to a larger master device. Special procedures are needed because of the central, controlling nature of the master database and the master device. Tables in master configure and control all of SQL Server's functions, databases, and data devices. The recovery process:

Restores master to the default state on a newly installed server Restores master to its condition at the time of your last backup Performs very special procedures to recover changes to devices and databases since the last backup During the early stages of recovering the master database, you will not be able to use the system store procedures. If you have user databases that you have not backed up on your master device, you may not be able to use these procedures to recover. You should call Technical Support for assistance.

Recovery Procedure System Administrators must use the following steps to restore a damaged master database. Each of these steps is discussed in more detail on the following pages. Make hard copies of vital system tables needed to restore disks, databases and logins. If you can log into your server, save copies of the following system tables to a disk file: sysdatabases, sysdevices, sysusages, sysloginroles and syslogins. You can use these to guarantee that your system has been fully restored at the completion of this process. You can use isql (use select * from tablename) or bcp (copy the tables in character mode) to make copies to disk files. If possible, make a copy of sysusages ordered by vstart: select * from sysusages order by vstart For more information about the isql and bcp programs, see the SQL Server utility programs manual for your operating system. If there are other databases on the master device, and they are accessible, back them up with dump database. If there are user databases on the master device, and they are accessible, use dump database to dump them. Shut down SQL Server and use buildmaster to build a new master database or master device. If you are rebuilding only your master database, you use a special option to buildmaster that only affects master. If you are rebuilding the entire master device, you use buildmaster without this option. WARNING! Shut down SQL Server before you use any buildmaster command. If you use buildmaster on a master device that is in use by SQL Server, the recovery procedure will fail when you attempt to load the most recent backup of master.

Page 4 of 11 Copyright 1999,2000 RFD & Associates, Inc. - www.rfdinc.com

Venice Systems www.venicesystems.com

Rebuilding only the master Database Run buildmaster -m (UNIX and PC) or buildmaster /master (OpenVMS) to replace the damaged master database with a copy of a "generic" master database. Give the full name for your master device, and the full size of the device. Note:You must give buildmaster a size as large as or larger than the size originally used to configure SQL Server. If you recorded this information in your SQL Server installation and configuration guide, use that size. If the size you provide is too small, you will get error messages when you try to load your databases. This example rebuilds the master database on a 17MB (8704 2K pages) master device: On UNIX platforms: buildmaster -d /dev/rsd1f -s8704 -m On OpenVMS: buildmaster /disk=dua0:[devices.master]d_master.dat/size=8704 /master On PC platforms: For PC platform examples, refer to the SQL Server installation and configuration guide. After you run buildmaster, the password for the default "sa" account reverts to NULL. For details on the buildmaster utility, see the SQL Server utility programs manual Starting SQL Server in Master-Recover Mode Start SQL Server in master-recover mode with the -m (UNIX and PC) or /masterrecover (OpenVMS) options. See the SQL Server utility programs manual for complete syntax. On UNIX platforms: startserver -f RUN_server_name -m On OpenVMS: startserver /server = server_name /masterrecover On PC platforms: For PC platform examples, refer to the SQL Server installation and configuration guide. When you start SQL Server in master-recover mode, only one login of one user the System Administrator is allowed. Immediately after a buildmaster command on the master database, only the "sa" account exists, and its password is NULL. This special master-recover mode is necessary because the generic master database created with buildmaster does not match the actual situation on SQL Server. For example the database does not know about any of your database devices. Any operations on the master database could make recovery impossible or at least much more complicated and time-consuming. A SQL Server started in master-recover mode is automatically configured to allow direct updates to the system tables. Certain other operations (for example, the checkpoint process) are disallowed. WARNING! Ad hoc changes to the system tables are dangeroussome changes can render SQL Server unable to run. Make only the changes described in this chapter, and always make the changes in a user-defined transaction. Restart SQL Server in single-user mode with the startserver command. Re-Creating Device Allocations for master Look at a hard copy of sysusages created before you ran buildmaster, or your most recent copy of this table. If it has only one line for dbid 1, your master database size has not been changed, and you can skip to the next step, "Checking Your Backup Server sysservers Information".

Page 5 of 11 Copyright 1999,2000 RFD & Associates, Inc. - www.rfdinc.com

Venice Systems www.venicesystems.com WARNING! If you have increased the size of master, and have user databases on the master device that are not backed up, you have a difficult recovery situation. You should call Technical Support for assistance before you proceed. If you have more than one row for dbid 1 in your hard copy of sysusages, you need to increase the size of master so that you can load the dump. You must duplicate the vstart value for each allocation for master in sysusages. This is easiest to do if you have a copy of sysusages ordered by vstart. In the simplest cases, additional allocations to master only require the use of alter database. In more complicated situations, you must allocate space for other databases in order to reconstruct the exact vstart values needed to recover master. In addition to the master database, tempdb (dbid =2 ) and model (dbid = 3) are located wholly or completely on the master device. In addition, there may be user databases wholly or partially on the device. If your master database is larger than 3MB, re-create its allocations in sysusages exactly. The size of master might be larger because of alter database commands or because earlier upgrades of SQL Server required a larger master database. If your Backup Server's network name (the name in the interfaces file) is not SYB_BACKUP, change the network name in sysservers. Check to see that your Backup Server is running. Use load database to load the most recent database dump of master. SQL Server stops automatically after successfully loading master.

Loading a Backup of master Load the most recent backup of the master database with load database. Here are examples of the load commands: On UNIX platforms: load database master from "/dev/nrmt4" On OpenVMS: load database master from "MTA0:" After the load database command completes successfully, SQL Server automatically shuts itself down. Watch for any error messages during the load and during the shutdown. Restart SQL Server in single-user mode with startserver. Use startserver to restart SQL Server in master-recover mode. Watch for error messages during recovery. Check the sysusages, sysdatabases and sysdevices tables in your recovered server against your hard copy. Look especially for these problems: If any devices in your hard copy are not included in the restored sysdevices, then you have added devices since your last backup, and you must run disk reinit and disk refit. If any databases listed in your hard copy are not listed in your restored sysdatabases table, you have added a database since the last time you backed up master. You must run disk refit. Loading the backup of master restores the "sa" account to its previous state. It restores the password on the "sa" account, if one exists. If you used sp_locklogin to lock this account before the backup was made, the "sa" account will now be locked. Perform the rest of these steps using an account with the System Administrator role

Page 6 of 11 Copyright 1999,2000 RFD & Associates, Inc. - www.rfdinc.com

Venice Systems www.venicesystems.com

If you have added database devices since the last dump of master, issue the disk reinit command to rebuild sysdevices. If you have run disk reinit, or if create database or alter database has been used since the last dump, make hard copies of sysusages and sysdatabases, and then issue the disk refit command to rebuild these system tables and shutdown SQL Server. Check for consistency: compare your hard copy of sysusages and sysdatabases with the new online version, run dbcc checkalloc on each database, and examine important tables in each database. If you restored the entire master device, restore the model database. If you are restoring only the master database, you can skip this step. If you are restoring the entire master device, you must also restore model:

Load your backup of model, if you keep a backup. If you do not have a backup: - Run the installmodel script: On UNIX platforms: cd $SYBASE/scripts setenv DSQUERY server_name isql -Usa -Ppassword -Sserver_name < installmodel On OpenVMS: set default sybase_system:[sybase.scripts] define dsquery server_name isql/user="sa"/password="password" /input=installmodel On PC platforms: For PC platform examples, refer to the SQL Server installation and configuration guide. - Redo any changes you have made to model.

Reload any affected user databases. If you had user databases stored on the master device and had to issue create database commands during the previous steps, reload your user databases with your usual load commands. Check syslogins if you have added new logins since the last backup of master.

If everything is correct, stop the server and use startserver to restart SQL Server for multi-user use. Once you have finished restoring the master database, use the shutdown command to shut down SQL Server. Then use startserver to restart in multi-user mode.

Dump the master database. When you have completely restored the master database and have run full dbcc integrity checks, back up the database using your usual dump commands. Restoring the Generic model Database buildmaster can restore the model database without affecting master.

Page 7 of 11 Copyright 1999,2000 RFD & Associates, Inc. - www.rfdinc.com

Venice Systems www.venicesystems.com WARNING!Shut down SQL Server before you use any buildmaster command. On UNIX platforms: buildmaster -d /devname -x On OpenVMS: buildmaster /disk = physicalname /model On PC platforms: For PC platform examples, refer to the SQL Server installation and configuration guide. Restoring model from a Backup If you can issue the use model command successfully, you can restore your model database from a backup with the load database command. If you cannot use the database: Follow the instructions above for using buildmaster to restore the model database. If you have changed the size of model, reissue the alter database commands. Load the backup with load database.

Restoring model with No Backup If you have changed your model database and do not have a backup: Follow the steps above for restoring a generic model database Reissue all the commands you issued to change model

Recovering the sybsystemprocs Database

The sybsystemprocs database stores the system procedures that are used to modify and report on system tables. If your routine dbcc checks on this database report damage, and you do not keep a backup of this database, you can restore it using installmaster. If you do keep backups of sybsystemprocs, you can restore it with load database.

How to clear a log suspend

SQL Server version 11.x includes a memory-based private log cache to reducecontention on transaction log writes, which can result in the following problematic scenario when using lct_admin("unsuspend"): 1. SQL Server cannot complete the kill and roll back the large or long-running transaction because the transaction log is full. 2. The full transaction log prevents SQL Server from flushing the contents of the private log cache to disk. 3. The database administrator must reboot SQL Server in order to terminate the transaction and free up transaction log space.Therefore, Sybase SQL Server 11.x database administrators must not executeselect lct_admin("unsuspend", dbid) when processes have become "LOGSUSPEND"ed.Solution--------If a very large or long-running transaction has prevented dump transactionfrom freeing sufficient space for processing to continue, SQL Server 11.xdatabase administrators should take one of the following two approaches: Approach 1 ----------Use alter database to add transaction log space to the database with the"LOG SUSPENDED"ed users: alter database database_name log on logdevice_name =3D size Approach 2----------Free up transaction log space held by the large or long-running transactionby following these steps: 1. Obtain the process id (spid) of the large or long-running transaction: select spid from master..syslogshold where dbid =3D dbid where dbid is the id of the database with "LOG SUSPEND"ed users. 2. Kill the large or long-running transaction: kill spid where spid is the output from step 1.

Page 8 of 11 Copyright 1999,2000 RFD & Associates, Inc. - www.rfdinc.com

Venice Systems www.venicesystems.com 3. Monitor the master..syslogshold table for a change in spid for the database with "LOG SUSPEND"ed users to determine whether the large or long-running transaction has been killed. ----------------------------------------------------------------- Note It can take some time for SQL Server to kill the large or long-running transaction. If you are concerned about the time, consider using Approach 1 instead of Approach 2. ------------------------------------1. Once the large or long-running transaction has been killed, issue a dump transaction command for the database with the "LOG SUSPEND"ed users. 2. Issue the sp_who command to determine whether there are still LOG SUSPENDed users for that database. If so, return to step 1, above.

As such, the log will grow as user connections affect changes to the database. The need arises to then clear out the log of all transactions that have been flushed to disk. This is performed by issuing the following command:

dump transaction my_db to logdump_for_my_db go

The SQL Server will write to the dumpdevice all transactions that have been committed to disk and will delete the entries from its copy, thus freeing up space in the log. Dumping of the transaction logs is accomplished via cron. It is advisable that you schedule the heavily hit databases every 20 minutes during peak times.

How to set TS Role

Some DBCC commands require that you set TS Role in order to run them. Here's how to set it: Login to Server as sa and perform the following: sp_role "grant", sybase_ts_role, sa go set role "sybase_ts_role" on go

DBCC Command Reference

allocdump( dbid, page ) bhash( { print_bufs | no_print }, bucket_limit ) buffer( [ dbid ][, objid ][, nbufs ], printopt = { 0 | 1 | 2 }, buftype ) bytes( startaddress, length ) checkalloc[( dbname [, fix | nofix ] ) ] checkcatalog[( dbname )] checkdb[( dbname [, skip_ncindex ] ) ] checktable( tablename | tabid [, skip_ncindex ] ) corrupt( tablename, indid, error ) 1133 error demonstrates that a page we think is an oam is not 2502 error shows multiple references to the same page 2503 error shows a breakage in the page linkage 2521 error shows that the page is referenced but is not allocated on the extent page 2523 error shows that the page number in the page or catalog entries are out-of-range for the database 2525 error shows that an extent objid/indid do not match what is on the page 2529 error shows a page number out-of-range for the database or a 605 style scenario 2540 error occurs when a page is allocated on an extent but the page is not referenced in the page chain

Page 9 of 11 Copyright 1999,2000 RFD & Associates, Inc. - www.rfdinc.com

Venice Systems www.venicesystems.com 2546 error occurs when an extent is found for an object without an of its pages being referenced (a stranded extent) 7939 error occurs when an allocation page which has extents for an object are not reflected on the OAM page 7940 error occurs when the total counts in the OAM page differ from the actual count of pages in the chain 7949 error is similar to a 7940 except that the counts are on an allocation page basis cursorinfo(cursor_level, cursor_name) where cursor_level - level of nesting. -1 is all nesting levels dbinfo( [ dbname ] ) dbrepair( dbid, option = { dropdb | fixindex | fixsysindex }, table, indexid ) dbrepair( dbid, ltmignore) dbtable( dbid ) delete_row( dbid, pageid, delete_by_row = { 1 | 0 }, rownum ) des( [ dbid ][, objid ] ) engine(eng func) where eng func may be: "online" "offline" extentcheck( dbid, objid, indexid, sort = {1|0} ) extentdump( dbid, page ) extentzap( dbid, objid, indexid, sort ) findnotfullextents( dbid, objid, indexid, sort = { 1 | 0 } ) fix_al( [ dbname ] ) help( dbcc_command ) ind( dbid, objid, printopt = { 0 | 1 | 2 } ) indexalloc(tablename|tabid, indid, [full | optimized | fast],[fix | nofix]) listoam(dbid, table_id, indid) - may supply dbname/tablename rather than id locateindexpgs( dbid, objid, page, indexid, level ) lock - print out lock chains log( [dbid][,objid][,page][,row][,nrecords][,type={-1..36}],printopt={0|1} ) memusage netmemshow( option = {1 | 2 | 3} ) netmemusage newalloc( dbname, option = { 1 | 2 | 3 } ) page( dbid, pagenum [, printopt={0|1|2} ][, cache={0|1} ][, logical={1|0} ] ) pglinkage( dbid, start, number, printopt={0|1|2}, target, order={1|0} ) pktmemshow( option = {spid} ) procbuf( dbid, objid, nbufs, printopt = { 0 | 1 } ) prtipage( dbid, objid, indexid, indexpage ) pss( suid, spid, printopt = { 1 | 0 } ) rebuildextents( dbid, objid, indexid ) rebuild_log( dbid, 1, 1) - careful as this will cause large jumps in your timestamp values used by log recovery. resource setkeepalive(# minutes) - for use on Novell with TCP/IP. settrunc('ltm','ignore') - this command may be usefull for a dba who is dumping and loading a database that has replication set on for the original db. show_bucket( dbid, pageid, lookup_type ) tab( dbid, objid, printopt = { 0 | 1 | 2 } ) tablealloc(tablename|tabid, [full | optimized | fast],[fix | nofix]) traceoff( tracenum [, tracenum ... ] ) traceon( tracenum [, tracenum ... ] ) tune( option, value ) - switch on any option immediately without having to reboot the SQL Server. Switches correspond to the old (pre-System 11) buildmaster -yall minus the c prefix

Page 10 of 11 Copyright 1999,2000 RFD & Associates, Inc. - www.rfdinc.com

Venice Systems www.venicesystems.com For example option may be: indextrips oamtrips datatrips schedspins bufwashsize sortbufsize sortpgcount maxscheds max_retries undo( dbid, pageno, rowno )

Page 11 of 11 Copyright 1999,2000 RFD & Associates, Inc. - www.rfdinc.com