Intelligenza artificiale
TR-4981: Riduzione dei costi di Oracle Active Data Guard con Amazon FSX ONTAP
Suggerisci modifiche
PDF
Allen Cao, Niyaz Mohamed, NetApp
Scopo
Oracle Data Guard garantisce disponibilità elevata, protezione dei dati e ripristino di emergenza per i dati aziendali in una configurazione di replica del database primario e di standby. Oracle Active Data Guard consente agli utenti di accedere ai database di standby mentre la replica dei dati è attiva dal database principale ai database di standby. Data Guard è una funzionalità di Oracle Database Enterprise Edition. Non richiede licenze separate. D'altra parte, Active Data Guard è un'opzione Oracle Database Enterprise Edition, pertanto richiede licenze separate. Più database di standby possono ricevere la replica dei dati da un database primario nella configurazione di Active Data Guard. Tuttavia, ogni database di standby aggiuntivo richiede una licenza Active Data Guard e un'ulteriore capacità di archiviazione come dimensione del database primario. I costi operativi si sommano rapidamente.
Se sei entusiasta di ridurre i costi operativi del tuo database Oracle e stai pianificando di configurare un sistema Active Data Guard in AWS, dovresti prendere in considerazione un'alternativa. Invece di Active Data Guard, utilizza Data Guard per eseguire la replica dal database primario a un singolo database di standby fisico sullo storage Amazon FSX ONTAP. Successivamente, è possibile clonare e aprire più copie di questo database di standby per accedere in lettura/scrittura e soddisfare molti altri casi d'utilizzo, come creazione di report, sviluppo, test, ecc. I risultati della rete offrono in modo efficace le funzionalità di Active Data Guard eliminando al contempo la licenza di Active Data Guard e i costi di storage aggiuntivi per ogni database di standby aggiuntivo. In questa documentazione, dimostreremo come configurare Oracle Data Guard con il database primario esistente in AWS e posizionare il database di standby fisico sullo storage Amazon FSX ONTAP. Il backup del database di standby viene eseguito tramite snapshot e clonato per l'accesso in lettura/scrittura per i casi d'utilizzo, in base alle necessità.
Questa soluzione risolve i seguenti casi di utilizzo:
-
Oracle Data Guard tra un database primario su qualsiasi storage in AWS e il database in standby sullo storage Amazon FSX ONTAP.
-
Clonazione del database in standby mentre è chiuso per la replica dei dati per casi di utilizzo come reporting, sviluppo, test, ecc.
Pubblico
Questa soluzione è destinata alle seguenti persone:
-
Un DBA che ha configurato Oracle Active Data Guard in AWS per garantire disponibilità elevata, protezione dei dati e disaster recovery.
-
Un Solution Architect per database interessato alla configurazione di Oracle Active Data Guard nel cloud AWS.
-
Un amministratore dello storage che gestisce lo storage AWS FSX ONTAP con supporto per Oracle Data Guard.
-
Proprietario di applicazioni che desidera supportare Oracle Data Guard in un ambiente AWS FSX/EC2.
Ambiente di test e convalida della soluzione
Il test e la convalida di questa soluzione sono stati eseguiti in un ambiente di laboratorio AWS FSX ONTAP e EC2 che potrebbe non corrispondere all'ambiente di implementazione finale. Per ulteriori informazioni, vedere la sezione [Key Factors for Deployment Consideration].
Architettura
Componenti hardware e software
Hardware |
||
Storage FSX ONTAP |
Versione corrente offerta da AWS |
Un cluster FSX ha nello stesso VPC e nella stessa zona di disponibilità |
Istanza EC2 per il calcolo |
t2.xlarge/4vCPU/16G |
Tre istanze EC2 T2 xlarge EC2, una come server DB primario, una come server DB in standby e la terza come server DB clone |
Software |
||
RedHat Linux |
RHEL-8.6.0_HVM-20220503-x86_64-2-Hourly2-GP2 |
Implementazione dell'abbonamento a RedHat per il test |
Oracle Grid Infrastructure |
Versione 19.18 |
Patch RU applicata p34762026_190000_Linux-x86-64.zip |
Database Oracle |
Versione 19.18 |
Patch RU applicata p34765931_190000_Linux-x86-64.zip |
Oracle OPatch |
Versione 12.2.0.1.36 |
Ultima patch p6880880_190000_Linux-x86-64.zip |
Configurazione di Oracle Data Guard con ipotetica configurazione da NY a LA DR
Database |
DB_UNIQUE_NAME |
Nome servizio netto Oracle |
Primario |
DB1_NY |
db1_NY.demo.netapp.com |
Standby fisico |
DB1_LA |
db1_LA.demo.netapp.com |
Fattori chiave per l'implementazione
-
Come funziona FlexClone Oracle Standby Database. AWS FSX ONTAP FlexClone fornisce copie condivise degli stessi volumi di database di standby scrivibili. Le copie dei volumi sono in realtà puntatori che si ricollegano ai blocchi di dati originali fino all'avvio di una nuova scrittura nel clone. ONTAP alloca quindi nuovi blocchi storage per le nuove scritture. Tutti gli io in lettura sono gestiti da blocchi di dati originali sotto replica attiva. Pertanto, i cloni sono molto efficienti in termini di storage, che possono essere utilizzati per molti altri casi di utilizzo con una nuova allocazione di storage minima e incrementale per i nuovi io in scrittura. Ciò consente un notevole risparmio sui costi di storage riducendo sostanzialmente l'ingombro dello storage di Active Data Guard. NetApp consiglia di ridurre al minimo le attività FlexClone in caso di passaggio del database dallo storage primario allo storage FSX in standby per garantire prestazioni Oracle di alto livello.
-
Requisiti del software Oracle. in generale, un database di standby fisico deve avere la stessa versione iniziale del database principale, incluse le eccezioni al set di patch (PSE), gli aggiornamenti critici delle patch (CPU), e gli aggiornamenti del set di patch (PSU), a meno che non sia in corso un processo di applicazione della patch standby-first di Oracle Data Guard (come descritto nella nota di supporto Oracle 1265700,1 all'indirizzo "support.oracle.com"
-
Considerazioni sulla struttura della directory del database di standby. se possibile, i file di dati, i file di log e i file di controllo sui sistemi primario e di standby devono avere gli stessi nomi e nomi di percorso e utilizzare le convenzioni di denominazione OFA (Optimal Flexible Architecture). Anche le directory di archivio del database di standby devono essere identiche tra i siti, comprese le dimensioni e la struttura. Questa strategia consente ad altre operazioni quali backup, switchover e failover di eseguire la stessa serie di passaggi, riducendo la complessità della manutenzione.
-
Imponi modalità di registrazione. per proteggere dalle scritture dirette non registrate nel database primario che non possono essere propagate al database di standby, attivare IMPONI REGISTRAZIONE nel database primario prima di eseguire i backup dei file di dati per la creazione in standby.
-
Gestione archiviazione database. per semplicità operativa, Oracle consiglia di impostare Oracle Automatic Storage Management (Oracle ASM) e Oracle Managed Files (OMF) in una configurazione Oracle Data Guard in modo simmetrico sui database primari e di standby.
-
Istanze di calcolo EC2. in questi test e convalide, abbiamo utilizzato un'istanza AWS EC2 t2.xlarge come istanza di calcolo del database Oracle. NetApp consiglia di utilizzare un'istanza M5 di tipo EC2 come istanza di calcolo per Oracle nelle implementazioni in produzione, perché è ottimizzata per il carico di lavoro del database. È necessario dimensionare l'istanza EC2 in modo appropriato in base al numero di vCPU e alla quantità di RAM in base ai requisiti effettivi del carico di lavoro.
-
Implementazione di cluster ha storage FSX a singola o multi-zona. in questi test e convalide, abbiamo implementato un cluster ha FSX in una singola zona di disponibilità AWS. Per l'implementazione in produzione, NetApp consiglia di implementare una coppia FSX ha in due diverse zone di disponibilità. Un cluster FSX viene sottoposto a provisioning in una coppia ha sincronizzata in una coppia di file system Active-passive per fornire ridondanza a livello di storage. L'implementazione multi-zona migliora ulteriormente l'alta disponibilità in caso di guasto in una singola zona AWS.
-
Dimensionamento del cluster di storage FSX. un file system di storage Amazon FSX per ONTAP fornisce fino a 160,000 IOPS SSD raw, throughput fino a 4 Gbps e una capacità massima di 192 TiB. Tuttavia, è possibile dimensionare il cluster in termini di IOPS con provisioning, throughput e limite di storage (minimo 1,024 GiB) in base ai requisiti effettivi al momento dell'implementazione. La capacità può essere regolata dinamicamente in tempo reale senza influire sulla disponibilità delle applicazioni.
Implementazione della soluzione
Si presuppone che il tuo database Oracle primario sia già implementato nell'ambiente AWS EC2 all'interno di un VPC come punto di partenza per la configurazione di Data Guard. Il database primario viene implementato utilizzando Oracle ASM per la gestione dello storage. Vengono creati due gruppi di dischi ASM: +DATA e +LOG per i file di dati Oracle, i file di registro, i file di controllo e così via Per informazioni sull'implementazione di Oracle in AWS con ASM, consultare i seguenti report tecnici per ottenere aiuto.
Il tuo database Oracle primario può essere eseguito su un FSX ONTAP o su qualsiasi altro storage scelto all'interno dell'ecosistema AWS EC2. Nella sezione seguente vengono fornite le procedure di distribuzione dettagliate per l'impostazione di Oracle Data Guard tra un'istanza primaria di database da EC2 GB con spazio di archiviazione ASM e un'istanza di standby di database da EC2 GB con spazio di archiviazione ASM.
Prerequisiti per l'implementazione
Details
L'implementazione richiede i seguenti prerequisiti.
-
È stato impostato un account AWS e sono stati creati i segmenti VPC e di rete necessari all'interno dell'account AWS.
-
Dalla console AWS EC2 è necessario implementare almeno tre istanze Linux EC2 GB, una come istanza primaria di Oracle DB, una come istanza standby di Oracle DB e un'istanza clone di database di destinazione per reporting, sviluppo e test, ecc. Fare riferimento al diagramma dell'architettura nella sezione precedente per ulteriori informazioni sulla configurazione dell'ambiente. Consulta anche l'AWS "Guida utente per istanze Linux" per ulteriori informazioni.
-
Dalla console AWS EC2, implementa i cluster ad alta disponibilità di storage Amazon FSX per ONTAP per ospitare volumi Oracle che archiviano il database di standby Oracle. Se non si ha familiarità con l'implementazione dello storage FSX, consultare la documentazione "Creazione di FSX per file system ONTAP" per istruzioni dettagliate.
-
I passaggi 2 e 3 possono essere eseguiti utilizzando il seguente toolkit di automazione Terraform, che crea un'istanza EC2 denominata
ora_01E un file system FSX denominatofsx_01. Prima dell'esecuzione, rivedere attentamente le istruzioni e modificare le variabili in base all'ambiente in uso. Il modello può essere facilmente rivisto in base ai tuoi requisiti di implementazione.git clone https://github.com/NetApp-Automation/na_aws_fsx_ec2_deploy.git
|
Assicurarsi di aver allocato almeno 50 G nel volume root dell'istanza EC2 per avere spazio sufficiente per la fase dei file di installazione Oracle. |
Preparare il database primario per Data Guard
Details
In questa dimostrazione, abbiamo configurato un database Oracle primario denominato DB1 sull'istanza DB primaria EC2 con due gruppi di dischi ASM in configurazione riavvio standalone con file di dati nel gruppo di dischi ASM +area di DATI e di ripristino flash nel gruppo di dischi ASM +LOGS. Di seguito vengono illustrate le procedure dettagliate per l'impostazione del database primario per Data Guard. Tutti i passaggi devono essere eseguiti come proprietario del database - utente oracle.
-
Configurazione del database primario DB1 sull'istanza primaria EC2 DB ip-172-30-15-45. I gruppi di dischi ASM possono trovarsi su qualsiasi tipo di storage all'interno dell'ecosistema EC2.
[oracle@ip-172-30-15-45 ~]$ cat /etc/oratab # This file is used by ORACLE utilities. It is created by root.sh # and updated by either Database Configuration Assistant while creating # a database or ASM Configuration Assistant while creating ASM instance. # A colon, ':', is used as the field terminator. A new line terminates # the entry. Lines beginning with a pound sign, '#', are comments. # # Entries are of the form: # $ORACLE_SID:$ORACLE_HOME:<N|Y>: # # The first and second fields are the system identifier and home # directory of the database respectively. The third field indicates # to the dbstart utility that the database should , "Y", or should not, # "N", be brought up at system boot time. # # Multiple entries with the same $ORACLE_SID are not allowed. # # +ASM:/u01/app/oracle/product/19.0.0/grid:N db1:/u01/app/oracle/product/19.0.0/db1:N [oracle@ip-172-30-15-45 ~]$ /u01/app/oracle/product/19.0.0/grid/bin/crsctl stat res -t -------------------------------------------------------------------------------- Name Target State Server State details -------------------------------------------------------------------------------- Local Resources -------------------------------------------------------------------------------- ora.DATA.dg ONLINE ONLINE ip-172-30-15-45 STABLE ora.LISTENER.lsnr ONLINE ONLINE ip-172-30-15-45 STABLE ora.LOGS.dg ONLINE ONLINE ip-172-30-15-45 STABLE ora.asm ONLINE ONLINE ip-172-30-15-45 Started,STABLE ora.ons OFFLINE OFFLINE ip-172-30-15-45 STABLE -------------------------------------------------------------------------------- Cluster Resources -------------------------------------------------------------------------------- ora.cssd 1 ONLINE ONLINE ip-172-30-15-45 STABLE ora.db1.db 1 ONLINE ONLINE ip-172-30-15-45 Open,HOME=/u01/app/o racle/product/19.0.0 /db1,STABLE ora.diskmon 1 OFFLINE OFFLINE STABLE ora.driver.afd 1 ONLINE ONLINE ip-172-30-15-45 STABLE ora.evmd 1 ONLINE ONLINE ip-172-30-15-45 STABLE -------------------------------------------------------------------------------- -
Da sqlplus, abilitare la registrazione forzata su primario.
alter database force logging; -
Da sqlplus, attivare flashback su primario. Flashback consente di ripristinare facilmente il database primario come standby dopo un failover.
alter database flashback on; -
Configurare l'autenticazione del trasporto di ripristino utilizzando il file password Oracle - creare un file pwd sul primario utilizzando l'utilità orapwd se non è impostata e copiarlo nella directory $ORACLE_HOME/dbs del database di standby.
-
Creare log di ripristino in standby sul database primario con le stesse dimensioni del file di log online corrente. I gruppi di log sono più di un gruppo di file di log online. Il database primario può quindi passare rapidamente al ruolo di standby e iniziare a ricevere i dati di redo, se necessario.
alter database add standby logfile thread 1 size 200M;Validate after standby logs addition: SQL> select group#, type, member from v$logfile; GROUP# TYPE MEMBER ---------- ------- ------------------------------------------------------------ 3 ONLINE +DATA/DB1/ONLINELOG/group_3.264.1145821513 2 ONLINE +DATA/DB1/ONLINELOG/group_2.263.1145821513 1 ONLINE +DATA/DB1/ONLINELOG/group_1.262.1145821513 4 STANDBY +DATA/DB1/ONLINELOG/group_4.286.1146082751 4 STANDBY +LOGS/DB1/ONLINELOG/group_4.258.1146082753 5 STANDBY +DATA/DB1/ONLINELOG/group_5.287.1146082819 5 STANDBY +LOGS/DB1/ONLINELOG/group_5.260.1146082821 6 STANDBY +DATA/DB1/ONLINELOG/group_6.288.1146082825 6 STANDBY +LOGS/DB1/ONLINELOG/group_6.261.1146082827 7 STANDBY +DATA/DB1/ONLINELOG/group_7.289.1146082835 7 STANDBY +LOGS/DB1/ONLINELOG/group_7.262.1146082835 11 rows selected. -
Da sqlplus, creare un pfile da spfile per la modifica.
create pfile='/home/oracle/initdb1.ora' from spfile; -
Rivedere il file pfile e aggiungere i seguenti parametri.
DB_NAME=db1 DB_UNIQUE_NAME=db1_NY LOG_ARCHIVE_CONFIG='DG_CONFIG=(db1_NY,db1_LA)' LOG_ARCHIVE_DEST_1='LOCATION=USE_DB_RECOVERY_FILE_DEST VALID_FOR=(ALL_LOGFILES,ALL_ROLES) DB_UNIQUE_NAME=db1_NY' LOG_ARCHIVE_DEST_2='SERVICE=db1_LA ASYNC VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE) DB_UNIQUE_NAME=db1_LA' REMOTE_LOGIN_PASSWORDFILE=EXCLUSIVE FAL_SERVER=db1_LA STANDBY_FILE_MANAGEMENT=AUTO
-
Da sqlplus, creare spfile nella directory ASM +DATA da pfile rivisto nella directory /home/oracle.
create spfile='+DATA' from pfile='/home/oracle/initdb1.ora'; -
Individuare il nuovo spfile creato in +DATA disk group (utilizzando l'utilità asmcmd se necessario). Utilizzare srvctl per modificare la griglia per avviare il database dal nuovo spfile come illustrato di seguito.
[oracle@ip-172-30-15-45 db1]$ srvctl config database -d db1 Database unique name: db1 Database name: db1 Oracle home: /u01/app/oracle/product/19.0.0/db1 Oracle user: oracle Spfile: +DATA/DB1/PARAMETERFILE/spfile.270.1145822903 Password file: Domain: demo.netapp.com Start options: open Stop options: immediate Database role: PRIMARY Management policy: AUTOMATIC Disk Groups: DATA Services: OSDBA group: OSOPER group: Database instance: db1 [oracle@ip-172-30-15-45 db1]$ srvctl modify database -d db1 -spfile +DATA/DB1/PARAMETERFILE/spfiledb1.ora [oracle@ip-172-30-15-45 db1]$ srvctl config database -d db1 Database unique name: db1 Database name: db1 Oracle home: /u01/app/oracle/product/19.0.0/db1 Oracle user: oracle Spfile: +DATA/DB1/PARAMETERFILE/spfiledb1.ora Password file: Domain: demo.netapp.com Start options: open Stop options: immediate Database role: PRIMARY Management policy: AUTOMATIC Disk Groups: DATA Services: OSDBA group: OSOPER group: Database instance: db1
-
Modificare tnsnames.ora per aggiungere db_unique_name per la risoluzione del nome.
# tnsnames.ora Network Configuration File: /u01/app/oracle/product/19.0.0/db1/network/admin/tnsnames.ora # Generated by Oracle configuration tools. db1_NY = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = ip-172-30-15-45.ec2.internal)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SID = db1) ) ) db1_LA = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = ip-172-30-15-67.ec2.internal)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SID = db1) ) ) LISTENER_DB1 = (ADDRESS = (PROTOCOL = TCP)(HOST = ip-172-30-15-45.ec2.internal)(PORT = 1521)) -
Aggiungere il nome del servizio protezione dati db1_NY_DGMGRL.demo.netapp per il database primario al file listener.ora.
#Backup file is /u01/app/oracle/crsdata/ip-172-30-15-45/output/listener.ora.bak.ip-172-30-15-45.oracle line added by Agent
# listener.ora Network Configuration File: /u01/app/oracle/product/19.0.0/grid/network/admin/listener.ora
# Generated by Oracle configuration tools.
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = ip-172-30-15-45.ec2.internal)(PORT = 1521))
(ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))
)
)
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = db1_NY_DGMGRL.demo.netapp.com)
(ORACLE_HOME = /u01/app/oracle/product/19.0.0/db1)
(SID_NAME = db1)
)
)
ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER=ON # line added by Agent
VALID_NODE_CHECKING_REGISTRATION_LISTENER=ON # line added by Agent
-
Chiudere e riavviare il database con srvctl e convalidare che i parametri di protezione dati siano ora attivi.
srvctl stop database -d db1srvctl start database -d db1
L'impostazione del database primario per Data Guard viene completata.
Preparare il database di standby e attivare Data Guard
Details
Oracle Data Guard richiede la configurazione del kernel del sistema operativo e gli stack di software Oracle, inclusi i set di patch sull'istanza EC2 DB di standby, in modo che corrispondano all'istanza primaria EC2 DB. Per semplificare la gestione e la semplicità, la configurazione dello storage del database di istanza EC2 DB di standby dovrebbe corrispondere idealmente anche all'istanza primaria EC2 DB, come il nome, il numero e la dimensione dei gruppi di dischi ASM. Di seguito sono riportate le procedure dettagliate per impostare l'istanza di standby EC2 DB per Data Guard. Tutti i comandi devono essere eseguiti come ID utente proprietario di oracle.
-
Innanzitutto, esaminare la configurazione del database primario sull'istanza EC2 primaria. In questa dimostrazione, abbiamo configurato un database Oracle primario chiamato DB1 sull'istanza DB primaria EC2 con due gruppi di dischi ASM +DATA e +LOGS nella configurazione di riavvio standalone. I gruppi di dischi ASM primari possono trovarsi su qualsiasi tipo di storage all'interno dell'ecosistema EC2.
-
Seguire le procedure riportate nella documentazione "TR-4965: Implementazione e protezione del database Oracle in AWS FSX/EC2 con iSCSI/ASM" Per installare e configurare Grid e Oracle sull'istanza EC2 DB di standby in modo che corrispondano al database primario. È necessario eseguire il provisioning e allocare lo storage del database all'istanza EC2 DB in standby da FSX ONTAP con la stessa capacità di storage dell'istanza EC2 DB primaria.
Fermarsi al passo 10 in Oracle database installationsezione. Il database di standby verrà creato un'istanza dal database primario utilizzando la funzione di duplicazione del database dbca. -
Una volta installato e configurato il software Oracle, copiare la password oracle dal database principale dalla directory $ORACLE_HOME dbs.
scp oracle@172.30.15.45:/u01/app/oracle/product/19.0.0/db1/dbs/orapwdb1 . -
Creare il file tnsnames.ora con le seguenti voci.
# tnsnames.ora Network Configuration File: /u01/app/oracle/product/19.0.0/db1/network/admin/tnsnames.ora # Generated by Oracle configuration tools. db1_NY = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = ip-172-30-15-45.ec2.internal)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SID = db1) ) ) db1_LA = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = ip-172-30-15-67.ec2.internal)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SID = db1) ) ) -
Aggiungere il nome del servizio protezione dati DB al file listener.ora.
#Backup file is /u01/app/oracle/crsdata/ip-172-30-15-67/output/listener.ora.bak.ip-172-30-15-67.oracle line added by Agent # listener.ora Network Configuration File: /u01/app/oracle/product/19.0.0/grid/network/admin/listener.ora # Generated by Oracle configuration tools. LISTENER = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = ip-172-30-15-67.ec2.internal)(PORT = 1521)) (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521)) ) ) SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = db1_LA_DGMGRL.demo.netapp.com) (ORACLE_HOME = /u01/app/oracle/product/19.0.0/db1) (SID_NAME = db1) ) ) ENABLE_GLOBAL_DYNAMIC_ENDPOINT_LISTENER=ON # line added by Agent VALID_NODE_CHECKING_REGISTRATION_LISTENER=ON # line added by Agent -
Imposta home e path oracle.
export ORACLE_HOME=/u01/app/oracle/product/19.0.0/db1export PATH=$PATH:$ORACLE_HOME/bin -
Utilizzare dbca per creare un'istanza del database di standby dal database primario DB1.
[oracle@ip-172-30-15-67 bin]$ dbca -silent -createDuplicateDB -gdbName db1 -primaryDBConnectionString ip-172-30-15-45.ec2.internal:1521/db1_NY.demo.netapp.com -sid db1 -initParams fal_server=db1_NY -createAsStandby -dbUniqueName db1_LA Enter SYS user password: Prepare for db operation 22% complete Listener config step 44% complete Auxiliary instance creation 67% complete RMAN duplicate 89% complete Post duplicate database operations 100% complete Look at the log file "/u01/app/oracle/cfgtoollogs/dbca/db1_LA/db1_LA.log" for further details.
-
Convalidare il database di standby duplicato. Il nuovo database di standby duplicato si apre inizialmente in modalità di SOLA LETTURA.
[oracle@ip-172-30-15-67 bin]$ export ORACLE_SID=db1 [oracle@ip-172-30-15-67 bin]$ sqlplus / as sysdba SQL*Plus: Release 19.0.0.0.0 - Production on Wed Aug 30 18:25:46 2023 Version 19.18.0.0.0 Copyright (c) 1982, 2022, Oracle. All rights reserved. Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.18.0.0.0 SQL> select name, open_mode from v$database; NAME OPEN_MODE --------- -------------------- DB1 READ ONLY SQL> show parameter name NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ cdb_cluster_name string cell_offloadgroup_name string db_file_name_convert string db_name string db1 db_unique_name string db1_LA global_names boolean FALSE instance_name string db1 lock_name_space string log_file_name_convert string pdb_file_name_convert string processor_group_name string NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ service_names string db1_LA.demo.netapp.com SQL> SQL> show parameter log_archive_config NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ log_archive_config string DG_CONFIG=(db1_NY,db1_LA) SQL> show parameter fal_server NAME TYPE VALUE ------------------------------------ ----------- ------------------------------ fal_server string db1_NY SQL> select name from v$datafile; NAME -------------------------------------------------------------------------------- +DATA/DB1_LA/DATAFILE/system.261.1146248215 +DATA/DB1_LA/DATAFILE/sysaux.262.1146248231 +DATA/DB1_LA/DATAFILE/undotbs1.263.1146248247 +DATA/DB1_LA/03C5C01A66EE9797E0632D0F1EAC5F59/DATAFILE/system.264.1146248253 +DATA/DB1_LA/03C5C01A66EE9797E0632D0F1EAC5F59/DATAFILE/sysaux.265.1146248261 +DATA/DB1_LA/DATAFILE/users.266.1146248267 +DATA/DB1_LA/03C5C01A66EE9797E0632D0F1EAC5F59/DATAFILE/undotbs1.267.1146248269 +DATA/DB1_LA/03C5EFD07C41A1FAE0632D0F1EAC9BD8/DATAFILE/system.268.1146248271 +DATA/DB1_LA/03C5EFD07C41A1FAE0632D0F1EAC9BD8/DATAFILE/sysaux.269.1146248279 +DATA/DB1_LA/03C5EFD07C41A1FAE0632D0F1EAC9BD8/DATAFILE/undotbs1.270.1146248285 +DATA/DB1_LA/03C5EFD07C41A1FAE0632D0F1EAC9BD8/DATAFILE/users.271.1146248293 NAME -------------------------------------------------------------------------------- +DATA/DB1_LA/03C5F0DDF35CA2B6E0632D0F1EAC8B6B/DATAFILE/system.272.1146248295 +DATA/DB1_LA/03C5F0DDF35CA2B6E0632D0F1EAC8B6B/DATAFILE/sysaux.273.1146248301 +DATA/DB1_LA/03C5F0DDF35CA2B6E0632D0F1EAC8B6B/DATAFILE/undotbs1.274.1146248309 +DATA/DB1_LA/03C5F0DDF35CA2B6E0632D0F1EAC8B6B/DATAFILE/users.275.1146248315 +DATA/DB1_LA/03C5F1C9B142A2F1E0632D0F1EACF21A/DATAFILE/system.276.1146248317 +DATA/DB1_LA/03C5F1C9B142A2F1E0632D0F1EACF21A/DATAFILE/sysaux.277.1146248323 +DATA/DB1_LA/03C5F1C9B142A2F1E0632D0F1EACF21A/DATAFILE/undotbs1.278.1146248331 +DATA/DB1_LA/03C5F1C9B142A2F1E0632D0F1EACF21A/DATAFILE/users.279.1146248337 19 rows selected. SQL> select name from v$controlfile; NAME -------------------------------------------------------------------------------- +DATA/DB1_LA/CONTROLFILE/current.260.1146248209 +LOGS/DB1_LA/CONTROLFILE/current.257.1146248209 SQL> select name from v$tempfile; NAME -------------------------------------------------------------------------------- +DATA/DB1_LA/TEMPFILE/temp.287.1146248371 +DATA/DB1_LA/03C5C01A66EE9797E0632D0F1EAC5F59/TEMPFILE/temp.288.1146248375 +DATA/DB1_LA/03C5EFD07C41A1FAE0632D0F1EAC9BD8/TEMPFILE/temp.290.1146248463 +DATA/DB1_LA/03C5F0DDF35CA2B6E0632D0F1EAC8B6B/TEMPFILE/temp.291.1146248463 +DATA/DB1_LA/03C5F1C9B142A2F1E0632D0F1EACF21A/TEMPFILE/temp.292.1146248463 SQL> select group#, type, member from v$logfile order by 2, 1; GROUP# TYPE MEMBER ---------- ------- ------------------------------------------------------------ 1 ONLINE +LOGS/DB1_LA/ONLINELOG/group_1.259.1146248349 1 ONLINE +DATA/DB1_LA/ONLINELOG/group_1.280.1146248347 2 ONLINE +DATA/DB1_LA/ONLINELOG/group_2.281.1146248351 2 ONLINE +LOGS/DB1_LA/ONLINELOG/group_2.258.1146248353 3 ONLINE +DATA/DB1_LA/ONLINELOG/group_3.282.1146248355 3 ONLINE +LOGS/DB1_LA/ONLINELOG/group_3.260.1146248355 4 STANDBY +DATA/DB1_LA/ONLINELOG/group_4.283.1146248357 4 STANDBY +LOGS/DB1_LA/ONLINELOG/group_4.261.1146248359 5 STANDBY +DATA/DB1_LA/ONLINELOG/group_5.284.1146248361 5 STANDBY +LOGS/DB1_LA/ONLINELOG/group_5.262.1146248363 6 STANDBY +LOGS/DB1_LA/ONLINELOG/group_6.263.1146248365 6 STANDBY +DATA/DB1_LA/ONLINELOG/group_6.285.1146248365 7 STANDBY +LOGS/DB1_LA/ONLINELOG/group_7.264.1146248369 7 STANDBY +DATA/DB1_LA/ONLINELOG/group_7.286.1146248367 14 rows selected. SQL> select name, open_mode from v$database; NAME OPEN_MODE --------- -------------------- DB1 READ ONLY -
Riavviare il database di standby in
mountpreparare ed eseguire il seguente comando per attivare il ripristino gestito dal database di standby.alter database recover managed standby database disconnect from session;SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount; ORACLE instance started. Total System Global Area 8053062944 bytes Fixed Size 9182496 bytes Variable Size 1291845632 bytes Database Buffers 6744440832 bytes Redo Buffers 7593984 bytes Database mounted. SQL> alter database recover managed standby database disconnect from session; Database altered.
-
Convalidare lo stato di ripristino del database di standby. Notare la
recovery logmergerpollAPPLYING_LOGazione.SQL> SELECT ROLE, THREAD#, SEQUENCE#, ACTION FROM V$DATAGUARD_PROCESS; ROLE THREAD# SEQUENCE# ACTION ------------------------ ---------- ---------- ------------ recovery apply slave 0 0 IDLE recovery apply slave 0 0 IDLE recovery apply slave 0 0 IDLE recovery apply slave 0 0 IDLE recovery logmerger 1 30 APPLYING_LOG RFS ping 1 30 IDLE RFS async 1 30 IDLE archive redo 0 0 IDLE archive redo 0 0 IDLE archive redo 0 0 IDLE gap manager 0 0 IDLE ROLE THREAD# SEQUENCE# ACTION ------------------------ ---------- ---------- ------------ managed recovery 0 0 IDLE redo transport monitor 0 0 IDLE log writer 0 0 IDLE archive local 0 0 IDLE redo transport timer 0 0 IDLE 16 rows selected. SQL>
In questo modo viene completata l'impostazione della protezione Data Guard per DB1 da primario a standby con ripristino in standby gestito abilitato.
Impostare Data Guard Broker
Details
Oracle Data Guard broker è un framework di gestione distribuito che automatizza e centralizza la creazione, la manutenzione e il monitoraggio delle configurazioni di Oracle Data Guard. Nella sezione seguente viene illustrato come configurare Data Guard Broker per la gestione dell'ambiente Data Guard.
-
Avviare il broker di protezione dei dati su entrambi i database primari e di standby con il seguente comando tramite sqlplus.
alter system set dg_broker_start=true scope=both; -
Dal database primario, connettersi a Data Guard Borker come SYSDBA.
[oracle@ip-172-30-15-45 db1]$ dgmgrl sys@db1_NY DGMGRL for Linux: Release 19.0.0.0.0 - Production on Wed Aug 30 19:34:14 2023 Version 19.18.0.0.0 Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved. Welcome to DGMGRL, type "help" for information. Password: Connected to "db1_NY" Connected as SYSDBA.
-
Creare e abilitare la configurazione di Data Guard Broker.
DGMGRL> create configuration dg_config as primary database is db1_NY connect identifier is db1_NY; Configuration "dg_config" created with primary database "db1_ny" DGMGRL> add database db1_LA as connect identifier is db1_LA; Database "db1_la" added DGMGRL> enable configuration; Enabled. DGMGRL> show configuration; Configuration - dg_config Protection Mode: MaxPerformance Members: db1_ny - Primary database db1_la - Physical standby database Fast-Start Failover: Disabled Configuration Status: SUCCESS (status updated 28 seconds ago) -
Convalidare lo stato del database nel framework di gestione di Data Guard Broker.
DGMGRL> show database db1_ny; Database - db1_ny Role: PRIMARY Intended State: TRANSPORT-ON Instance(s): db1 Database Status: SUCCESS DGMGRL> show database db1_la; Database - db1_la Role: PHYSICAL STANDBY Intended State: APPLY-ON Transport Lag: 0 seconds (computed 1 second ago) Apply Lag: 0 seconds (computed 1 second ago) Average Apply Rate: 2.00 KByte/s Real Time Query: OFF Instance(s): db1 Database Status: SUCCESS DGMGRL>
In caso di guasto, Data Guard Broker può essere utilizzato per eseguire il failover del database primario in standby istantaneamente.
Clonare il database di standby per altri casi di utilizzo
Details
Il principale vantaggio dello staging del database di standby su AWS FSX ONTAP in Data Guard è la possibilità di creare con FlexClone il supporto di molti altri casi di utilizzo con un investimento minimo nello storage aggiuntivo. Nella sezione seguente, mostreremo come creare snapshot e clonare i volumi di database di standby montati e in fase di ripristino in FSX ONTAP per altri scopi, come SVILUPPO, TEST, REPORT, ecc. utilizzo dello strumento NetApp SnapCenter.
Di seguito sono riportate le procedure di alto livello per clonare un database di LETTURA/SCRITTURA dal database di standby fisico gestito in Data Guard utilizzando SnapCenter. Per istruzioni dettagliate su come impostare e configurare SnapCenter, fare riferimento a. "Soluzioni di database per il cloud ibrido con SnapCenter" Sezioni Oracle relavant.
-
Si inizia con la creazione di una tabella di test e l'inserimento di una riga nella tabella di test sul database primario. Quindi, convalideremo se la transazione passa in standby e infine al clone.
[oracle@ip-172-30-15-45 db1]$ sqlplus / as sysdba SQL*Plus: Release 19.0.0.0.0 - Production on Thu Aug 31 16:35:53 2023 Version 19.18.0.0.0 Copyright (c) 1982, 2022, Oracle. All rights reserved. Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.18.0.0.0 SQL> alter session set container=db1_pdb1; Session altered. SQL> create table test( 2 id integer, 3 dt timestamp, 4 event varchar(100)); Table created. SQL> insert into test values(1, sysdate, 'a test transaction on primary database db1 and ec2 db host: ip-172-30-15-45.ec2.internal'); 1 row created. SQL> commit; Commit complete. SQL> select * from test; ID ---------- DT --------------------------------------------------------------------------- EVENT -------------------------------------------------------------------------------- 1 31-AUG-23 04.49.29.000000 PM a test transaction on primary database db1 and ec2 db host: ip-172-30-15-45.ec2. internal SQL> select instance_name, host_name from v$instance; INSTANCE_NAME ---------------- HOST_NAME ---------------------------------------------------------------- db1 ip-172-30-15-45.ec2.internal -
Aggiungi cluster di storage FSX a.
Storage SystemsIn SnapCenter con IP di gestione cluster FSX e credenziale fsxadmin.
-
Aggiungi AWS EC2 utente a.
CredentialpollSettings.
-
Aggiungere l'istanza di standby EC2 DB e clonare l'istanza EC2 DB a.
Hosts.
L'istanza EC2 DB clone deve avere stack software Oracle simili installati e configurati. Nel nostro test, l'infrastruttura di rete e Oracle 19C sono stati installati e configurati, ma non è stato creato alcun database. -
Creare un criterio di backup personalizzato per il backup completo del database non in linea/montato.
-
Applicare i criteri di backup per proteggere il database di standby in
Resourcesscheda.
-
Fare clic sul nome del database per aprire la pagina di backup del database. Selezionare un backup da utilizzare per il clone del database e fare clic su
Cloneper avviare il flusso di lavoro di clonazione.
-
Selezionare
Complete Database CloneE denominare il SID dell'istanza clone.
-
Selezionare l'host clone che ospita il database clonato dal database di standby. Accettare il valore predefinito per i file di dati, i file di controllo e i registri di ripristino. Sull'host clone verranno creati due gruppi di dischi ASM corrispondenti ai gruppi di dischi del database di standby.
-
Non sono necessarie credenziali di database per l'autenticazione basata sul sistema operativo. Associare l'impostazione home Oracle a quanto configurato nell'istanza del database EC2 clone.
-
Se necessario, modificare i parametri del database clone e specificare gli script da eseguire prima di cloen, se necessario.
-
Immettere SQL da eseguire dopo la clonazione. Nella demo, abbiamo eseguito comandi per disattivare la modalità di archiviazione del database per un database dev/test/report.
-
Configurare la notifica e-mail, se lo si desidera.
-
Rivedere il riepilogo, fare clic su
Finishper avviare il clone.
-
Monitorare il processo clone in
Monitorscheda. Abbiamo osservato che erano necessari circa 8 minuti per clonare un database di circa 300GB TB nelle dimensioni del volume del database.
-
Convalidare il database clone da SnapCenter, che viene registrato immediatamente in
Resourcessubito dopo l'operazione di clonazione.
-
Eseguire una query nel database clone dall'istanza clone EC2. Abbiamo validato la transazione di test verificatasi nel database primario in modo da ottenere la clonazione del database.
[oracle@ip-172-30-15-126 ~]$ export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dev [oracle@ip-172-30-15-126 ~]$ export ORACLE_SID=db1dev [oracle@ip-172-30-15-126 ~]$ export PATH=$PATH:$ORACLE_HOME/bin [oracle@ip-172-30-15-126 ~]$ sqlplus / as sysdba SQL*Plus: Release 19.0.0.0.0 - Production on Wed Sep 6 16:41:41 2023 Version 19.18.0.0.0 Copyright (c) 1982, 2022, Oracle. All rights reserved. Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.18.0.0.0 SQL> select name, open_mode, log_mode from v$database; NAME OPEN_MODE LOG_MODE --------- -------------------- ------------ DB1DEV READ WRITE NOARCHIVELOG SQL> select instance_name, host_name from v$instance; INSTANCE_NAME ---------------- HOST_NAME ---------------------------------------------------------------- db1dev ip-172-30-15-126.ec2.internal SQL> alter session set container=db1_pdb1; Session altered. SQL> select * from test; ID ---------- DT --------------------------------------------------------------------------- EVENT -------------------------------------------------------------------------------- 1 31-AUG-23 04.49.29.000000 PM a test transaction on primary database db1 and ec2 db host: ip-172-30-15-45.ec2. internal SQL>
Ciò completa il clone e la convalida di un nuovo database Oracle dal database di standby in Data Guard sullo storage FSX per LO SVILUPPO, IL TEST, IL REPORT o qualsiasi altro caso di utilizzo. È possibile clonare più database Oracle dallo stesso database di standby in Data Guard.
Dove trovare ulteriori informazioni
Per ulteriori informazioni sulle informazioni descritte in questo documento, consultare i seguenti documenti e/o siti Web:
-
Concetti e amministrazione di Data Guard
-
WP-7357: Implementazione dei database Oracle su EC2 e Best practice di FSX
-
Amazon FSX per NetApp ONTAP
-
Amazon EC2