Oracle High Availability: Administering Oracle GoldenGate

20.1 Performing Application Patches

Application patches and application upgrades typically perform DDL such as adding new objects or changing existing objects. To apply applications patches or upgrades in an Oracle GoldenGate environment, you can do one of the following:

If Oracle GoldenGate supports DDL replication for your database type, you can use it to replicate the DDL without stopping replication processes. To use this method, the source and target table structures must be identical.
You can apply the patch or upgrade manually on both source and target after taking the appropriate steps to ensure replication continuity.

To use Oracle GoldenGate to replicate patch DDL

If you have not already done so, dedicate some time to learn, install, and configure the Oracle GoldenGate DDL support. See the instructions for your database in this documentation. Once the DDL environment is in place, future patches and upgrades will be easier to apply.
If the application patch or upgrade adds new objects that you want to include in data replication, make certain that you include them in the DDL parameter statement. To add new objects to yourTABLE and MAP statements, see the procedure on Section 20.4.2, "Adding Tables to the Oracle GoldenGate Configuration".
If the application patch or upgrade installs triggers or cascade constraints, disable those objects on the target to prevent collisions between DML that they execute on the target and the same DDL that is replicated from the source trigger or cascaded operation.

To apply a patch manually on the source and target

Stop access to the source database.
Allow Extract to finish capturing the transaction data that remains in the transaction log. To determine when Extract is finished, issue the following command in GGSCI until it returns At EOF.
```
SEND EXTRACT group GETLAG
```
Stop Extract.
```
STOP EXTRACT group
```
Start applying the patch on the source.
Wait until the data pump (if used) and Replicat are finished processing the data in their respective trails. To determine when they are finished, use the following commands until they return At EOF.
```
SEND EXTRACT group GETLAG
SEND REPLICAT group GETLAG
```
Stop the data pump and Replicat.
```
STOP EXTRACT group
STOP REPLICAT group
```
At this point, the data in the source and target should be identical, because all of the replicated transactional changes from the source have been applied to the target.
Apply the patch on the target.
If the patches changed table definitions, run DEFGEN for the source tables to generate updated source definitions, and then replace the old definitions with the new ones in the existing source definitions file on the target system.
Start the Oracle GoldenGate processes whenever you are ready to begin capturing user activity again.

20.2 Initializing the Transaction Logs

When you initialize a transaction log, you must ensure that all of the data is processed by Oracle GoldenGate first, and then you must delete and re-add the Extract group and its associated trail.

Stop the application from accessing the database. This stops more transaction data from being logged.
Run GGSCI and issue the SEND EXTRACT command with the LOGEND option for the primary Extract group. This command queries Extract to determine whether or not Extract is finished processing the records that remain in the transaction log.
```
SEND EXTRACT group LOGEND
```
Continue issuing the command until it returns a YES status, indicating that there are no more records to process.
On the target system, run GGSCI and issue the SEND REPLICAT command with the STATUSoption. This command queries Replicat to determine whether or not it is finished processing the data that remains in the trail.
```
SEND REPLICAT group STATUS
```

Continue issuing the command until it shows 0 records in the current transaction, for example:

Sending STATUS request to REPLICAT REPSTAB...
Current status:
  Seqno 0, Rba 9035
  0 records in current transaction.

Stop the primary Extract group, the data pump (if used), and the Replicat group.
```
STOP EXTRACT group
STOP EXTRACT pump_group
STOP REPLICAT group
```

Delete the Extract, data pump, and Replicat groups.

DELETE EXTRACT group
DELETE EXTRACT pump_group
DELETE REPLICAT group

Using standard operating system commands, delete the trail files.
Stop the database.
Initialize and restart the database.
Recreate the primary Extract group.
```
ADD EXTRACT group TRANLOG, BEGIN NOW
```
Recreate the local trail (if used).
```
ADD EXTTRAIL trail, EXTRACT group
```

Recreate the data pump (if used).

ADD EXTRACT pump_group, EXTTRAILSOURCE trail

Recreate the remote trail.
```
ADD RMTTRAIL trail, EXTRACT pump_group
```
Recreate the Replicat group.
```
ADD REPLICAT group, EXTTRAIL trail
```

Start Extract, the data pump (if used), and Replicat.

START EXTRACT group 
START EXTRACT pump_group
START REPLICAT group

20.3 Shutting Down the System

When shutting down a system for maintenance and other procedures that affect Oracle GoldenGate, follow these steps to make certain that Extract has processed all of the transaction log records. Otherwise, you might lose synchronization data.

Stop all application and database activity that generates transactions that are processed by Oracle GoldenGate.
Run GGSCI.
In GGSCI, issue the SEND EXTRACT command with the LOGEND option. This command queries the Extract process to determine whether or not it is finished processing the records in the data source.
```
SEND EXTRACT group LOGEND
```
Continue issuing the command until it returns a YES status. At that point, all transaction log data has been processed, and you can safely shut down Oracle GoldenGate and the system.

To add a table to the Oracle GoldenGate configuration

