1. Bereitstellung und Bereitstellung einer Lösung für maximale Verfügbarkeit für PeopleSoft in Oracle Cloud
  2. Für Datenbankmigration konfigurieren
  3. Zukünftige sekundäre Datenbank einrichten

Zukünftige sekundäre Datenbank einrichten

Nachdem Sie die erste physische Standbydatenbank in Oracle Cloud Infrastructure (OCI) eingerichtet haben, erstellen Sie eine zweite Standbydatenbank in einer anderen Region. Diese zweite Datenbank ist die Datenbank in Ihrer cloudbasierten Disaster Recovery-Umgebung.

Die Oracle Data Guard kaskadierende Standby-Funktionalität, bei der die zweite Standbydatenbank ihre redo von der ersten Standbydatenbank und nicht direkt von der On-Premise-Primärdatenbank empfängt, reduziert den Netzwerktraffic von der On-Premise-Hostsite. Außerdem wird festgelegt, was letztendlich die Hauptpropagierungsroute redo sein wird.

Zu diesem Zeitpunkt gibt es Einschränkungen, die uns daran hindern, OCI-Tools zu verwenden, um unsere zukünftige Disaster Recovery-Datenbank einzurichten und vollständig zu verwalten. Der Oracle Data Guard-Verknüpfungs-Cloud-Service kann derzeit keine vorhandene Standbydatenbankbeziehung registrieren und die Standbydatenbankkonfiguration nicht verwalten. Beispiel: Oracle Managed Disaster Recovery Cloud Service kann nicht verwendet werden.

Da beide Standbydatenbanken mit einer OCI-basierten Platzhalterdatenbank eingerichtet sind, kann die OCI-Control Plane das Patching und andere Lebenszyklusaktivitäten für jede dieser Datenbanken verwalten.

Platzhalterdatenbank erstellen

Mit der OCI-Konsole können Sie eine neue Platzhalterdatenbank in einer anderen Region (empfohlen) oder in einer anderen Availability-Domain in derselben Region erstellen.

Führen Sie die folgenden Schritte aus. Löschen Sie die Platzhalterdatenbank NICHT mit Tools wie OCI oder dbaascli.
  1. Wählen Sie Exadata auf Oracle Public Cloud aus. Wählen Sie den Oracle Exadata Database Service on Dedicated Infrastructure-Service aus, in dem Sie die Datenbank bereitstellen möchten.

    Befolgen Sie diese Constraints:

    • Das Datenbank-Home muss sich auf derselben Softwareversion, demselben Release und derselben Patchebene wie die Quelle befinden.
    • DB_NAME muss mit der Primär- und der ersten Standbydatenbank identisch sein.
    • DB_UNIQUE_NAME kann leer gelassen oder angegeben werden, muss sich jedoch von der On-Premise-Primär- und der ersten physischen Standbydatenbank unterscheiden.
    • Konfigurieren Sie beim Provisioning dieser Datenbank keine automatischen Backups.
    • Geben Sie beim Provisioning dieser Datenbank keinen PDB-Namen an.
  2. Erfassen Sie die kaskadierenden Standbykonfigurationsdaten.
    1. Melden Sie sich als BS-Benutzer oracle auf einem der Datenbankknoten an, auf dem die gerade erstellte Platzhalterdatenbank gehostet wird.
    2. Quelle der Umgebung für diese Datenbank.
    3. Führen Sie den folgenden Befehl mit DB_UNIQUE_NAME aus:
    $ srvctl config database -db DB_UNIQUE_NAME
    Speichern Sie diese Konfigurationsdaten. Sie werden sie in mehreren Schritten unten verwenden.
  3. Stoppen Sie die Platzhalterdatenbank.
    $ srvctl stop database -db cascade standby placeholder database -stopoption immediate
  4. Melden Sie sich als BS-Benutzer "grid" an. Löschen Sie mit dem Befehl asmcmd die Dateien in den Verzeichnissen unter +DATAC1/DB_UNIQUE_NAME:
    1. DATAFILE
    2. ONLINELOG
    3. Alle PDB GUID/DATAFILE
    4. Alle Kontrolldateien unter +DATAC1/DB_UNIQUE_NAME/CONTROLFILE
    5. Die Kennwortdatei, wie in den in Schritt 1 erfassten Konfigurationsdaten angegeben
  5. Entfernen Sie unter +RECOC1/DB_UNIQUE_NAME die Dateien in den Verzeichnissen ARCHIVELOG, AUTOBACKUP und FLASHBACKLOG.
  6. Entfernen Sie die spfile nicht.

