1. Start
  2. Unternehmen
  3. Blog
  4. Synchronisation von Quest SharePlex Replikationen - compare and repair

Synchronisation von Quest SharePlex Replikationen - compare and repair

Veröffentlicht
Author
Start the Conversation
0 Comments
Categories

1. Ausgangssituation

In diesem Beispiel werden die Daten einer Source PDB einer Containerdatenbank 19c auf eine Target PDB einer anderen Containerdatenbank repliziert.
Nachfolgend sind die tnsnames.ora beider Hosts zu sehen.

tnsnames.ora auf beiden Hosts

PDB11_SOURCE =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = lehrvpc233.edu.robotron.de)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = PDB11)
    )
  )

PDB11_TARGET =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = lehrvpc234.edu.robotron.de)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = PDB11)
    )
  )
Beide Hosts sind für die Quest-Replikation mit SharePlex vorbereitet.
Shareplex ist auf beiden Hosts gestartet.

2. Aktivierung der SharePlex-Konfiguration

In diesem Beispiel sollen alle Tabellen des Nutzers scott von PDB11_SOURCE auf PDB11_TARGET repliziert werden.
Anzeige und Verifzierung der Konfiguration:

 

$ cd /home/splex/splex/prod/bin/
$ ./sp_ctrl     
sp_ctrl (lehrvpc233:2100)> view config scott_config.lst
Datasource:o.pdb11_source
#Source Table       Destination Table        Routing Map
expand scott.%      scott.%                  lehrvpc234@o.pdb11_target

sp_ctrl (lehrvpc233:2100)> verify config scott_config_eine_table.lst
  Config scott_config_eine_table.lst is valid
  View detailed config in /home/splex/splex/var/temp/scott_config_eine_table.lst

 

Die Konfiguration ist gültig und kann deshalb jetzt aktiviert werden.

 

sp_ctrl (lehrvpc233:2100)> activate config scott_config.lst
sp_ctrl (lehrvpc233:2100)> list config
File   Name                                         State       Datasource     
--------------------------------------------------  ----------  ---------------
scott_config_eine_table.lst                         Inactive    o.ORCL         
Last Modified At: 19-Jan-22 15:13    Size: 123   
scott_config.lst                                    Active      o.pdb11_source 
Last Modified At: 31-Jan-22 09:19    Size: 154     Internal Name: .conf.21

 

Die gewünschte Konfiguration ist aktiviert und die Replikation läuft.

 

sp_ctrl (lehrvpc233:2100)> show config

Tables Replicating with Key:

  "SCOTT"."DEPT"   KEY: DEPTNO
  "SCOTT"."EMP"   KEY: EMPNO

Tables Replicating with no key:

  "SCOTT"."SALGRADE"
  "SCOTT"."BONUS"
  "SCOTT"."DEPT_NEU"
…
Total Objects                 :5
Total Objects Replicating     :5
Total Objects Not Replicating :0
…

3. Automatische Replikation bei DDL auf Source

Was passiert beim drop table auf Source ?

 

SCOTT@pdb11_source>drop table dept_neu;

sp_ctrl (lehrvpc233:2100)> show config
…
Total Objects                 :4
Total Objects Replicating     :4
Total Objects Not Replicating :0
…

 

Die Tabelle wurde aus der Replikation entfernt !

Was passiert beim create table auf Source ?

 

SCOTT@pdb11_source>create table dept_neu as select * from dept;

sp_ctrl (lehrvpc233:2100)> show config

Tables Replicating with Key:
…
  "SCOTT"."DEPT_NEU"

File Name  :scott_config.lst
Datasource :pdb11_source
Activated  :31-Jan-22 10:02:18
Actid      :21

Total Objects                 :5
Total Objects Replicating     :5
Total Objects Not Replicating :0

 

Die Tabelle wird wieder neu in die Replikation aufgenommen. Entsprechend der Standardeinstellungen von SharePlex werden alle DDLs der Source entsprechend der in der Konfiguration enthaltenen Objekte repliziert.
In diesem Beispiel gilt das für alle Tabellen des Nutzers SCOTT.

4. Erkennen und Reparieren von "Out of Sync"-Situationen

Der Target Host bleibt bei der Shareplex-Replikation im read write Modes.

Im folgenden 1. Szenario werden deshalb auf der Target "versehentlich" Datensätze gelöscht.

 

SCOTT@pdb11_target>delete from dept_neu;
6 rows deleted.
SCOTT@pdb11_target>commit;

 

Die Replikation mit neuen Datensätzen klappt immer noch, da die Replikation von der Source gesteuert wird.

 

SCOTT@pdb11_source>insert into dept_neu values(70,'Training','Chemnitz');
SCOTT@pdb11_source>commit;

SCOTT@pdb11_target>select * from dept_neu;

    DEPTNO DNAME	  LOC
---------- -------------- -------------
	70 Training	  Chemnitz

 

 Aber mit den beiden folgenden Kommandos erkennt man, dass die Tabelle scott.dept_neu "Out of Sync" ist.

 

sp_ctrl (lehrvpc233:2100)> compare scott.% to scott.% at lehrvpc234@o.pdb11_target for o.pdb11_source

  comparing 5 of 5 objects
  compare started; job id 1

sp_ctrl (lehrvpc233:2100)> compare status      ( oder repair status)

Job ID    : 1
PID       : 242648
Host      : lehrvpc233
Started   : 31-Jan-2022 11:43:22
Job Type  : Compare
Status    : Done - 5 objects completed

