Reverse the Active and Standby Roles

In order to perform the database defragmentation on the active database, switch the roles of the active and standby database.

The active (ttdb1) becomes the standby database. The original standby (ttdb2) becomes the active database.

Stop all application processing and disconnect all application connections with the ttAdmin -disconnect command. Any query only processing can be moved to work at the ttdb2 TimesTen database. See Disconnecting from a Database in this book and ttAdmin in the Oracle TimesTen In-Memory Database Reference.
Call the ttRepSubscriberWait built-in procedure at the current active database (ttdb1), with the database name and host of the current standby database (ttdb2) as input parameters. This verifies that all queued updates are transmitted to the current standby database.
Note:

If you set the waitTime to -1, the call waits until all committed transactions have been transmitted to the subscriber without timeout value.

However, if you set the waitTime to any value (this value cannot be NULL), ensure that the return timeOut parameter value is 0x00 before continuing. If the returned value is 0x01, repeatedly call the ttRepSubscriberWait built-in procedure until it returns 0x00, which indicates that all committed transactions are transmitted to the subscriber.

For more information about the ttRepSubscriberWait built-in procedure, see ttRepSubscriberWait in the Oracle TimesTen In-Memory Database Reference.
```
call ttRepSubscriberWait(NULL,NULL,'ttdb2','ttsrv2', 100);
```
Stop the replication agent on the current active database ttdb1.
```
call ttRepStop;
```
Call the ttRepDeactivate built-in procedure on the current active database ttdb1. This puts the database in the IDLE state.
```
call ttRepDeactivate;
```
Call the ttRepStateGet built-in procedure to show the database state.
```
Command> call ttRepStateGet;
< IDLE >
1 row found.
```
Promote the standby to active by calling the ttRepStateSet('ACTIVE') built-in procedure on the old standby database. This database ttdb2 now becomes the active database in the active standby pair. Use the ttRepStateGet built-in to verify that the database has become active.
```
call ttRepStateSet('ACTIVE');
```
```
Command> call ttRepStateGet;
< ACTIVE >
1 row found.
```
Use ttRepStateSave to instruct the new active database to replicate directly to any read-only subscribers while the old active database is unavailable. Run ttRepStateSave on the new active database ttdb2 to set the status of the old active database to failed.
```
call ttRepStateSave('FAILED', 'ttdb1', 'ttsrv1');
```
Restart the full application workload on the new active database (ttdb2).

Now, the new active database is functional and the next step is to recreate a new standby. For details, see Destroy and Re-Create a New Standby.