Datenbankwiederherstellung vorbereiten

Konfigurieren Sie das neue Oracle Home, um die Wiederherstellung der Datenbank vorzubereiten.

  • Passen Sie die Datei tnsnames.ora in jeder Umgebung an, um sich über jede der anderen Datenbanken zu informieren. Prüfen Sie die Kommunikation zwischen Umgebungen.
  • Kopieren Sie die Kennwortdatei aus der ersten Standbydatenbank.
  • Kopieren Sie das Wallet Transparente Datenverschlüsselung (TDE) aus der ersten Standbydatenbank.
  • Passen Sie die Datenbankparameter für die kaskadierende Standby-Datenbank an.

TNS für kaskadierende Standbydatenbank konfigurieren

Passen Sie die Datei tnsnames.ora in jeder Umgebung an, um sich über jede der anderen Datenbanken zu informieren. Prüfen Sie die Kommunikation zwischen Umgebungen.

Data Guard Broker muss mit jeder Datenbank in der Konfiguration kommunizieren können, unabhängig davon, mit welcher Instanz er verbunden ist. Oracle Zero Downtime Migration hat diese Konfiguration für die anfängliche Standbybeziehung ausgeführt. Sie müssen die kaskadierende Standby-Datenbank zur Konfiguration hinzufügen:
  • Fügen Sie die TNS-Verbindungszeichenfolge für die kaskadierende Standbydatenbank zu den tnsnames.ora-Dateien hinzu, die von allen Oracle Real Application Clusters-(Oracle RAC-)Instanzen der On-Premise-Primärdatenbank und der ersten Standbydatenbank verwendet werden
  • Fügen Sie die TNS-Verbindungszeichenfolgen für die On-Premise-Primärdatenbank und die ersten OCI-Standbydatenbanken zu den tnsnames.ora-Dateien hinzu, die von allen Oracle RAC-Instanzen der kaskadierenden Standbydatenbank verwendet werden.
Diese TNS-Einträge müssen jeweils SCAN IP-Adressen und nicht den SCAN-Namen verwenden. Im Folgenden finden Sie ein Beispiel für einen konformen TNS-Eintrag, den Oracle Zero Downtime Migration für die erste Standbydatenbank erstellt hat: 
CDBHCM_iad1dx =
          (DESCRIPTION =
             (ADDRESS = (PROTOCOL = TCP) (HOST = <SCAN IPv4 address  1>) (PORT = 1521))
             (ADDRESS = (PROTOCOL = TCP) (HOST = <SCAN IPv4 address  2>) (PORT = 1521))
             (ADDRESS = (PROTOCOL = TCP) (HOST = <SCAN IPv4 address  3>)) (PORT = 1521))
            (CONNECT_DATA =
              (SERVER = DEDICATED)
              (SERVICE_NAME = CDBHCM_iad1dx)
              (FAILOVER_MODE =
                  (TYPE = select)
                  (METHOD = basic)
              )
              (UR=A)
             )
          )

Sie müssen sich bei jedem Datenbankserver als BS-Benutzer "oracle" anmelden und die Umgebung beziehen. Wechseln Sie dann in das Verzeichnis $TNS_ADMIN.

  1. Bearbeiten Sie für jede Oracle RAC-Instanz sowohl der On-Premise-Primär- als auch der ersten OCI-Standbydatenbank die Datei tnsnames.ora, und fügen Sie die TNS-Verbindungszeichenfolge für die kaskadierende Standbydatenbank hinzu.
  2. Bearbeiten Sie für jede Oracle RAC-Instanz der OCI-Kaskadenstandbydatenbank die Datei tnsnames.ora, und fügen Sie TNS-Verbindungszeichenfolgen für die On-Premise-Primär- und die erste OCI-Standbydatenbank hinzu.
  3. Testen Sie, ob Sie die erste Standbydatenbank aus der kaskadierenden Standbydatenbank pingen können. Verwenden Sie dazu das Utility tnsping mit dem hinzugefügten Verbindungszeichenfolgenalias.
    $ tnsping CDBHCM_iad1dx
    Dies sollte OK mit Latenzzeit in Millisekunden zurückgeben. Wenn OK nicht zurückgegeben wird, prüfen Sie auf Fehler, und beheben Sie sie entsprechend.
  4. Testen Sie die Verbindung von jedem der Datenbankserver, auf dem die kaskadierende Standbydatenbank gehostet wird, zur ersten Standbydatenbank (CDBHCM_iad1dx) mit SQL*Plus. Sie benötigen das Kennwort SYS für die Primärdatenbank.
    $ sqlplus sys/<password>@CDBHCM_iad1dx as sysdba
    Beheben Sie alle Fehler, und wiederholen Sie den Vorgang, bis die Verbindung erfolgreich hergestellt werden kann.

