o reilly Unix Backup and Recovery phần 8 potx

setup. Also, if additional EBFs (Sybase patches) or upgrades were installed, they will have to be reapplied. It is much quicker to restore from a single backup of these directories. Restoring from a Hot Backup Sybase reduces the time it takes to perform a hot backup by saving only the pages that contain data. It also saves them exactly as they are on the devices and in the order they are found in the database. Because of this, the recovery requires that the database be re-created with exactly the same layout it had before the recovery. In other words, if the database was created with a 40-MB default segment and a 10-MB log segment, and at a later point, an additional 40-MB was added to the default segment, then the database needs to be re-created with a 40-MB default segment and 10-MB log segment and then altered to add the last 40-MB. Otherwise, when the load of the hot backup occurs, Sybase will do unpredictable things with the allocation. In the previous example, these commands would be create database mydb on mydefseg = 40, mydefseg = 40 log on mylogseg = 10 alter database mydb on mydefseg = 40 Once the database creation is complete, the full dump of the database needs to be applied using the load command. The load command has all of the same parameters as the dump command. It needs to know what to restore, from where to get it, and how to get it from there. To restore from a tape, use exactly the same parameters as were used to create the tapes. First, restore the full database backup to the database. This will give you a base point against which to restore all the transaction logs. Example 16-3 contains a sample load of a full database dump. Example 16-3. Sample load database Command 1> load database mydb from '/sybase/backups/mydb.990312.bck' 2> go Backup Server session id is: 26. Use this value when executing the 'sp_volchanged' system stored procedure after fulfilling any volume change request from the Backup Server. Backup Server: 6.28.1.1: Dumpfile name 'mydb9909106EF4 ' section number 0001 mounted on disk file '/sybase/backups/mydb.990312.bck' Backup Server: 4.58.1.1: Database mydb: 17926 kilobytes LOADed. Backup Server: 4.58.1.1: Database mydb: 19462 kilobytes LOADed. Backup Server: 4.58.1.1: Database mydb: 19470 kilobytes LOADed. Backup Server: 3.42.1.1: LOAD is complete (database mydb). Use the ONLINE DATABASE command to bring this database online; SQL Server will not bring it online automatically. Page 557 If there are no transaction logs for this database, then as the command output says, this database could be brought online. Enter the online database baddbname command to have Sybase bring it up and make it available for use. If there are transaction logs, they will need to be applied to bring the database up to the most current point possible. Use the load transaction command to apply a transaction log to the database. To restore the transaction logs for the database mydb in the preceding dump example, enter the command shown in Example 16-4. Example 16-4. Sample load transaction Command 1> load transaction mydb from '/sybase/backups/mydb.tlogdmp' 2> go Backup Server session id is: 28. Use this value when executing the 'sp_volchanged' system stored procedure after fulfilling any volume change request from the Backup Server. Backup Server: 6.28.1.1: Dumpfile name 'mydb9909106F49 ' section number 0001 mounted on disk file '/sybase/backups/mydb.tlogdmp' Backup Server: 4.58.1.1: Database mydb: 24 kilobytes LOADed. Backup Server: 3.42.1.1: LOAD is complete (database mydb). Use the ONLINE DATABASE command to bring this database online; SQL Server will not bring it online automatically. Repeat the transaction logs loads until there are no more transaction logs to apply. When they are done, the database has been restored completely and should be brought online using the online database baddbname command. Because of a quirk in some versions of Sybase on some platforms, the preceding loads might not work for using the physical devices. To get by this "feature," you can use logical devices instead. The only differences in the examples would be changing the physical device to a logical device after the logical dump device is created. For more information on how to create logical dump devices, see the definition of dump devices under "The DBA's View," near the beginning of this chapter. As of Sybase Version 11.92, a database can now be restored up to a specific point in time as long as it is covered by a transaction log dump. To specify the time to which the database should be restored, use the new until_time parameter. This parameter takes a single value of a time and date in the default format for the data server. For example, to restore a database up to April 1, 1999, at 12:34:32:650 A.M., first apply the full database dump, then apply all transaction log dumps up to the one that contains the stop time. With this dump, add until_time, like this: load transaction mydb from '/sybase/backups/mydb.tlogdmp' with until_time = 'April 1, 1999 at 12:34:32:650AM' Page 558 Once the database has been restored and brought online, it is important to check all the major objects in the system and validate the data. Run a number of queries on the database tables to make sure the data is as it should be and then check the consistency of the database structure using the dbcc checkalloc. When all of these checks have been passed, do a full database dump to make sure a consistent recent backup is on hand in case additional problems arise. Also, it will save time because none of the transaction logs restored earlier will need to be restored again. Using the Recovery Procedure Recovering from a database problem starts with diagnosing exactly what is wrong with the database. Maybe isql will not connect to the data server, maybe the database is marked suspect, or maybe an error message in the error log occurs when the data server is started. In all of these cases and others, something has gone wrong where it had gone right before. Fortunately, with the proper backups, many of these problems can be fixed and the database restored to full working order. Sybase has many parts that are interrelated, but like Sherlock Holmes investigating a mystery, if we eliminate from consideration the items that are working correctly, only the error-causing parts will remain. This section provides step-by-step directions to diagnosing and repairing all of these error-causing parts, and when completed, will leave a fully functional data server. A flowchart that appears at the beginning of these steps (Figure 16-1) should help you in the recovery process. Each item in the chart is numbered the same as the steps and procedures that follow. The electronic version of this procedure* contains a flowchart that is an HTML image map. Each decision or action box in the flowchart is a hyperlink to the appropriate section of the printed procedure. For more detailed information about individual steps, please consult Sybase's System Administration documentation, especially the ''Backup and Recovery" chapter. To begin the investigation, start the data server as it is normally started. If problems show up in the Sybase error log file or the data server does not come up, start with Step 1 to begin the recovery/diagnosis procedure. Step 1: Runfile OK? Sybase starts up by using the startserver program. This program takes an additional parameter -f runfilename that is the file containing the server startup command and parameters. If this file is missing or the path given for the runfile is * It is available at http://www.backupcentral.com and on the CD that comes with this book. Page 559 Figure 16-1. A Sybase recovery flowchart Page 560 incorrect, the startserver command will return an error Cannot execute file runfilename. If the path is incorrect for the file, correct it and start again. If you are unsure of the path being used, change your directory to the location of the runfile, then run the command, but specify only the runfile name. Sybase then will try looking in your current default directory for the file. If the runfile is OK, proceed to Step 3. If not, go to Step 2. Step 2: Restore or Re-create Runfile If the file is missing, it can be re-created fairly easily. There is nothing magical about this file. It contains the command and parameters to start the server. Example 16-5 contains a sample runfile for a Unix system. Example 16-5. Sample Runfile #!/bin/sh # # SQL Server Information: # Name: SYB_TITANIA # Master device /sybdata/master.dbf # Master device size: 10752 # Errorlog: /opt/sybase/logs/SYB_MYDB.errorlog # Interfaces: /opt/sybase # /opt/sybase/bin/dataserver -d/sybdata/master.dbf -sSYB_MYDB \ -e/opt/sybase/logs/SYB_MYDB.errorlog -i/opt/sybase As seen in the comment lines, dataserver takes a number of different parameters. Again, check Sybase's documentation for your OS for more details. The most important parameter shown is the master device. The master device is the primary device used by the master database, and the master database is one of the keystones of a Sybase server. The master database contains a majority of the information about all the other databases, devices, and other data server objects, including the location of the master device. The -s dataservername is how the data server knows what name to call itself. If this is omitted, Sybase assumes a data server of the name SYBASE is being started. The -e errorlog point to the full filename and pathname ofthe data server's error log. During an install, Sybase defaults to the$SYBASE/install directory. Because this directory containsa number of important files other than the error log, it is recommended thatthis be changed to point to another directory, maybe Page 561 $SYBASE/logs/. Also, if there is more than one data server on the system, the errorlog filename should be changed. Appending the .errorlog suffix to each data server name provides each server with its individual errorlog file, making tracking down errors much simpler. The next parameter to look at is the interface parameter, -i interfacedir. This is the directory where Sybase can find the interface file. In some systems, there might be two interface files-one or more for the users to use and one for the Sybase system to use. The different interface files could contain different selections of server entries, preventing the users or the data server from accessing all the Sybase servers available. If this parameter is omitted, Sybase will look in the directory pointed to by $SYBASE environmental variable. One parameter that is not shown here is the configuration file parameter -c configfile. As of Version 11, Sybase can be started using a configuration file. This file contains the text of all the configuration options on the data server and their values. When no -c parameter is specified, Sybase defaults to the file servername. cfg found in the directory where the data server is started. The Origins of the Configuration File Before Version 11, all configuration parameters were kept only in tables in the master database. When a configuration option was changed and required a restart of the data server, the data server might not come up because of this change. Because the server was not up, there was no way to reset the option except by running a command to reset all the options to their default values. They then had to be reset to their values before the final incorrect option change. In other words, a real pain in the you-know-what. Now, the configuration file contains all these options in an easily edited file. To revert a value back, a text editor can be used to change the value in the file. When the data server is next restarted with the reverted values, the data server will restart cleanly. Two additional parameters can be used with the dataserver program-the version parameter -v and the single-user mode parameter -m. The version number parameter is handy to use when you need to see the current version of the database program, and do not want to search for it in the error log. The single-user, or maintenance, mode -m is used to bring the data server up so only the sa account can access the data server. This is required when doing certain recovery procedures and, in general, when there is a need to prevent user access while maintenance is being done. Page 562 It is easy to re-create this file by using a text editor to create a script like the preceding one, but with the values of your data server. Once the file is created and the account that starts the data server has access to it, run the startserver -f runfile command. Once you've replaced the runfile, return to Step 1. Step 3: Able to Get Shared Memory? Like most database products, Sybase uses shared memory to communicate between data server processes, process queries, and store sections of the database for quick access. If Sybase is prevented from acquiring the minimum shared memory it needs, it will fail to come up and instead will error out with a message like the following: 00:1999/03/21 23:39:02.78 kernel os_create_region: can't allocate 2147479552 bytes 00:1999/03/21 23:39:02.80 kernel kbcreate: couldn't create kernel region. 00:1999/03/21 23:39:02.80 kernel kistartup: could not create shared memory If you are able to get to shared memory, proceed to Step 5. If not, proceed to Step 4. Step 4: Free Up Shared Memory or Reconfigure Memory in Configuration File As mentioned earlier, changes in configuration parameters can cause the Sybase server to need additional memory. This in turn can require the Sybase server to request a larger shared memory segment from the OS. There are two things that can prevent this from happening: 1. The maximum shared memory segment size is undersized. 2. There is not enough shared memory on the system to allow this to run. In the first case, the solution is to increase the maximum shared memory segment value appropriately for the OS. Because Sybase is supported on many different Page 563 OSs, how to change this is not shown here. Please refer to the appropriate operating system Sybase installation manual for further information on setting this value. In the second case, either shared memory needs to be added to the system, or shared memory needs to be freed up from other processes. Please contact a system administrator for help in accomplishing either of these. You can view the shared memory being used by using the ipcs command. Check the manpages for the correct usage of the command, but the output should look something like this: Shared Memory Segments shmid owner perms bytes nattch status 129 sybase 600 11964416 1 2 sybase 666 1024 3 56 curtis 606 33334342 3 Here, the curtis process has also taken some of the shared memory for itself. By stopping this process, the shared memory should be freed up. If stopping the process does not free up the memory, it can be freed using the Unix command ipcrm. Again, check the Unix manpages for more information on this command on your operating system. If none of these solutions helps the problem, the changes in the configuration options will need to be reverted to allow the data server to come up correctly. If possible, make one change to the configuration options at a time. Sybase configuration options interact, some causing the system to need more memory, others less. By making one change at a time, the configuration option that prevents the system from restarting is known and can be adjusted accordingly. Once you have corrected these problems, return to Step 1. Step 5: Able to Connect to Data Server? When Sybase starts, it needs the interface file so it can set up all the interprocess and network communication parameters. This interfaces file is usually named interfaces, interface, or sql.ini, depending on the operating system. If you are able to connect, proceed to Step 7. If you are unable to connect, go to Step 6. Page 564 Step 6: Check Interface File If Sybase cannot find the file or there is something wrong with it, Sybase will error out during startup with a message like one of the following: 00:1999/03/22 00:17:46.54 kernel Could not open interface file '/opt/sybase/interfaces' 00:1999/03/22 00:22:16.15 kernel Could not find name 'SYB_MYDB' in the interfaces file /opt/sybase/interfaces To correct the first error, make sure the interface file is located where the runfile says it should be located. If the interface file is in a different directory, either adjust the runfile to point to the correct directory or move the interface file to the directory specified in the runfile. The second entry means the lines for the data server being started (in this case SYB_MYDB) cannot be found in the interface file. To fix this problem, add an entry using the appropriate method for your operating system. Please see the Sybase OS-specific documentation for more information. Once the entry is in the correct interface file, rerun the startserver command to see if this has fixed the problem. Once you have corrected any problems with the interface file, return to Step 1. Step 7: Master Database Initialized? The master database is the most important database in the system: not only does it contain all the information about all the other databases but also it is the repository of all information regarding logins, roles, devices, usages of those devices, and configuration options on the system. It is imperative that this database comes up correctly. Otherwise, the rest of the data server would not work at all. If the master database did initialize, proceed to Step 14. If it did not, go to Step 8. Page 565 Step 8: Master Device/File Missing? The first information that something is wrong with the master database would most likely be the following error messages displayed during startup: 00:1999/03/22 00:53:48.44 kernel kdconfig: unable to read primary master device 00:1999/03/22 00:53:48.44 kernel kiconfig: read of config block failed These lines are preceded by a line that will tell you why the system could not read the primary master device. To fix these problems, go to Step 15. If none of the solutions in that section corrects the problem, you must restore the master database (go to Step 9). If there are no problems accessing the master data device, then the problem might be the master database has been corrupted. This type of problem could show a number of strange symptoms if the data server was already running. For example, isql will crash with program errors when trying to connect, or currently running queries will crash. If strange things like these start happening, the best thing to do is to try to restart the data server. However, in situations like this, almost all access to the data server will be blocked, so the isql command shutdown cannot be used normally. Instead, the dataserver process must be stopped at the operating system level. In Unix, this can be done using the kill command. This should be used only during extreme situations such as when the data server is consuming all the processing of the system. Use kill only if nothing else will help, because it could cause corruption of the databases in the data server. Once the data server is down, check to make sure memory used by Sybase has been freed. See Steps 3 and 4 for more information on shared memory. When the shared memory has been freed, try starting the data server using normal starting procedures. If the data server fails to start, see if there are errors on the master device in the data server error log. Go to Step 15 and make sure there are no problems there. If there are, correct the problem with the device, and try restarting again. If there are no problems with the physical devices, the master database will need to be completely recovered from backup. Page 566 If there are any problems with the physical devices, proceed to Step 9. Otherwise, proceed to Step 10. Step 9: Restoring Generic Master Database Follow these steps to restore the generic master database: 1. Backup server up? Make sure your backup server is up and running. It will be used later to restore any backups of the master database and to back up the restored database when the recovery is finished. 2. Create data device. Since the master device was corrupted, it must be created anew. Open up the runfile used to start the Sybase server in a text editor. Note the master device path and the size of the master device; they will be used in the buildmaster command to re-create the master device. To re-create the master device, enter the following buildmaster command or the OS equivalent needed by the downed server: buildmaster -d /sybdata/master.dbf -s 8704 The -d option is the master device path and the -s option is the size in pages. For this example, the master device being created is 17 MB (8704 2-K pages) on /sybdata/master.dbf. 3. Startup in master recovery mode. To start the data server in master recovery mode, first make a copy of the current runfile. Edit this file, and add the -m master recovery mode parameter. When the change is done, use this file to start the dataserver process with the startserver -f master_runfile command. This mode will allow the master database's system tables to be updated and prevent users from accessing the system. 4. Re-create master's entries in usages. Before anything more can be done to restore the data into the master database, the master device needs to be restored to the same usage as it was when the last backup of the master database was performed. Using hardcopies of the system tables sysusages, sysdevices, and sysdatabases, the entries in sysusages can be re-created with the alter database and create database commands. [...]... not allow load of the transaction logs to occur out of order In fact, if any of the logs are missing or corrupt, the rest of the logs cannot be applied To load the transaction logs for our preceding example, enter the following command, repeating it for each transaction dump load transaction baddbname from '/dev/nrmt0' For more information on how to load dumps and transaction logs, please refer to... echo &llquo; Usage: $0 (Will lock or unlock all clearcase vobs on this server )" exit 1 fi HOST='hostname¦awk -F '{print $1}'' #Get a list of all vobs on this server VOBS='cleartool lsvob -host $HOST¦sed 's/*//' ¦awk '{print $1}'' case $1 in lock ) for VOB in $VOBS ; do # (Lock VOBS) cleartool lock -c 'VOB backups in progress' -vob $VOB \ > /tmp/voblock.log 2>&1 done ;; unlock ) ... proceed to Step 11 If one does not exist, go to Step 13 Step 11: Restore Master from Dump Use the following T-SQL command to load the backup of the master database into the system You might have to change the ''from" section of the command to match what is needed for your operating system and environment Review the section "Restoring from a Hot Backup" for more information When the backup finishes, the data... can be done Common strategies for doing a VOB backup include (but are not limited to): standard and snapshot (the two most common), disk backup, and the use of mirrors Since the main thrust is the backing up of the physical storage directory, there are many ways this can be accomplished, including the use of commercial tools Standard strategy The standard backup procedure is to "lock" the VOB, thereby... that, when they needed them, were completely useless Page 589 VI BACKUP & RECOVERY POTPOURRI Part VI consists of the following three chapters: • Chapter 17, ClearCase Backup & Recovery, describes backup and recovery of ClearCase, a software configuration management tool • Chapter 18, Backup Hardware, provides information on the characteristics of, and trade-offs among, various hardware architectures • Chapter... host; the second line should have the name(s) of one or more hosts to be backup registry servers, that is: primary_registry_host first _backup_ host, second _backup_ host 2 Copy the ~gy.host.conf file to the /usr/adm/atria/rgy directory on every client host (including the backup registry host(s)) 3 Usually, the rgy _backup program runs automatically once a day on each backup registry host However, if you... other two parts, if left out, will default to the default database and the username of the data server login used to run the command Page 584 The bcp utility is used to copy the data in and out of the database table Choose in to copy the data from a file into a table Choose out to copy the data from a table to a datafile The datafile is the path of a file in which to place the data or from which to get... restore the files, and restart the albd_server The actual restore can be done using the same tools that were used to create the backup 1 On the secondary server (first _backup_ host), execute the following command: $ rgy_switchover -backup "second _backup_ host primary_registry_host" primary_registry_host first _backup_ host 2 For any client that was down or for some reason unreachable by the network (record... to the databases and objects in the data server To make sure the suids are the same, compare the hardcopy of the syslogin system table and the online version of the table If they do not match, there could be problems Refer to Sybase's Security Information Guide for more information on re-creating changes to logins if the original scripts cannot be found Another are of Sybase's security is login roles... one or more users-to edit source versions, compile them into object modules, format them into documents, and so on Users in different views can work with the same files without interfering with one another For each element in a VOB, a view's configuration specification selects one version from the element's version tree Each view also can store view-private files and view-private directories, which do . to change the ''from" section of the command to match what is needed for your operating system and environment. Review the section "Restoring from a Hot Backup& quot; for more information using the load command. The load command has all of the same parameters as the dump command. It needs to know what to restore, from where to get it, and how to get it from there. To restore from a. Unix command ipcrm. Again, check the Unix manpages for more information on this command on your operating system. If none of these solutions helps the problem, the changes in the configuration