ID     Tablename                            Status         Time         Total Rows %Comp Total Time  
------ ------------------------------------ -------------- ------------ ---------- ----- ------------
3      "SCOTT"."DEPT_NEU"                   Out Sync                N/A          7   100         0:06

 

Jetzt erfolgt die Reparatur der unsynchronisierten Tabelle.

 

sp_ctrl (lehrvpc233:2100)> repair status

Job ID    : 3
PID       : 242821
Host      : lehrvpc233
Started   : 31-Jan-2022 11:55:29
Job Type  : Repair
Status    : Done - 5 objects completed

ID     Tablename                            Status         Time         Total Rows %Comp Total Time  
------ ------------------------------------ -------------- ------------ ---------- ----- ------------
3      "SCOTT"."DEPT_NEU"                   Repaired                N/A          7   100         0:11

SCOTT@pdb11_target>select * from dept_neu order by deptno ;

    DEPTNO DNAME	  LOC
---------- -------------- -------------
	10 ACCOUNTING	  NEW YORK
	20 RESEARCH	  DALLAS
	30 SALES	  CHICAGO
	40 OPERATIONS	  BOSTON
	50 Training	  Dresden
	60 Training	  Leipzig
	70 Training	  Chemnitz

sp_ctrl (lehrvpc233:2100)> compare scott.% to scott.% at lehrvpc234@o.pdb11_target for o.pdb11_source

sp_ctrl (lehrvpc233:2100)> repair status

Job ID    : 6
PID       : 242976
Host      : lehrvpc233
Started   : 31-Jan-2022 11:58:59
Job Type  : Compare
Status    : Processing - 5 objects completed

 

Jetzt sind Source und Target wieder synchron, was sowohl der Datenvergleich wie auch die erneute Anwendung des compare Statements zeigt.

Im 2. Szenario wird "versehentlich" die komplette Tabelle auf dem Ziel gelöscht !

 

SCOTT@pdb11_target>drop table dept_neu;

sp_ctrl (lehrvpc233:2100)> compare scott.% to scott.% at lehrvpc234@o.pdb11_target for o.pdb11_source
sp_ctrl (lehrvpc233:2100)> repair status

Job ID    : 7
PID       : 243600
Host      : lehrvpc233
Started   : 31-Jan-2022 13:11:11
Job Type  : Compare
Status    : Processing - 5 objects completed

ID     Tablename                            Status         Time         Total Rows %Comp Total Time  
------ ------------------------------------ -------------- ------------ ---------- ----- ------------
3      "SCOTT"."DEPT_NEU"                   Error                   N/A          5               0:09

 

Wie der Status "error" zeigt, funktioniert die Replikation nicht mehr, auch das folgende repair-Kommando bringt kein Lösung.
Der compare-Status bleibt auf den Status "error".

 

sp_ctrl (lehrvpc233:2100)> repair scott.% to scott.% at lehrvpc234@o.pdb11_target for o.pdb11_source

sp_ctrl (lehrvpc233:2100)> compare status
…
ID     Tablename                            Status         Time         Total Rows %Comp Total Time  
------ ------------------------------------ -------------- ------------ ---------- ----- ------------
3      "SCOTT"."DEPT_NEU"                   Error                   N/A          5               0:08

 

Abhilfe schafft in diesem Fall das Neuanlegen der Struktur auf dem Target mit anschließender Synchronisation.

 

SCOTT@pdb11_target>create table dept_neu as select * from dept where 1=2;
sp_ctrl (lehrvpc233:2100)> compare scott.% to scott.% at lehrvpc234@o.pdb11_target for o.pdb11_source
sp_ctrl (lehrvpc233:2100)> compare status
…

ID     Tablename                            Status         Time         Total Rows %Comp Total Time  
------ ------------------------------------ -------------- ------------ ---------- ----- ------------
3      "SCOTT"."DEPT_NEU"                   Out Sync                N/A          7   100         0:04

sp_ctrl (lehrvpc233:2100)> repair scott.% to scott.% at lehrvpc234@o.pdb11_target for o.pdb11_source
sp_ctrl (lehrvpc233:2100)> compare status
…

ID     Tablename                            Status         Time         Total Rows %Comp Total Time  
------ ------------------------------------ -------------- ------------ ---------- ----- ------------
3      "SCOTT"."DEPT_NEU"                   Repaired                N/A          7   100         0:11

sp_ctrl (lehrvpc233:2100)> compare scott.% to scott.% at lehrvpc234@o.pdb11_target for o.pdb11_source
sp_ctrl (lehrvpc233:2100)> repair status
Job ID    : 11
PID       : 243909
Host      : lehrvpc233
Started   : 31-Jan-2022 13:30:59
Job Type  : Compare
Status    : Done - 5 objects completed

 

Damit ist auch in diesem Fall die Synchronsation der Tabelle "SCOTT"."DEPT_NEU" vollständig gelungen.

Zusammenfassung

In diesem Blogeintrag wurde gezeigt, wie mit SharePlex ein Erkennen und Reparieren von Strukturen möglich ist, die "Out of Sync" geworden sind.
Ergänzend sei erwähnt, dass auch ein Test ganzer Konfigurationen auf Synchronität möglich ist.

Dazu stehen die folgenden beiden Statements zur Verfügung.

compare using konfiguration1.lst
repair using konfiguration1.lst

Allerdings ist bei der Anwendung Vorsicht geboten, da eine große Anzahl von zu überprüfenden Tabellen unter Umständen zu sehr langen Laufzeiten führen kann.

Kommentare

Keine Kommentare

Kommentar schreiben

* Diese Felder sind erforderlich