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. It can be used 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 28-19 shows the syntax for copying a log after a device failure.
Copying with the no_truncate option |
|
|---|---|
dump transaction database_name
to [compress::[compression_level::]] stripe_device
[at server_name]
[density = density,
blocksize = number_bytes,
capacity = number_kilobytes,
dumpvolume = volume_name,
file = file_name]
[stripe on [compress::[compression_level::]] stripe_device
[at 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,
dumpvolume = volume_name,
file = file_name,
[nodismount | dismount],
[nounload | unload],
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"