Stop user access to the new tables.
(If new tables do not satisfy a wildcard) If you are adding numerous tables that do not satisfy a wildcard, make a copy of the Extract and Replicat parameter files, and then add the new tables with TABLE and MAP statements. If you do not want to work with a copy, then edit the original parameter files after you are prompted to stop each process.
(If new tables satisfy wildcards) In the Extract and Replicat parameter files, make certain theWILDCARDRESOLVE parameter is not being used, unless it is set to the default of DYNAMIC.
(If new tables do not satisfy a wildcard) If the new tables do not satisfy a wildcard definition, stop Extract.
```
STOP EXTRACT group
```
Add the new tables to the source and target databases.
If required for the source database, issue the ADD TRANDATA command in GGSCI for the new tables. Before using ADD TRANDATA, issue the DBLOGIN command.
Depending on whether the source and target definitins are identical or different, use eitherASSUMETARGETDEFS or SOURCEDEFS in the Replicat parameter file. If SOURCEDEFS is needed, you can do either of the following:
- Run DEFGEN, then copy the new definitions to the source definitions file on the target.
- If the new tables match a definitions template, specify the template with the DEF option of the MAP parameter. (DEFGEN not needed.)
To register the new source definitions or new MAP statements, stop and then start Replicat.
```
STOP REPLICAT group
START REPLICAT group
```
Start Extract, if applicable.
```
START EXTRACT group
```
Permit user access to the new tables.

Coordinating Table Attributes between Source and Target

Follow this procedure if you are changing an attribute of a source table that is in the Oracle GoldenGate configuration, such as adding or changing columns or partitions, or changing supplemental logging details (Oracle). It directs you how to make the same change to the target table without incurring replication latency.

Note:

This procedure assumes that the Oracle GoldenGate DDL support feature is not in use, or is not supported for your database. For Oracle and Teradata databases, you can enable the DDL support feature of Oracle GoldenGate to propagate the DDL changes to the target, instead of using this procedure.

On the source and target systems, create a table, to be known as the marker table, that can be used for the purpose of generating a marker that denotes a stopping point in the transaction log. Just create two simple columns: one as a primary key and the other as a regular column. For example:
```
CREATE TABLE marker
(
id int NOT NULL,
column varchar(25) NOT NULL,
PRIMARY KEY (id)
);
```
Insert a row into the marker table on both the source and target systems.
```
INSERT INTO marker VALUES (1, 1);
COMMIT;
```
On the source system, run GGSCI.
Open the Extract parameter file for editing.

Caution:
Do not use the VIEW PARAMS or EDIT PARAMS command to view or edit an existing parameter file that is in a character set other than that of the local operating system (such as one where the CHARSET option was used to specify a different character set). View the parameter file from outside GGSCI if this is the case; otherwise, the contents may become corrupted..
Add the marker table to the Extract parameter file in a TABLE statement.
```
TABLE marker;
```
Save and close the parameter file.
Add the marker table to the TABLE statement of the data pump, if one is being used.
Stop the Extract and data pump processes, and then restart them immediately to prevent capture lag.
```
STOP EXTRACT group
START EXTRACT group
STOP EXTRACT pump_group
START EXTRACT pump_group
```
On the target system, run GGSCI.
Open the Replicat parameter file for editing.

Caution:
Do not use the VIEW PARAMS or EDIT PARAMS command to view or edit an existing parameter file that is in a character set other than that of the local operating system (such as one where the CHARSET option was used to specify a different character set). View the parameter file from outside GGSCI if this is the case; otherwise, the contents may become corrupted.
Add the marker table to the Replicat parameter file in a MAP statement, and use theEVENTACTIONS parameter as shown to stop Replicat and ignore operations on the marker table.
```
MAP marker, TARGET marker, EVENTACTIONS (STOP, IGNORE);
```
Save and close the parameter file.
Stop, and then immediately restart, the Replicat process.
```
STOP REPLICAT group
START REPLICAT group
```
When you are ready to change the table attributes for both source and target tables, stop all user activity on them.
On the source system, perform an UPDATE operation to the marker table as the only operation in the transaction.
```
UPDATE marker
SET column=2,
WHERE id=1;
COMMIT;
```
On the target system, issue the following command until it shows that Replicat is stopped as a result of the EVENTACTIONS rule.
```
STATUS REPLICAT group
```
Perform the DDL on the source and target tables, but do not yet allow user activity.
Start Replicat.
```
START REPLICAT group
```
Allow user activity on the source and target tables.

Purging Archive Logs

An Oracle archive log can be purged safely once Extract's read and write checkpoints are past the end of that log. Extract does not write a transaction to a trail until it has been committed, so Extract must keep track of all open transactions. To do so, Extract requires access to the archive log where each open transaction started and all archive logs thereafter.

Extract reads the current archive log (the read checkpoint) for new transactions and also has a checkpoint (the recovery checkpoint) in the oldest archive log for which there is an uncommitted transaction.

Use the following command in GGSCI to determine Extract's checkpoint positions.

INFO EXTRACT group, SHOWCH

The Input Checkpoint field shows where Extract began processing when it was started.
The Recovery Checkpoint field shows the location of the oldest uncommitted transaction.
The Next Checkpoint field shows the position in the redo log that Extract is reading.
The Output Checkpoint field shows the position where Extract is writing.

You can write a shell script that purges all archive logs no longer needed by Extract by capturing the sequence number listed under the Recovery Checkpoint field. All archive logs prior to that one can be safely deleted.

Oracle High Availability

Thursday, December 17, 2015

Administering Oracle GoldenGate

20.1 Performing Application Patches

20.2 Initializing the Transaction Logs

20.3 Shutting Down the System

Coordinating Table Attributes between Source and Target

Purging Archive Logs

No comments:

About Me