Kennwortdatei kopieren

Kopieren Sie die Kennwortdatei aus der ersten Standbydatenbank.

  1. Melden Sie sich bei einem der Server an, auf denen die erste Standbydatenbank (CDBHCM_iad1dx) als BS-Benutzer "oracle" gehostet wird.
  2. Verwenden Sie srvctl, um zu bestimmen, wo sich die Kennwortdatei für diese Datenbank befindet, und kopieren Sie sie dann in das Verzeichnis /tmp.
    Um den Wallet-Root-Speicherort zu bestimmen, führen Sie den folgenden Befehl als sysdba aus:
    $ srvctl config database -db first standby db name
  3. Suchen Sie nach der Zeile mit der Bezeichnung "Kennwortdatei:" und notieren Sie den Speicherort (Pfad zu Oracle Automatic Storage Management (Oracle ASM)).
  4. Melden Sie sich als Grid-BS-Benutzer an, und kopieren Sie die Kennwortdatei mit dem Befehl asmcmd in das Verzeichnis /tmp:
    $ asmcmd -p
asmcmd> cd +DATAC1/path from step 3
asmcmd> cp <password file name> /tmp/password file name
  5. Übertragen Sie die Kennwortdatei mit scp an einen temporären Speicherort auf einem der kaskadierenden Standbydatenbankserver oder auf beliebige Weise zum Übertragen von Dateien in OCI.
  6. Melden Sie sich als Grid-BS-Benutzer bei dem kaskadierenden Standby-Datenbankserver an, auf dem die Kennwortdatei gespeichert wurde. Kopieren Sie die Kennwortdatei in Oracle ASM. Verwenden Sie dazu den Speicherort, der in den oben angegebenen kaskadierenden Standbykonfigurationsdaten angegeben ist.
    $ asmcmd -p --privilege sysdba
asmcmd> pwcopy –dbuniquename cascade standby db unique name /tmp/password-file-name +ASM Diskgroup/path/password-file-name -f
    Beispiel: 
    asmcmd> pwcopy –dbuniquename CDBHCM_phx5s   /tmp/password file name +DATAC1/CDBHCM_phx5s/PASSWORD/orapwCDBHCM_phx5s -f
  7. Stellen Sie sicher, dass alle TNS-Verbindungszeichenfolgen korrekt konfiguriert sind, indem Sie prüfen, ob jede Datenbank eine Verbindung zu allen anderen Datenbanken herstellen kann. Beheben Sie alle Verbindungsfehler für die folgenden Verbindungsversuche, die nicht erfolgreich sind.
    1. Aus der On-Premise-Datenbank (primäre Datenbank):
      $ sqlplus sys/password@first standby db as sysdba
$ sqlplus sys/password@cascade standby db as sysdba
    2. Von der ersten physikalischen Standby-Datenbank:
      $ sqlplus sys/password@on-prem primary as sysdba
$ sqlplus sys/password@cascade standby db as sysdba
    3. Aus der kaskadierenden physikalischen Standby-Datenbank:
      $ sqlplus sys/password@on-prem primary as sysdba
$ sqlplus sys/password@first standby db as sysdba
    Fahren Sie erst fort, wenn alle Verbindungsversuche erfolgreich waren.

TDE-Wallet kopieren

Kopieren Sie das Wallet Transparente Datenverschlüsselung (TDE) aus der ersten Standbydatenbank. In Oracle Exadata Database Service on Dedicated Infrastructure befindet sich der Speicherort, den das Cloud-Tooling zum Speichern der TDE-Wallets verwendet, in Oracle Advanced Cluster File System (Oracle ACFS), das alle Datenbankserver im Cluster gemeinsam verwenden.
  1. Melden Sie sich bei einem der Server an, auf denen die erste Standbydatenbank (CDBHCM_iad1dx) als BS-Benutzer oracle gehostet wird, und wechseln Sie in das Wallet-Root-Verzeichnis.
    Um den Wallet-Root-Speicherort zu bestimmen, führen Sie den folgenden Befehl als sysdba aus:
    $ sqlplus / as sysdba
