Copying the log after a device failure

Normally, dump transaction truncates the inactive portion of the log after copying it. Use with no_truncate to copy the log without truncating it.

no_truncate allows you to copy the transaction log after failure of the device that holds your data. It uses pointers in the sysdatabases and sysindexes tables to determine the physical location of the transaction log. You can use no_truncate only if your transaction log is on a separate segment and your master database is accessible.

WARNING! Use no_truncate only if media failure makes your data segment inaccessible. Never use no_truncate on a database that is in use.

Copying the log with no_truncate is the first step described in “Recovering a database: step-by-step instructions”.

Table 12-20 shows the syntax for copying a log after a device failure.

**Table 12-20: Copying the log file after a device failure**
	Copying with the no_truncate option
	dump transaction database_name to [compress::[compression_level::]] stripe_device [at backup_server_name] [density = density, blocksize = number_bytes, capacity = number_kilobytes, dumpvolume = volume_name, file = file_name] [stripe on [compress::[compression_level::]] stripe_device [at backup_server_name] [density = density, blocksize = number_bytes, capacity = number_kilobytes, dump volume = volume_name, file = file_name] ...] [with{ density = density, blocksize = number_bytes, capacity = number_kilobytes, compression = compress_level, dumpvolume = volume_name, file = file_name, [nodismount \| dismount], [nounload \| unload], passwd = password, retaindays = number_days, [noinit \| init],
Do not truncate log	`no_truncate,`
	`[notify = {client \| operator_console}] standby_access}]`

You can use no_truncate with striped dumps, tape initialization, and remote Backup Servers. Here is an example:

dump transaction mydb 
to "/dev/nrmt0" at REMOTE_BKP_SERVER
with init, no_truncate,
notify = "operator_console"