Recovery procedures

Use these procedures to ensure clean recovery after media failure.

Recovering after media failure of the database file

Make an extra backup copy of the current transaction log. If the database file is gone, the only record of changes since the last backup is in the transaction log.
Create a recovery directory to hold the files you use during the recovery process.
Copy the database file from the last full backup to the recovery directory. You can find the database file in the backup directory. It is named erssd_name.db.
Copy the backup transaction log into the recovery directory. The backup transaction log, named erssd_name.log, is in the backup directory.
Apply the transactions from the backup transaction log to the recovery database:
```
dbsrv11 erssd_name.db -a erssd_name.log
```
Copy the online transaction log into the recovery directory. The online transaction log, named erssd_name.log, is in the log directory.
Apply the transactions from the online transaction log to the recovery database:
```
dbsrv11 erssd_name.db -a erssd_name.log
```
Make a post-recovery backup by making an extra copy of the database file.
Move the database file to the production directory and restart the database. Use the command dbspawn from the Replication Server error log.

Perform validity checks on the recovery database:

dbvalid -c 
"uid=primary_user_name;
pwd=primary_user_password;eng=erssd_name
LINKS=tcpip
(DOBROAD=NONE;HOST=localhost;PORT=port)"

Restart Replication Server.

Recovering from media failure on the database transaction log

Identify the corrupted file. You can do this by running the Log Translation utility on both the transaction log and its mirror to see which one generates an error message. In this example, the Log Translation utility, dbtran, translates a transaction log named erssd_name.log, saving the translated output in db_name.sql.
```
dbtran erssd_name.log
```
The Log Translation utility translates the intact file with no errors, but reports an error when translating the corrupt file.
Copy the correct file over the corrupted file, so that the two files are identical.
Restart the database, using command from the Replication Server error log.
Restart Replication Server.

Resetting the database transaction log for ERSSD

If Replication Agent is running and there are existing routes, you can reset the database transaction log for the ERSSD after you recover from media failure on the log. This procedure uses the dblog, dbeng11, and dbstop SQL Anywhere commands that you must run at the system prompt.

Shut down Replication Server using shut down. See “Shutting down Replication Server”.
Reset the ERSSD database log at a system prompt:
```
dblog -il erssd_name.db
```
Start the ERSSD database server:
```
dbeng11 erssd_name.db
```
Reset the ERSSD database locator value to 0:
1. Start isql.
2. Execute rs_zeroltm on the ERSSD database:
```
rs_zeroltm erssd_name, erssd_name
```
3. Exit isql.

Stop the ERSSD database at the system prompt:

dbstop -c
“eng=erssd_name;uid=primary_user_name;
pwd=primary_user_password”

Start Replication Server. See “Starting Replication Server”.

See your SQL Anywhere documentation for more information on the SQL Anywhere commands.