SQL> show wallet_root
$ cd wallet root location from “show wallet_root” above
  2. Gehen Sie zum Wallet-Root-Verzeichnis, und komprimieren Sie das Verzeichnis tde.
    Das Verzeichnis tde befindet sich unter dem Verzeichnis im 1. Schritt, das in der Regel /var/opt/oracle/dbaas_acf/<DB_NAME>/wallet_root ist. 
    $ zip -r CDBHDM_tde_wallet.zip  tde
  3. Übertragen Sie diese ZIP-Datei auf einen der Datenbankserver, auf dem die kaskadierende Datenbank (CDBHCM_phx5s) gehostet wird, an einen temporären Speicherort (z.B. /tmp).
    Verwenden Sie scp oder auf beliebige Weise, um Dateien in OCI zu übertragen.
  4. Melden Sie sich bei den Datenbankservern an, auf denen die kaskadierende Datenbank (CDBHCM_phx5s) gehostet wird und auf denen sich die ZIP-Datei befand, als BS-Benutzer oracle an, und wechseln Sie in das Wallet-Root-Verzeichnis.

    Der Speicherort muss mit dem vorherigen identisch sein, da DB_NAME identisch ist (CDBHCM). 

    $ cd /var/opt/oracle/dbaas_acf/<DB_NAME>/wallet_root
  5. Verschieben Sie das vorhandene TDE-Verzeichnis in einen anderen Namen.
    $ mv tde tde_date
  6. Verschieben Sie die ZIP-Datei mit dem in Schritt 2 erstellten TDE-Wallet (CDBHDM_tde_wallet.zip) in den folgenden Pfad:/var/opt/oracle/dbaas_acf/<DB_NAME>/wallet_root.
    Ersetzen Sie DB_NAME durch den Namen der Datenbank.
  7. Dekomprimieren Sie die Datei CDBHDM_tde_wallet.zip.
    $ unzip CDBHDM_tde_wallet.zip

Dadurch wird ein neues Unterverzeichnis tde mit den Wallet-Dateien aus der ersten physischen Standbydatenbank erstellt.

Datenbankparameter für kaskadierende Standby-Datenbank anpassen

Schließen Sie die Konfiguration der kaskadierenden Standby-Datenbank ab.

  1. Melden Sie sich bei einem der Server an, auf dem die erste Standbydatenbank (CDBHCM_iad1dx) als Benutzer oracle OS gehostet wird, und beziehen Sie die Umgebung. 
    $ . ./CDBHCM.env
  2. Erstellen Sie eine PFILE aus der ersten Standby-Datenbank, die als Referenz zum Anpassen der Parameter in der kaskadierenden Standby-Datenbank verwendet werden soll.
    $ cd $ORACLE_HOME/dbs
$ sqlplus / as sysdba
SQL> create pfile=’tmp_CDBHCM_iad1dx_init.ora’ from spfile;
  3. Melden Sie sich bei einem der Datenbankserver an, auf dem die kaskadierende Standbydatenbank (CDBHCM_phx5s) gehostet wird, und beziehen Sie die Umgebung:
    $ . ./CDBHCM.env
  4. Starten Sie NOMOUNT auf einer Instanz.
    $ sqlplus / as sysdba
SQL> startup nomount
  5. Nehmen Sie die folgenden Anpassungen an den Datenbankparametern für die kaskadierende Datenbank vor, und verweisen Sie dabei auf die Liste der Datenbankparameter aus Schritt 2 oben:
    SQL> alter system set control_files=’’ sid=’*’ scope=spfile;
SQL> alter system set undo_tablespace=’<Refer to the parameter list from step 2>’ sid=’<ORACLE_SID for instance 1>’ scope=spfile;
SQL> alter system set undo_tablespace=’<Refer to the parameter list from step 2>’ sid=’<ORACLE_SID for instance 2>’ scope=spfile;
SQL> alter system set undo_tablespace=’<Refer to the parameter list from step 2>’ sid=’<ORACLE_SID for instance N>’ scope=spfile;
SQL> alter system set sga_target=’<Refer to the parameter list from step 2>’ sid=’*’ scope=spfile;
SQL> alter system set log_buffer=’<Refer to the parameter list from step 2>’ sid=’*’ scope=spfile;
  6. Passen Sie die spezifischen Parameter für PeopleSoft an.
    SQL> alter system set “_gby_hash_aggregation_enabled”=false sid=’*’ scope=spfile;
