This chapter describes the following types of fixed and open problems:
Fixed problems in Backup Toolkit V4.2.3/4.4.3 and SAMS:Alexandria V4.50.70
Fixed problems in Backup Toolkit V4.2.2/V4.4.2 and SAMS:Alexandria V4.50.53
Fixed problems in Backup Toolkit V4.2.1/V4.4.1 and SAMS:Alexandria V4.50.17a
Open SAMS:Alexandria problems that only impact ACSLS-connected library usage
The numbers in parentheses identify the problems in the problem-tracking system. You should also refer to the SAMS:Alexandria Release Notes for fixed and open problems against SAMS:Alexandria.
This section lists the following information about problems that are fixed in the current release of Backup Toolkit and SAMS:Alexandria. No problems were fixed in Backup Toolkit V4.2.3/4.4.3.
The following problems, which are specific to using SAMS:Alexandria on a DYNIX/ptx host or found on a DYNIX/ptx host, have been fixed in SAMS:Alexandria V4.50.70:
(245838) The RPF formatter failed to restore the correct owner and group for directories during Restore operations.
(246561) Tape drives went offline when ACSLS auto-cleaning operations exceeded 5 minutes on an STK 9710 or STK 9740 library because SAMS:Alexandria did not recognize the STATUS_PENDING response from the ACSLS server.
(248827, 248828) StackCopy used incorrect syntax when it issued commands to shut down sscldaemon processes on DYNIX/ptx v4.2.x, which caused unexpected results or failures.
(250767) RPF Restore operations to a raw partition failed when the physical size of the volume was evenly divisible by Alexandria's tape block size (65536) minus the block header (1024). That is, evenly divisible by 64512 (which is 65536-1024).
(251111) SAMS:Alexandria contained a potential security problem that was identified during internal code review. (This problem was very unlikely to be exposed and was not reported by any customers.)
(251632) SAMS:Alexandria Store operations failed with Store Operation found Aborted when the USE-UNIQUE-MEDIA-OPCARD configuration option was used.
The following problems, which were found on a DYNIX/ptx host, have been fixed in SAMS:Alexandria COBRA V4.50.70:
(246429) COBRA started child Store operation cards after ensuring that devices were configured online, but before ensuring that the devices were not being used by another Store operation. If no devices became available before the number configured for FAILURE-RETRIES had been exhausted, the entire COBRA Store operation failed. This problem is resolved by setting the SSW_WAIT_ON_DEVICE=32 environment variable in the parent COBRA Store operation card. For more information on this environment variable, refer to "Changes in Backup Toolkit V4.2.3 and V4.4.3." in Chapter 1 of these release notes.
(247796) COBRA Store operations issued a query to the v$archived_logs table that took an excessive amount of time to complete.
(249920) COBRA dumped core when a hot backup and a log backup were run simultaneously, which caused one of the backups to fail. Now, both hot and log backups can occur simultaneously.
(250083) Rescanning a tape that contained a COBRA stack returned errors, some that meant the scan had really failed and was incomplete and some that were false errors since the scan had actually been successful.
(250667) COBRA Store operations did not execute the actions designated in the USER-PRE-DB-RESTART and USER-POST-DB-RESTART keywords when the SKIP-SHUTDOWN ALL keyword was used.
(251596) The SAMS:Alexandria Database table "Optimize-Search" could grow exponentially large when frequent repetitive COBRA backups were run from the same Store operation card.
This section lists the following information about problems that were fixed in the last release of Backup Toolkit and SAMS:Alexandria:
The following problems are fixed in Backup Toolkit V4.2.2 and V4.4.2:
(240336) SetupHD.Seq always defaulted to the d20 density when configuring DLT tape drives regardless of the version of ptx/SPDRIVERS that was being used. Now, on hosts running the following software, the default density when configuring DLT tape drives is unspecified (" "):
(244749, 245842) The genop sample Store operation card provided in /usr/alexbkup/local/bin did not exclude the CD-ROM drive from the Store operation. When the CD-ROM was mounted and a GenOp Store operation was executed, this problem caused the Store operation to fail. Now, the DF-XCL option has been added to the sample genop operation card to exclude the CD-ROM drive from the Store operation.
(246801, 247199) Output messages from SetupHD.Seq incorrectly stated that DLT4000 tape drives were being configured when it was actually DLT7000 tape drives that were being configured. Only the output messages were incorrect, the SAMS:Alexandria device configuration was correct.
(247372) The genop sample operation card provided in the /usr/alexbkup/local/bin directory contained incorrect syntax in the FULL BEGIN-COMMAND and INCR BEGIN-COMMAND lines.
(248124) The setup_acs script did not have a usage message, provide clear prompting, or provide default values. This script has been enhanced to provide a usage message when run with the -? option and to provide clearer prompts and default values.
(248280) The cobra_cvt script could not be used with operation cards that backed up archived redo logfiles. The cobra_cvt script can now create COBRA V4.50 operation card template files from ptx/OSBM (COBRA v3) operation cards that back up archived redo logfiles.
The following problems, which are specific to using SAMS:Alexandria on a DYNIX/ptx host or found on a DYNIX/ptx host, have been fixed in SAMS:Alexandria V4.50.53:
(244868) The SAMS:Alexandria Java-based interface could not configure the first device for use with the Transfer Manager. The first device had to be configured from the command line with the alex-xfer command and then the Java-based interface could be used to configure devices for use with the Transfer Manager.
(245546) SAMS:Alexandria RPF Restore operations did not create more than 3 levels of directories, which caused Restore operations to fail when the destination directory structure did not completely exist.
(245711) The SAMS:Alexandria Java-based interface could not be used with operation cards created from the command line and used invalid default settings for the MAX-RESOURCE-USAGE and CONFLICT-CONTROL-THRESHOLD keywords.
(245883, 245884) The StackCopy utility failed when running on DYNIX/ptx v4.2.x because it could not shutdown sscldaemon processes.
(246205, 247159) The online backup of the SAMS:Alexandria database sometimes corrupted the Detail-File and Detail-Dir tables when it was restored from a housekeeping tape. Symptoms of this problem were that the ErrorMsgs file showed errors against these tables, a restore of the -ROOT_USR- operation card silently failed to restore some files, or the sldbdaemon died.
(246446) Instead of displaying the actual values of an existing operation card, the SAMS:Alexandria Java-based interface displayed default values for a new operation card. (The correct values for the operation card were displayed by the alex-xfer command.)
(248475) Running an AlexClient/NT Java GUI Store operation card to store filesystem backups on Windows NT failed with a Dr. Watson error on the Windows NT client, which caused alex-xfer to dump core on the SAMS:Alexandria server host.
The following problems, which were found on a DYNIX/ptx host, have been fixed in SAMS:Alexandria COBRA V4.50.53:
(243975) Concurrent COBRA hot and archived redo log Store operations sometimes caused duplicate records in the SAMS:Alexandria database, which then caused all subsequent Store operations with that Oracle instance to fail.
(244077) Devices specified in the DEVICE_POOL of a COBRA Store operation card were selected for use even when they were configured as inactive in the SAMS:Alexandria hardware configuration.
(244078) The output from cobraquery truncated long datafile names and stacks. Now, the -l option has been added, which outputs the report in long format.
(245818) COBRA did not backup all Oracle parameter files defined by multiple ifile parameter declarations, only the file pointed to by the last ifile parameter declaration was backed up.
(245961) The SQL queries used by COBRA to collect the information from Oracle databases with a large number of tablespaces and datafiles resulted in a significant delay during the query phase, which substantially delayed the start of the data backup.
(246306) When cobraquery created COBRA Restore operation cards from store operation stacks that used resource maps, cobraquery incorrectly put the single disk resource number (res-disk-priority) as the last field on each of the RESTORE-FILE keyword lines. When these restore operation cards were run, files were incorrectly restored in the root filesystem.
(247041, 248151) Media that contained multiple COBRA store operation stacks returned failure messages about bad dbid when detail reassigning was performed. Scanning the media a second time succeeded, but cobraquery failed to show all the store operation details.
This section lists the following information about problems that were fixed in the last release of Backup Toolkit and SAMS:Alexandria:
The following problems were fixed in Backup Toolkit V4.2.1 and V4.4.1:
(240640) SetupHD.Seq failed on STK 9730 libraries on DLT7000 tape drives.
(241921) cobra_cvt incorrectly set the value of MAX-DEVICES.
(242242) Sample COBRA V4 operation cards included default examples that were too specific.
(242409) The cobra_cvt script needed to automate more of the conversion from COBRA v3.0 to COBRA v4.00.
(242597) cobra_cvt failed on operation cards with names containing "n."
(243065) cobra_cvt did not set the remote host name.
(244274) cobra_cvt did not recognize incl_tablespace and parallel_reads.
(244377) SetupHD.Seq erroneously set up cleaning in a STK 9730 library.
(245293) When EMC® disks had redundant paths, the systeminfo script captured VTOC information via each path. This resulted in the VTOC information being listed multiple times in the drinfo.out file when it only needed to be listed once per disk.
The following problems, which are specific to using SAMS:Alexandria on a DYNIX/ptx host or were found on a DYNIX/ptx host, have been fixed in SAMS:Alexandria V4.50.17a:
(234471) SAMS:Alexandria dumped core and failed to store a file when its name contained an embedded '\n' character.
(244708) The SAMS:Alexandria database update failed during an upgrade from ptx/ESBM (Alexandria V3.80) to SAMS:Alexandria V4.50.
(246617) The installation of the SAMS:Alexandria AlexClient/NT personality from the V4.50.17 distribution CD-ROM failed because of a corrupt file on the CD-ROM.
The following problems have been reported against Backup Toolkit.
On hosts running DYNIX/ptx V4.2.x, during SAMS:Alexandria startup, the /etc/init.d/alex start command provided by Backup Toolkit fails to build the passthrough device file for a library when that library contains a faulty tape drive or drives. The following message is displayed when this error occurs during startup:
devbuild : slpt : /dev/mch/ms0 (or associated device) in use
After the failure, the library cannot be accessed by SAMS:Alexandria. The fault of the tape drive is that it is not responding to operating system commands and therefore does not exist in the kernel. For example, the output from the mc command will list the total number of drives, but the output from the dumpconf command will show only the drives that the operating system recognizes. The faulty drives will not be listed in the dumpconf output. This problem does not apply to Backup Toolkit on hosts running DYNIX/ptx V4.4.x, V4.5.x, or V4.6.x. This problem was first reported against ptx/ESBM.
Workaround. Contact IBM Customer Support to replace the faulty drive.
The systeminfo script provided by Backup Toolkit does not output any warnings when the system configuration has changed such that you need to build a new custom miniroot tape. Some events that require the creation of a new custom miniroot include installing or updating operating system and layered product software or changing the kernel configuration. This problem was first reported against ptx/ESBM
Workaround. Be sure to create a custom miniroot tape any time the system configuration changes. For hosts running DYNIX/ptx V4.2.x, details on when a custom miniroot should be created are provided in Chapter 5, "Disaster Preparation," of the Backup Toolkit Administration Guide for SAMS:Alexandria, part number 1003-75171-03. For hosts running DYNIX/ptx V4.4.x, V4.5.x, or V4.6.x, details on when a custom miniroot should be created are provided in Chapter 1, "General Disaster Preparation," of the DYNIX/ptx V4.4 System Recovery and Troubleshooting Guide, DYNIX/ptx V4.5 System Recovery and Troubleshooting Guide, and the DYNIX/ptx V4.6 System Recovery and Troubleshooting Guide.
When installalex fails, it incorrectly says to rerun the .restore_config script, as in the following output:
# ./installalex Fri Dec 4 13:25:23 PST 1998 - install Starting installation. * Running Preliminary Checks for Alexandria Install... * Error: .restore_config The alexandria Daemons are running. Please Shut Alexandria down and rerun '.restore_config' ******************************* ERROR: INSTALL IS BEING ABORTED ******************************* Fri Dec 4 13:25:25 PST 1998 - Alexandria V4.50.02 PN: BKTK-ALEXANDRIA (install aborted)
Workaround. Ignore this internal-only script reference. After resolving the error condition, just re-run installalex. In the example above, you would resolve the error condition by shutting down the SAMS:Alexandria daemons.
The following problems, which are specific to using SAMS:Alexandria on a DYNIX/ptx host, have been reported:
SAMS:Alexandria is not compatible with extended fundamental types that are supported in DYNIX/ptx. For this reason, SAMS:Alexandria can save only those files that have 16-bit user IDs and group IDs. If you are using SAMS:Alexandria with these DYNIX/ptx versions, ensure that your system uses only user ID and group ID values less than or equal to 60,002. (By default, the ptx/ADMIN menu system limits user ID and group ID values to 60,000.)
If you try to back up files with 32-bit user and group IDs, SAMS:Alexandria will output messages similar to the following in the stack history:
FAULT: [109-009] System Call `open' failed. Error: Value too large for
defined data type (79).
MESSAGE: [109-000] Open called with filename `/usr/alexbkup/Store/Xhost1.47'
mode 02402 perms 0666.
MESSAGE: [817-000] Store Op-Card `motd.op' failed to run successfully.
Workaround. None.
If the audit feature is enabled in DYNIX/ptx, SAMS:Alexandria generates excessive error messages in the audit log file /usr/spool/audit/audit_log. Errors are reported about user alexbkup and are logged as frequently as every 30 seconds. This problem causes the audit_log file to grow rapidly and eventually fills up the /usr filesystem.
Workaround. Monitor the audit_log file and truncate or remove the file.
On hosts running DYNIX/ptx V4.2.x and ptx/SVM V1.5.x, if the ptx/SVM volumes are stored or restored through the use of symbolic links, the following error message is logged to the .Messages file for each volume stored or restored:
WARNING: [770-013] System Call `utime' failed. Error = Read-only file
system (30).
These messages do not cause any store or restore stack warnings and do not affect the success of the operation. However, the quantity of messages can make the .Messages file difficult to review for legitimate error conditions. This problem does not apply to hosts running DYNIX/ptx V4.4.x, V4.5.x, or V4.6.x and ptx/SVM V2.x.x. This problem was first reported against ptx/ESBM.
Workaround. None.
When configuring devices in SAMS:Alexandria, you designate the SCSI ID of the device. A problem exists in SAMS:Alexandria when it is used on hosts running DYNIX/ptx V4.2.x such that the value entered for the device SCSI ID is truncated to one decimal digit, thereby limiting the SCSI ID to a value from 0 to 9. The problem occurs when the SCSI ID, which is always treated as a hexadecimal value, is converted to a decimal string and truncated to one digit. For example, the value of 14 is truncated to 0, since hex 14 is 20.
This problem does not impact currently supported SAMS:Alexandria devices such as DDS-2, DDS-3 and DLT4000 libraries and tape drives. However, it will impact backup devices that support fast, wide SCSI, such as the DLT 7000 tape drive. This problem does not affect SAMS:Alexandria versions that run on DYNIX/ptx V4.4.x, V4.5.x, or V4.6.x.
Workaround. Limit the SCSI IDs for all SCSI devices to a value from 0 to 9 when using SAMS:Alexandria on hosts running DYNIX/ptx V4.2.x.
The following SAMS:Alexandria problems that were found on a DYNIX/ptx host have been reported. For other SAMS:Alexandria problems that have been reported, refer to the SAMS:Alexandria Release Notes.
When creating Restore operation cards, you can define directory filters and file filters to limit the scope of files restored. However, there is no way to designate the file filters that should be used with a specific directory filter. This problem can cause unexpected results when a file with the same name exists in more than one directory and you are trying to restore that file as part of a restore operation that includes multiple directory filters.
When this scenario exists, the restore operation can recover more files than you intended, for example, all files of the same name in all directories specified. Alternatively, the restore operation can recover different files than you intended, for example, if you inadvertently request a file that has never been backed up and a file with the same name has been backed up in a different directory that matches one of the directory filters.
Workaround. Create one Restore operation card for each directory filter you want to apply.
With any of the SAMS:Alexandria storage formats, if the disk to which you are restoring becomes full, SAMS:Alexandria does not indicate that the disk is full. Instead, it displays a misleading error message and fails the recovery. For example, the message displayed during a failed recovery using the RPF storage format is similar to the following:
FAULT: [770-004] Incorrect amount of data written to `/tmp/Op-List.39'
The message displayed when using the Alexandria, Tar, and CPIO storage formats is similar to the following:
FAULT: [751-002] Error writing output file `/home/jones/report1'.
Workaround. Before starting any recoveries, ensure that the disk to which you are recovering has enough available space for the recovered data.
Alexandria Store operation cards do not have the ability to skip a day in the configured backup schedule, for example for a holiday. SAMS:Alexandria also does not have the ability to temporarily edit a Store operation card.
Workaround. The only way to skip a scheduled backup is to unmanage (unschedule) the operation card before the backup is scheduled to run. However, ensure that you manage (schedule) the operation card again as soon as the backup time has passed. Otherwise, this operation card will never run again. The only way to change the schedule for an operation card is to edit the schedule for the operation card before the backup and then, once the backup is done, manually restore the original schedule.
Once a backup has been made, the retention dates for that backup (Database Retain, Library Retain, and Lifetime Retain) cannot be extended or changed.
Workaround. The only way to change the retention dates in this case is to use the alex-media -sd or alex-media -sg command to scan the tapes. These commands change the retention dates in the SAMS:Alexandria database so that the information never expires unless manually deleted.
If you delete the configuration for a library in SAMS:Alexandria, the configurations for all tape drives associated with that library are also deleted. The problem that can occur is that any tape left in the drive at the time of its deconfiguration cannot be ejected, because SAMS:Alexandria no longer recognizes the drive's existence.
Workaround. Before deleting a library configuration, ensure that no tapes are in any of the affected tape drives. If this problem occurs, bring the tape drive on line and then move the tape from the tape drive to a library slot. Once this procedure is finished, take the drive off line again.
When you are performing database pack operations, if the permissions on the pack directory you are using do not match the permissions of the directory containing the SAMS:Alexandria database (by default, /usr/alexbkup/Database), the pack operation will fail. The pack operation will also fail if the pack directory does not exist. This problem occurs because the alex-dbase -PS command, which enables you to designate the pack directory, does not verify that the directory you designate exists or has the correct permissions. Later, when you pack the database with the alex-dbase -P command, it fails because it could not set the appropriate permissions on files in the pack directory.
Workaround. Always set the owner and group of the pack directory to alexbkup and set the permissions to 700 to match the /usr/alexbkup/Database directory.
If a tape resides in a tape drive of a configured SAMS:Alexandria library and that library is power-cycled, the next time SAMS:Alexandria accesses the library it marks the tape as UNKNOWN. Furthermore, if SAMS:Alexandria tries to identify the tape while it is in the tape drive, the tape will be marked as Managed Incorrect (MI). This problem occurs because the library does not return barcode information to SAMS:Alexandria for tapes that are in tape drives. This problem most commonly occurs when both the system and the library have a power failure while tapes are in tape drives. After the system reboots and SAMS:Alexandria is started, SAMS:Alexandria then marks the tapes as UNKNOWN.
Workaround. Using the touch screen on the library or the SAMS:Alexandria graphical interface Xalex, manually unload all tapes from tape drives and reinventory the library.
Before backing up data, SAMS:Alexandria calculates the estimated amount of tape storage space required by the store operation. This estimation is based on uncompressed data size. If SAMS:Alexandria determines that the library does not contain enough media to handle the estimated storage requirements, the store operation will fail with messages similar to the following:
FAILURE: [817-011] Could not locate any media for data storage.
MESSAGE: [817-000] Make sure libraries have enough available media.
MESSAGE: [817-000] Store Op-Card `FULL-/usr' failed to run successfully.
The estimation algorithm can cause store operations to fail when compression is used to back up the data. In this case, the store can fail even though sufficient media space is available.
Workaround. Ensure that the library contains enough media for the store operation to run based on uncompressed data capacity even though the actual store operation will be using compressed data.
If you select a stack for a restore operation that is identified as a FAILURE or that is a partially or incorrectly detailed scanned stack, the restore operation will be initiated for any complete clusters contained on that stack. However, SAMS:Alexandria does not display any warnings that you are restoring a failed or incomplete stack and that some expected data will not be restored. This problem can occur when all tapes for a stack are not scanned or when a store operation was not successful.
Workaround. Before beginning restore operations, check the stacks you want to restore for SUCCESS, FAILURE, or WARNING messages.
If a library is manually accessed, for example, by using the front panel of the library to perform tape movement operations, while a SAMS:Alexandria store or restore operation is active that needs to perform some tape movement in that library, the operation will fail with a SCSI Test Unit Ready error (Sense code 0x02, 0x04, 0x00). This problem has been seen while performing bulk moves and queued unloads with the front panel of the DDS-2 library.
Workaround. Ensure that there are no active or pending store or restore operations for the library before manually accessing it. For example, if you need to load and unload multiple tapes on a daily basis, then stop alex-sched at a time outside of the primary backup window, wait for all currently running stores and restores to be completed, load and unload the tapes as needed, and restart alex-sched. Any jobs that were scheduled to start during the time that alex-sched was stopped will start immediately after alex-sched is restarted.
The GenOp script does not output any information about the filesystems that were backed up by each child operation card that GenOp creates. GenOp dynamically assigns the filesystem backups to child operation cards each time GenOp is run. For this reason, it is possible that one child operation card can back up a filesystem on one day and that a different child operation card can back up that same filesystem the next day. This becomes confusing when you need to recover a full and an incremental backup of a filesystem and these two backups were performed by different child operation cards. In this case, you would need to restore data from two different stacks. However, there is no record of the previous days' filesystem distribution. You can only see the current distribution.
Workaround. Manually search for the data to be restored rather than relying on specific stack IDs to define all the data you want restored.
Assume that you have multiple tapes that comprise one or more stacks from one host. Then you move these tapes to a different host or to the original host which no longer has any references to these tapes and perform a "detailed alien scan" on some, but not all of these tapes. When a restore operation is run that requires data from these tapes, the restore can succeed even though not all the expected data was restored. No warnings are displayed about the missing data.
Workaround. Be sure to scan all necessary tapes.
When a client host starts a restore operation, the client host requests from the server host the location of the media to use for that restore operation. When that media is already in a tape drive, the server host returns the name of the tape drive to the client host. If the tape drive name returned by the server is different from the name configured on the client for that tape drive, the restore operation fails with errors similar to the following:
FAILURE: [814-006] Device `host1-lib1-D1' is NOT configured
MESSAGE: [818-000] Restore Op-Card `def.s-Restore-1' failed to run successful
ly.
Restore operations from a client do not fail if the required media is in a library slot.
Workaround. Retry the restore operation when the media is no longer in use. Alternatively, ensure that the library and device names are the same on the server and client. If you want to name the libraries and devices the same on the server and client, you will have to use the Xalex interface. The names generated by SetupHD.Seq and ClientHD for a given device do not match do not match in order to support multiple network interfaces between clients and servers.
If the front panel of a library is used to insert a cleaning tape directly into the SAMS:Alexandria designated cleaning slot, the next SAMS:Alexandria operation that needs to identify media will move that cleaning cartridge into a tape drive and the operation will fail. The result is that the cleaning cartridge is left in the tape drive and the drive is taken offline.
Workaround. Always use SAMS:Alexandria commands or the Xalex graphical interface to insert and eject cleaning cartridges to and from libraries configured in SAMS:Alexandria.
If you designate the path of a large file in the STORE-ROOT keyword of a Store operation card (for a full or incremental backup), the store operation fails with the following errors:
FAULT: [109-013] System Call `stat' failed. Error: Value too
large for defined data type (79).
MESSAGE: [109-000] Stat called with filename `/lsst/LF1/6GBfile'.
MESSAGE: [817-000] Store Op-Card `LF' failed to run successfully.
Workaround. Specify only the directory that contains the large file in the STORE-ROOT keyword.
When SAMS:Alexandria is shut down, the following messages may be printed:
Trying to terminate process UNKNOWN (7640)...
Trying to terminate process UNKNOWN (7668)...
Trying to terminate process UNKNOWN (7647)...
Trying to terminate process UNKNOWN (7642)...
Trying to terminate process UNKNOWN (7649)...
Trying to terminate process UNKNOWN (7669)...
Process UNKNOWN (7640) TERMINATED
Process UNKNOWN (7668) TERMINATED
Process UNKNOWN (7647) TERMINATED
Process UNKNOWN (7642) TERMINATED
Process UNKNOWN (7645) TERMINATED
Process UNKNOWN (7669) TERMINATED
The processes that are listed as UNKNOWN are typically additional slnetdaemon processes started by various remote accesses including the HTML GUI. This is not an indication of an orphaned process, but that SAMS:Alexandria does not have a process name associated with this process ID.
Workaround. This message can be safely ignored. No incorrect processes will be terminated.
Error messages are generated on the DYNIX/ptx server in the /usr/alexbkup/ErrorMsgs/Messages file when the SAMS:Alexandria Java-based interface is exited. The errors, which are quite long, are generated when exiting with the [X] in the top right corner and with the [Exit SAMS:Alexandria] button on the main Login screen. These slnetdaemon errors are similar to the following:
FAULT: [621-011] System call 'recv' failed. Error Connection request by peer (131). MESSAGE: [621-000] TCP/IP Detail Error Information Report. MESSAGE: [621-000] ID : 141 MESSAGE: [621-000] Initialized : YES MESSAGE: [621-000] Server : YES MESSAGE: [621-000] Client : NO MESSAGE: [621-000] Debug Value : 0 MESSAGE: [621-000] Port Number : 22364 MESSAGE: [621-000] Program Name : slnetdaemon
Workaround. These error messages can be safely ignored.
When SAMS:Alexandria is started for the first time after a restore from a daily housekeeping tape, corruption will be introduced into the SAMS:Alexandria database if transaction logging is turned on and the raw partition for the transaction logging database contains residual data.
The corruption occurs because the database is backed up ONLINE with housekeeping and not marked with a clean shutdown. When the SAMS:Alexandria database is restored and brought up, the database daemon notices the restored database was not shut down clean (because it was backed up online) and reloads the residual data from the raw partition, which in this case is incorrect and should not be applied, thus corrupting the database.
Workaround. Zeroing out the transaction log raw partition before starting SAMS:Alexandria for the first time after restoring from a DATABASE backup tape will wipe out any residual data in the raw partition. For example, the following command will overwrite any data on the raw partition v-alex_raw with zeroes:
# dd if=/dev/zero of=/dev/vx/rdsk/v-alex-tldb bs=64k
The disaster recovery procedures provided for Backup Toolkit on all versions of DYNIX/ptx account for this problem.
The AlexClient/NT personality fails to store some of the Registry keys. The backup of the registry keys fails with a status code of 'A', which means that SAMS:Alexandria could not find any attributes describing the file, so it was not backed up. The following registry keys are not backed up:
HKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\SYSTEM\EISAADAPTER\0\Configuration Data HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWS\CURRENTVERSION\CONTROLS FOLDER\Presentati on Cache HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWSNT\CURRENTVERSION\PERFLIB\009\Counter HKEY_LOCAL_MACHINE\SOFTWARE\MICROSOFT\WINDOWSNT\CURRENTVERSION\PERFLIB\009\Help
Previous versions of Alexandria also did not back up the HKEY_LOCAL_MACHINE\SECURITY\SAM\C registry key. With SAMS:Alexandria V4.50.53, this registry key is properly backed up.
Workaround. Contact IBM Customer Support if this problem affects your site.
SAMS:Alexandria network backups can hang during the first cluster build when it opens a second socket. Starting with SAMS:Alexandria V4.50.53, network operations were changed by opening a second socket during network backups and indications are that the second socket is related to this problem.
Workaround. Disable the second socket from being opened by enabling the Single-Port-For-Remote-Devices configuration option of SAMS:Alexandria. This option should be enabled only for client hosts; it does not need to be enabled on server hosts. Note that only those client hosts that have enabled this option will use one socket to negotiate with the server. Client hosts who have not enabled this option will continue to use two sockets for network backups.
To enable the Single-Port-For-Remote-Devices configuration option, use the alex-option command as follows:
# alex-option -u Single-Port-For-Remote-Devices 'On'
This section describes the SAMS:Alexandria problems that occur only when using the ACSLS personality and ACSLS-connected libraries. (The ACSLS personality is part of SAMS:Alexandria and is not a separate software product.) These problems do not apply to any other library usage, including directly-connected STK libraries.
Inserting media from the CAP to a pool with the alex-util command or from the CAP to a logical library (insert method is cap-id, for example, 0,0,0) sometimes fails. The failure occurs when the barcode reader of the ACSLS-connected library cannot read the barcode labels on the media in the CAP. This can happen when the CAP door is shut too firmly and the media shifts in the CAP. Media whose barcodes cannot be read are left in the CAP door as would be expected. The problem that occurs is that the media whose barcodes were successfully read are not inserted into the requested pool or logical library. Instead, they are inserted only into the physical library and are unavailable for direct use by SAMS:Alexandria.
Workaround. To prevent this problem, be sure to shut the STK library CAP door extremely gently, preventing the spring tension on the door from closing it more firmly.
If this problem occurs, use the ACSLS server to locate the media that was inserted into only the physical library and eject them from the physical library. Then you can reinsert them into the logical library or pool. For more information on inserting media into an ACSLS-connected library, refer to the Backup Toolkit Administration Guide for SAMS:Alexandria.
Alexandria logical slots 1 and 2 are reserved for managed database volumes. However, the alex_cntrl +l libraryname +d devicename -u -1 command will unmount the tape but put it in slot 1 or slot 2, if either of these slots do not contain any media. This will cause the recovery pool to incorrectly reflect this tape as a managed database tape.
Workaround. None.
The recovery pool is supposed to show barcode labels for all managed database tapes. However, it shows only the barcode labels of the tapes in SAMS:Alexandria logical slots 1 and 2, regardless of the actual media status of those volumes.
Workaround. Use standard SAMS:Alexandria procedures to track managed database tapes. Do not rely on the recovery pool to track these tapes.
When configuring logical libraries for an ACSLS-connected library, the Library Personality Specifiers window in the Xalex GUI does not verify that the pool-IDs that you enter for the insert, eject, and recovery pools actually exist in the ACSLS.
Workaround. Make sure that the pools have been created.
When the CAP insert method is used with ACSLS-connected libraries, if you issue the command alex-cntrl +l libraryname -i 0 and then terminate the command before entering any tapes into the CAP, the command will terminate but the ACSLS will keep on waiting for tapes to be entered. This will prevent other commands from using the CAP. Also, the ACSLS will accept tapes from the CAP but the tapes will not be put into the correct library.
Workaround. If the alex-cntrl -i command is terminated prematurely, make sure that the enter command on the ACSLS server is also terminated. If the enter command has not terminated, cancel the related enter request from the `cmd_proc' window of the ACSLS server.
When the CAP eject method is used with ACSLS-connected libraries, if you issue the command alex-cntrl +l libraryname -e slot and then terminate the command, the command will be terminated but the ACSLS will probably put some of the tapes into the CAP. These ejected tapes will still be in the library's inventory, causing these volumes to be orphaned from SAMS:Alexandria.
Workaround. If any tapes have come to the CAP because of this eject command, reinsert them into the correct logical library.
The following COBRA problems that were found on a DYNIX/ptx host have been reported. For other COBRA problems that have been reported, refer to the SAMS:Alexandria COBRA/v4 Personality Release Notes.
The OPS-DB-INSTANCE keyword/command documented on page 81 of the SAMS:Alexandria COBRA System Administration Guide under "Store Commands Reference" in Chapter 6, "Backup Commands Reference," incorrectly shows the following syntax:
OPS-DB-INSTANCE <unique_id> <db_instance> <ORACLE Home> <node_name> [....]
The correct syntax is as follows:
OPS-DB-INSTANCE <unique_id> <ORACLE Home> <node_name> <db_instance> [....]
Whenever a COBRA Store operation card is saved in the SAMS:Alexandria Java-based interface, the value of the BACKUP-READ-ONLY keyword is set to ON regardless of the selection for the Skip Read Only TS-s check box. With this problem, it is not possible to use the Java-based interface to disable the back up of read-only tablespaces.
Furthermore, if a Store operation card was previously created with the alex-xfer command so that read-only tablespaces are not backed up (BACKUP-READ-ONLY OFF) and this operation card is viewed with the Java-based interface, the Skip Read Only TS-s check box is correctly displayed as unselected. However, if this operation card is then saved by the Java-based interface, read-only tablespaces will be backed up as the value of the BACKUP-READ-ONLY keyword is reset from OFF to ON by the Java-based interface.
Workaround. Use the alex-xfer command to update this option to OFF if required.
The section "Backing Up an OPS Environment" in Chapter 7, "Handling Special Backup Tasks," on page 124 of the SAMS:Alexandria COBRA System Administration Guide is missing the following additional information about what COBRA requires:
Parameter files for remote instances must be copied to the local node where COBRA will initiate the backup. This must be done anytime a change is made to the parameter files. If the required startup files of every remote instance are not present on the local node, COBRA attempts to restart all instances with the same startup files, which implies the same thread and instance numbers. This results in starting up only one instance while the other instances fail with error messages.
Some OPS configurations maintain the same Oracle SID for all instances, which is a valid setup in Oracle. Although store operations complete successfully in this scenario, the remote instance's files fail to restore using COBRA restore operation cards that are generated with cobraquery.
In Oracle OPS environments where the Oracle SID is the same across all threads, the following COBRA restore issues exist:
cobraquery fails to add the parameter files on the remote instances to the restore operation card that it builds.
Manually adding the remote parameter files to the COBRA restore operation card fails to restore the files for the remote nodes. In this case, the following error will be reported:
FAULT: [826-010] No file backup record found. File: co_cobra_r.c (941) [PID_568] MESSAGE: [826-000] file='/oracle/orahomes/oracle805_ops/dbs/orapwrealw4385' File: co_cobra_r.c (943) [PID_568] MESSAGE: [826-000] stack='99/01/11:10:30-FULL-COBRA-cobcold_3_node_2_1.elm1 7b66' File: co_cobra_r.c (945) [PID_568] CASCADE: [826-000] Call to co_RestoreAssignFilesToNodes failed. File: co_cobra_r.c (3066) [PID_568] CASCADE: [920-000] Call to co_PerformRestoreOperation failed. File: co_cobramain.c (460) [PID_568]
Workaround. Use regular SAMS:Alexandria restore methods to select and restore the object(s).
The Daily Summary Report mail does not give any details about those stacks created by Transfer Manager Store operations. This includes those Store operations run by COBRA v4, ON-Bar, RMAN, and any other backups generated by the Transfer Manager. The Daily Summary Report mail only includes those stacks that are generated by the alex-sched scheduler.
Workaround. Use alex-stack -lA to check the status of alex-xfer based stores. Note that for parent/child store operations the result of the parent store operation indicates the overall success or failure of the backup operation. For example, a child store operation might fail, but then be successfully retired and thus the overall backup operation succeeded.
The SAMS:Alexandria COBRA/v4 Personality Release Notes, April 1999, that are provided with SAMS:Alexandria 4.50.70, state that split mirror backups have been certified with EMC Symmetrix® hardware, EMC TimeFinder software, and DYNIX/ptx. This information is provided in the section "Platforms/System Requirements." However, at this time, IBM does not support the use of SAMS:Alexandria with EMC TimeFinder on DYNIX/ptx and EMC Symmetrix hardware.
Workaround. Contact your IBM Sales Representative for information on future support of this functionality.
COBRA does not create any missing directories during Restore operations. When restoring database files to a new location, this problem prevents the Restore operation from successfully completing. This problem exists because of the way COBRA creates the SLT files used during the Restore operation.
Workaround. Before beginning a COBRA Restore operation, ensure that the entire directory tree exists for the Oracle data that you plan to restore.
COBRA Store operations monitor how much data is written to its input FIFO and sleeps for 5 seconds after every 2048 bytes are written. This allows the reader on the other side of the pipe to catch up. In some circumstances, this can cause a long delay during Store operations. For example, COBRA Store operations of Oracle databases that track 3000 or more Archive logs may see a delay of 10 minutes or more.
Workaround. Limiting the size of the v$archived_log table (MAXLOGHISTORY) or properly configuring redo log sizes can help manage the delay. However, there is no workaround for sites that have efficiently configured the size of the v$archived_log table and/or do require an archive log table of greater than 3000 records.