Je vais vous expliquer dans cette article comment supprimer le schéma dédié à GoldenGate de la base Oracle source. En effet la plupart du temps cela se passe sans aucun problème mais parfois vous aurez la désagréable surprise de constater qu’il est impossible de supprimer l’utilisateur GoldenGate car une table temporaire et plus précisément GGS_STICK est verrouillée par un processus Oracle, là encore rien de grave puisqu’il suffit de supprimer la session par la commande ALTER SESSION KILL SESSION ‘PID,SERIAL#’  mais cela devient plus embarrassant lorsqu’il s’agit du processus smon.

Dans ce cas de figure malheureusement pas d’autres alternatives que d’arrêter et redémarrer la base de données Oracle, pour cette opération dans un environnement de production elle nécessitera dans la plupart des cas un arrêt des applications qui devra obligatoirement être planifiée à une heure où les accès aux données seront les moins pénalisants et correspondront bien souvent à des opérations de nuit.

 
Voyons maintenant le mode opératoire de cette petite procédure, elle se décompose en 4 étapes :

1. Arrêter tous les processus GoldenGate (extract, replicat, mgr)
2. Contrôler les verrous sur la table GGS_STICK
3. Supprimer le schéma GoldenGate
4. Supprimer les options SUPPLEMENTAL LOGGING

Arrêt des tous les processus GoldenGate

Il convient  avant tout d’arrêter tous les processus goldengate (Extract, Replicat, Mgr, Agent)

./ggsci
stop *
stop mgr
stop agent             # Uniquement si agent monitor est installé
info all
exit

Vérification des verrous sur la table GGS_STICK

Alors avant de supprimer le schéma GoldenGate, il est impératif de vérifier qu’aucun verrou ne soit posé sur la table GGS_STICK par cette simple requête :

sqlplus / as sysdba
set lines 200
alter session set nls_date_format='DD-MM-YY HH24:MI:SS';
col "USER HOLDING LOCK" for A50
SELECT 'USER: '||s.username||' SID: '||s.sid||' SERIAL #: '||S.SERIAL# "USER HOLDING LOCK", s.logon_time, s.status, s.paddr, s.program
 FROM gv$lock l
 ,dba_objects o
 ,gv$session s
 WHERE l.id1 = o.object_id
 AND s.sid = l.sid
 AND o.owner = 'GGS_OWNER' and o.object_name = 'GGS_STICK';
USER HOLDING LOCK              LOGON_TIME          STATUS       PADDR            PROGRAM
-----------------------------  ------------------- ----------  ---------------- -------------------
USER:  SID: 5496 SERIAL #: 1   21-02-2014 01:33:52 ACTIVE      000000CD784D670  oracle@easy (SMON)

Dans le cas où des sessions accèdent à cet objet ‘GGS_STICK’, il faudra les supprimer alors la commande usuelle ‘ALTER SYSTEM KILL SESSION’ malheureusement comme dans notre cas de figure s’il s’agit de ‘smon’ il faudra alors planifier un arrêt et redémarrage de la base de données.

Suppression du schéma GoldenGate

Maintenant que l’étape précédente est passée, il suffit d’enchaîner les scripts suivants qui se trouvent dans le répertoire de la distribution GoldenGate.

sqlplus / as sysdba       
@remove_seq.sql GGS_OWNER
@ddl_disable.sql
@ddl_remove.sql
@marker_remove.sql
drop trigger GGS_DDL_TRIGGER_BEFORE;
drop user GGS_OWNER cascade ;

Suppression des options SUPPLEMENTAL LOGGING

Il ne reste plus qu’à désactiver toutes les options sur les fichiers REDOLOG pour retrouver le volume normal enregistré dans ces fichiers (informations complémentaires sur les colonnes destinées à GoldenGate)

sqlplus / as sysdba
alter database drop supplemental log data (all) columns;
alter database drop supplemental log data (primary key) columns;
alter database drop supplemental log data (foreign key) columns;
alter database drop supplemental log data (unique) columns;
alter database drop supplemental log data;
alter database drop supplemental log data for procedural  replication; (Uniquement Oracle 11gR2)

Un dernier petit contrôle s’impose pour valider que toutes les options SUPPLEMENTAL LOGGING ne sont plus actives c’est à dire ayant pour valeur ‘NO’

select NAME, SUPPLEMENTAL_LOG_DATA_MIN, SUPPLEMENTAL_LOG_DATA_PK, SUPPLEMENTAL_LOG_DATA_UI, SUPPLEMENTAL_LOG_DATA_FK, SUPPLEMENTAL_LOG_DATA_ALL from v$database;
NAME                        SUPPLEMENTAL_LOG_DATA_MI SUPPLEMEN SUPPLEMEN SUPPLEMEN SUPPLEMEN
--------------------------- ------------------------ --------- --------- --------- ---------
GOLDENGATE                  NO                          NO        NO       NO         NO

En conclusion il semblerait que GoldenGate interfère dans l’exploitation courante d’une base de données Oracle et plus particulièrement avec les dernières versions d’Oracle 11gR2, ainsi avec Integrated Golden Gate il devient impossible de supprimer les fichiers d’archive avec recovery manager ‘rman’ tant que le processus d’extraction GoldenGate est actif ce qui est quand même embarrassant et risque de modifier votre stratégie de sauvegarde des archives. La colonne ‘session_restart_scn’ de la vue ‘v$streams_capture’ vous retournera le SCN à partir duquel l’extraction de GoldenGate débute et donc du numéro de séquence de l’archive qui ne sera pas supprimée par ‘rman’.