SQL> alter system set “_ignore_desc_in_index”=true sid=’*’ scope=spfile;
SQL> alter system set “_unnest_subquery”=true sid=’*’ scope=spfile;
SQL> alter system set nls_length_semantics='CHAR' sid=’*’ scope=spfile;

    Hinweis:

    Ändern Sie die folgenden Parameter nicht:
    • DB_NAME
    • DB_UNIQUE_NAME
    • WALLET_ROOT
  7. Fahren Sie NOMOUNT auf der Instanz herunter, und starten Sie sie neu, um die Änderungen zu implementieren.
    $ sqlplus / as sysdba
SQL> shutdown immediate
SQL> startup nomount

Datenbank in der kaskadierenden Standby-Datenbank wiederherstellen

Schreiben Sie die Datenbank aus der ersten physischen Standbydatenbank in den kaskadierenden Standby-Footprint zurück. Schreiben Sie die Kontrolldatei und die Datendateien mit dem Oracle Recovery Manager (RMAN)-Befehl RESTORE FROM SERVICE zurück.

  1. Wenn die Instanz für die kaskadierende Standbydatenbank nicht gestartet wird, starten Sie sie in NOMOUNT:
    $ sqlplus / as sysdba 
$ SQL> startup nomount
  2. Mit RMAN können Sie die Kontrolldatei und Datendateien von der ersten Standbydatenbank in die kaskadierende Standbydatenbank zurückschreiben.

    Hinweis:

    Möglicherweise müssen Sie die Anzahl der RMAN-Kanäle für "Gerätetypdatenträger" anpassen, um das Netzwerk nicht zu überlasten. Wenn eine Änderung erforderlich ist, führen Sie dies aus, bevor Sie den Befehl "Datenbank aus Service wiederherstellen" ausführen. Sie können dies mit dem folgenden Befehl tun, indem Sie N nach Bedarf ersetzen: 
    RMAN> CONFIGURE DEVICE TYPE DISK PARALLELISM N; 
    $ rman target / nocatalog
RMAN> restore standby controlfile from service ‘first standby db name’;
RMAN> alter database mount;
RMAN> restore database from service ‘first standby db name’ section size 8G;
RMAN> shutdown immediate;
RMAN> exit
  3. Starten Sie alle Instanzen neu, und mounten Sie die kaskadierende Standbydatenbank mit srvctl.
    $ srvctl start database -db cascade standby db unique name -startoption mount
  4. Erstellen und löschen Sie alle Online- und Standby-Logdateien mit dem folgenden Skript.
    $ sqlplus “/ as sysdba”
SQL> set pagesize 0 feedback off linesize 120 trimspool on
SQL> spool /tmp/clearlogs.sql
SQL> select distinct 'alter database clear logfile group '||group#||';' from v$logfile;
SQL> spool off
  5. Prüfen Sie das generierte Skript clearlogs.sql, bevor Sie es ausführen. Dadurch wird die Datenbankinstanz sowohl Online- als auch Standby-Logdateien für alle Threads erstellen und löschen. Führen Sie dann das Skript aus.
    SQL> @/tmp/clearlogs.sql

Data Guard Broker für die kaskadierende Standbydatenbank konfigurieren

Sie haben Data Guard Broker bereits von Oracle Zero Downtime Migration zwischen der On-Premise-Primär- und der ersten OCI-Standbydatenbank konfiguriert. Jetzt fügen Sie die kaskadierende Standbydatenbank zur Konfiguration hinzu.

