Migrate and Rebuild the Standby Database

This section shows how to stop replication to the standby TimesTen database, save a copy of the standby database, and then defragment the standby database and its associated cache group.

Note:

While the standby database is defragmented, application processing can continue on the active database.

Perform the following steps to defragment the standby database having a cache group:

Stop the replication agent on the standby database (ttdb2):
```
ttAdmin –repStop ttdb2
```
If there is any subscriber, run ttRepStateSave on the active database to set the status of the standby to 'failed' and activate replication of updates directly from the active database to the subscriber databases. As long as the standby database is unavailable, updates from the active database are replicated directly to the subscriber databases.
```
call ttRepStateSave('FAILED', 'ttdb2', 'ttsrv2');
```
Save a copy of the standby database using ttMigrate.
```
ttMigrate -c ttdb2 ttdb2.dat
```
If there is a read-only cache group, stop the cache agent, drop any cache groups, and destroy the standby.
Note:
If you do not have cache groups, you can ignore the cache-specific steps.
```
ttAdmin –cacheStop ttdb2
```
While connected as cache manager user in ttIsql, drop all cache groups:
```
DROP CACHE GROUP t_cg;
```
Destroy the standby database:
```
ttDestroy ttdb2
```
Rebuild the standby database. Run the following on the standby as the instance administrator:
```
ttIsql ttdb2
```
Create the cache manager user and grant the user ADMIN privileges. Using ttIsql:
```
CREATE USER cacheadmin IDENTIFIED BY cadminpwd;
GRANT CREATE SESSION, CACHE_MANAGER, CREATE ANY TABLE, DROP ANY TABLE TO cacheadmin;
GRANT ADMIN TO cacheadmin;
```
Note:

The cache manager user requires ADMIN privileges in order to run ttMigrate –r. Once migration is completed, you can revoke the ADMIN privilege from this user if desired.

See ttMigrate in the Oracle TimesTen In-Memory Database Reference.
As the cache manager user, restore the ttdb2 database using ttMigrate:
```
ttMigrate -r -relaxedUpgrade -cacheuid cacheadmin -cachepwd cadminpwd 
-connstr "dsn=ttdb2;uid=cacheadmin;pwd=cadminpwd;oraclepwd=oraclepwd" ttdb2.dat
```
After restoring the ttdb2 database:
- All the users, cache groups, and the active standby pair have been restored to ttdb2.
- The cache groups are in AUTOREFRESH STATE = OFF.
- The cache and replication agents are not running.
As the cache manager user, start the cache agent on the standby:
```
ttAdmin –cacheStart ttdb2
```
Load cache group.
```
ALTER CACHE GROUP t_cg SET AUTOREFRESH STATE PAUSED;
LOAD CACHE GROUP t_cg COMMIT EVERY 256 ROWS PARALLEL <nThreads>;
```
Note:
- Choose nThreads based on how many CPU cores you use to insert the data into TimesTen for this load operation.
- If there are several read-only cache groups, it is recommended that you run several LOAD operations in separate sessions in parallel.

After completion, verify the cache group state.

Command> cacheGroups;
Cache Group CACHEADMIN.T_CG:
  Cache Group Type: Read Only
  Autorefresh: Yes
  Autorefresh Mode: Incremental
  Autorefresh State: On
  Autorefresh Interval: 10 Seconds
  
  Autorefresh Status: ok
  Aging: No aging defined
 
  Root Table: SALES.T
  Table Type: Read Only
 
1 cache group found.

Start the replication agent on the standby database ttdb2:
```
ttAdmin -repStart ttdb2
```

Check the replication state on the standby:

% ttIsql ttdb2
Command> call ttRepStateGet;
< STANDBY >
1 row found.

The standby database (ttdb2) has been defragmented and both the active and standby databases are functional.