Die kaskadierende Standbydatenbank und die On-Premise-Datenbanken kommunizieren nicht direkt miteinander. Bei Bedarf wird ihre redo über die erste On-Premise-Standbydatenbank gesendet:

  • Wenn die On-Premise-Datenbank primär ist, wird redo von der On-Premise-Primärdatenbank an oder über die erste Standbydatenbank und dann an die kaskadierende Standbydatenbank gesendet:
    • On-Premise-Primärdatenbank zur ersten OCI-Standbydatenbank
    • OCI First Standby zur OCI Cascade Standby
  • Wenn sich die erste Standbydatenbank in der Primärrolle befindet, wird redo von dieser Datenbank direkt an die On-Premise- und die kaskadierende Standbydatenbank gesendet:
    • OCI primär zur On-Premise-Standbydatenbank
    • OCI-Primärinstanz zur OCI-Kaskadenstandbydatenbank
  • Wenn die kaskadierende Standbydatenbank in dieser Konfiguration zur Primärdatenbank wird, wird Redo von dieser Datenbank an oder über die erste OCI-Standbydatenbank und dann an die On-Premise-Datenbank gesendet:
    • Erste OCI-Standbydatenbank zur On-Premise-Standbydatenbank
    • OCI kaskadiert Primärdatenbank zur ersten OCI-Standbydatenbank
  1. Konfigurieren Sie Data Guard Broker auf dem Datenbankserver, der die kaskadierende Standbydatenbank hostet. Melden Sie sich bei einem der Datenbankserver an, auf dem die kaskadierende Standbydatenbank als Benutzer des Betriebssystems oracle gehostet wird, und beziehen Sie die Umgebung. 
    $ sqlplus / as sysdba
SQL> alter system set dg_broker_config_file1=’+DTAC1/cascade standby db/DG/dr1 cascade standby db.dat’ sid=’*’ scope=both;
SQL> alter system set dg_broker_config_file2=’+RECOC1/cascade standby db/DG/dr2 cascade standby db.dat’ sid=’*’ scope=both;
SQL> alter system set dg_broker_start=TRUE sid=’*’ scope=both;
  2. Melden Sie sich bei der primären oder der ersten physischen Standbydatenbank an, und beziehen Sie die Umgebung. Fügen Sie der vorhandenen Data Guard Broker-Konfiguration die neue kaskadierende Standbydatenbank hinzu.
    $ dgmgrl 
DGMGRL>  connect sys/password
DGMGRL> show configuration
DGMGRL> add database 'cascade standby db’
 as connect identifier is cascade standby db;
  3. Fügen Sie redo routes hinzu.
    DGMGRL> edit database on-premises db set property redoroutes='(LOCAL : first standby db ASYNC)';
DGMGRL> edit database first standby db set property redoroutes='(LOCAL : on-premises db ASYNC, cascade standby db ASYNC)(on-premises db : cascade standby db ASYNC)(cascade standby db : on-premises db ASYNC)';
DGMGRL> edit database cascade standby db set property redoroutes='(LOCAL : first standby db ASYNC)';
  4. Aktivieren Sie die neue kaskadierende Standby-Datenbank.
    DGMGRL> enable database cascade standby db;
  5. Sobald die kaskadierende Datenbank aktiviert ist, erhält sie redo, das von der On-Premise-Primärdatenbank über die erste Standbydatenbank generiert wird. Zeigen Sie in Data Guard Broker die Konfiguration an:
    DGMGRL> show configuration lag
Configuration - zdm_psfthcm_dg
  Protection Mode: MaxPerformance
  Members:
  CDBHCM_sca6dp  - Primary database
    CDBHCM_iad1dx - Physical standby database 
                      Transport Lag:      0 seconds (computed 0 seconds ago)
                      Apply Lag:          0 seconds (computed 1 second ago)
      CDBHCM_phx5s - Physical standby database (receiving current redo)
                        Transport Lag:      1 second (computed 1 second ago)
                        Apply Lag:          2 seconds (computed 1 second ago)

Fast-Start Failover:  Disabled

Configuration Status:
SUCCESS   (status updated 47 seconds ago)

Rollenbasierte Datenbankservices für die zukünftige Standbydatenbank definieren

Fügen Sie rollenbasierte Datenbankservices hinzu, die von der Anwendung PeopleSoft verwendet werden, wenn die sekundäre OCI-Datenbank die Rolle PRIMARY ausfüllt.

  1. Fügen Sie rollenbasierte Datenbankservices für den Prozessplaner hinzu.
    srvctl add service -db CDBHCM_phx5s -pdb HR92U033 -service HR92U033_BATCH -preferred "CDBHCM1,CDBHCM2" -notification TRUE -role PRIMARY -failovermethod BASIC -failovertype AUTO -failoverretry 10 -failoverdelay 3
  2. Fügen Sie rollenbasierte Datenbankservices für die Onlinebenutzer hinzu. 
    srvctl add service -db CDBHCM_phx5s -pdb HR92U033 -service HR92U033_ONLINE -preferred "CDBHCM1,CDBHCM2" -notification TRUE -role PRIMARY -failovermethod BASIC -failovertype AUTO -failoverretry 10 -failoverdelay 3