دیتابیس اوراکل

دیتابیس اوراکل
طبقه بندی موضوعی

۴ مطلب با کلمه‌ی کلیدی «Data Guard» ثبت شده است

PDB Replication in Data Guard

برای کنترل کردن اینکه یک pdb در دیتابیس استندبای سینک شود یا نه، 2 روش وجود دارد:

1- استفاده از عبارت STANDBYS در دستور CREATE PLUGGABLE DATABASE که از ورژن 12.1.0.2 اضافه شده است.

CREATE PLUGGABLE DATABASE PDBTEST

ADMIN USER pdbadmin IDENTIFIED BY Password1

STANDBYS=NONE ;

 

مقادیری که میتوان برای STANDBYS ست کرد به صورت زیر است:

  • STANDBYS=NONE: این pdb با هیچ کدام از استندبای ها سینک نشود.
  • STANDBYS=ALL: این pdb با همه استندبای های سینک شود.
  • STANDBYS=ALL EXCEPT ('cdb1_stby_1','cdb1_stby_2'): این pdb با همه استندبای ها سینک شود بجز استندبای هایی که DB_UNIQUE_NAME آنها cdb1_stby_1 و cdb1_stby_2 است.
  • STANDBYS=('cdb1_stby_1'): این pdb فقط با استندبای cdb1_stby_1 سینک شود.

 

2- استفاده از پارامتر ENABLED_PDBS_ON_STANDBY که از ورژن 12.2 اضافه شده است.

اگر میخواهید یک pdb توسط استندبای سینک نشود، باید قبل از ایجاد pdb ، این پارامتر را به صورت زیر در دیتابیس اصلی یا استندبای ست کنید، ولی این را مد نظر داشته باشید که این پارامتر فقط توسط استندبای استفاده میشود:

ALTER SYSTEM SET enabled_pdbs_on_standby="*", "-PDBTEST";

 

مقادیری که میتوان به پارامتر enabled_pdbs_on_standby پاس داد به صورت زیر است:

  • "*": همه pdbها با استندبای سینک شوند.
  • ""PDB1", "PDB2: فقط PDB1 و PDB2 با استندبای سینک شوند.
  • ""PDB*: فقط pdbهایی که با کلمه "PDB" شروع میشوند با استندبای سینک شوند.
  • ""*", "-PDB*: همه pdbها بجز pdbهایی که با کلمه "PDB" شروع میشوند با استندبای سینک شوند.
  • ""*", "-PDB1: همه pdbها بجز PDB1 با استندبای سینک شوند.

 

بعد از ست کردن این پارامتر به صورت بالا، pdb زیر را ایجاد میکنیم:

CREATE PLUGGABLE DATABASE PDBTEST

ADMIN USER pdbadmin IDENTIFIED BY Password1;

 

در دیتابیس primary:

SQL> SELECT name, open_mode, recovery_status

FROM v$pdbs

WHERE name='PDBTEST';

 

NAME           OPEN_MODE   RECOVERY_STATUS

---------------- ----------------- --------------------------

PDBTEST       READ WRITE   ENABLED

 

در دیتابیس standby:

SQL> SELECT name, open_mode, recovery_status

FROM v$pdbs

WHERE name='PDBTEST';

 

NAME           OPEN_MODE   RECOVERY_STATUS

---------------- ----------------- --------------------------

PDBTEST       READ WRITE   DISABLED

 

 

Document:

https://oracle-base.com/articles/12c/multitenant-controlling-pdb-replication-in-data-guard-environments-12c

 

Data Guard Physical Standby Switchover using SQLPlus

  1. Verify Managed Recovery is running on the standby:

On Standby:

SQL> select process from v$managed_standby where process like 'MRP%';

PROCESS

-------------

MRP0

 

On Primary:

SQL> select recovery_mode from v$archive_dest_status where dest_id=2;

RECOVERY_MODE

-------------------------------------

MANAGED REAL TIME APPLY

 

  1. Verify there are no Gaps:

On Primary: 
select a.db_unique_name , a.dest_name ,a.archived_seq# ,  a.applied_seq#, a.gap_status 
  from v$archive_dest_status a
 where a.db_unique_name in ('stby_dbunique');

 

select thread#, max(sequence#) "Last Primary Seq Generated"
from gv$archived_log val, gv$database vdb
where val.resetlogs_change# = vdb.resetlogs_change#
group by thread# order by 1;

 

On Standby:
select thread#, max(sequence#) "Last Standby Seq Applied"
from gv$archived_log val, gv$database vdb
where val.resetlogs_change# = vdb.resetlogs_change#
and val.applied in ('YES')
group by thread# order by 1;

 

select thread#, low_sequence#, high_sequence# from v$archive_gap;

 

  1. Verify all datafiles are online On Target Standby:

SQL> select name from v$datafile where status='OFFLINE';

If there are any OFFLINE datafiles, and these are needed after switchover, bring them ONLINE:

SQL> alter database datafile '<DATAFILE_NAME>' online;

 

  1. Verify Primary and Standby tempfiles match:

select tmp.name filename, bytes, ts.name tablespace
  from v$tempfile tmp, v$tablespace ts
 where tmp.ts#=ts.ts#;

If the queries do not match, then you can correct the mismatch now or immediately after the open of the new primary database;

 

  1. Stop Jobs in Primary

SQL> select * from dba_jobs_running;

Depending on what the running job is, be ready to terminate the job if necessary.

 

Block further job submission by setting the job_queue_processes parameter to 0 so that there would be no jobs running during switchover.

SQL> show parameter job_queue_processes

SQL> alter system set job_queue_processes=0 scope=spfile;

 

  1. Create Guaranteed Restore Points

On Standby:

SQL> alter database recover managed standby database cancel;

SQL> create restore point SWITCHOVER_START_GRP guarantee flashback database;

SQL> alter database recover managed standby database using current logfile nodelay disconnect from session;

 

On Primary: 

SQL> create restore point SWITCHOVER_START_GRP guarantee flashback database;

 

  1. Verify that the primary database can be switched to the standby role.

SQL> select switchover_status from v$database;

SWITCHOVER_STATUS

-----------------------------

SESSIONS ACTIVE

A value of TO STANDBY or SESSIONS ACTIVE (which requires the WITH SESSION SHUTDOWN clause on the switchover command) indicates that the primary database can be switched to the standby role.

 

Switchover always originates from Primary database. On the request of switchover sql statement "alter database commit to switchover to physical standby with session shutdown", Primary will generate special marker called EOR (end-of-redo) that is placed in the header of online redo log sequence. So this online redo log sequence will be archived locally and sent to all standby databases. Only upon receiving and applying EOR (end-of-redo), v$database.switchover_status will change from "not allowed" to "to primary" or "sessions active". At this stage Physical standby is ready to assume Primary database role.

  1. If The Primary is a RAC, then shutdown all secondary primary instances
  2. Switchover the Primary to a standby database

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY WITH SESSION SHUTDOWN;

 

  1. Verify that the standby database can be switched to the primary role.

SQL> select switchover_status from v$database;

SWITCHOVER_STATUS

----------------------------

TO PRIMARY

A value of TO PRIMARY or SESSIONS ACTIVE indicates that the standby database is ready to be switched to the primary role.

 

  1. Switchover the Standby to a primary

SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;

SQL> ALTER DATABASE OPEN;

 

  1. Restart the new standby

SQL> shutdown immediate;

SQL> startup mount;

SQL> alter database recover managed standby database using current logfile disconnect;

SQL> alter database open;

If the database is a RAC, then start all secondary instances on the new standby.

 

  1. Check Primary and New Standby:

SQL> select db_unique_name,total_gap,open_mode,database_role from v$database;

 

  1. Drop any Switchover Guaranteed Restore Points on all databases.

DGMGRL> drop restore point SWITCHOVER_START_GRP;

 

  1. Reset Jobs

Set the job queue processes to its original value on the new standby.

SQL> alter system set job_queue_processes=<value> scope=both sid='*';

SQL> show parameter job_queue_processes

 

Document:

Doc ID 1304939.1

 

ِData Guard Physical Standby Switchover using the Broker

1. Verify there are no Gaps:

Primary: 
select thread#, max(sequence#) "Last Primary Seq Generated"
from gv$archived_log val, gv$database vdb
where val.resetlogs_change# = vdb.resetlogs_change#
group by thread# order by 1;

 

Physical Stby:
select thread#, max(sequence#) "Last Standby Seq Applied"
from gv$archived_log val, gv$database vdb
where val.resetlogs_change# = vdb.resetlogs_change#
and val.applied in ('YES')
group by thread# order by 1;

 

Primary: 
select a.db_unique_name , a.dest_name ,a.archived_seq# ,  a.applied_seq#, a.gap_status 
  from v$archive_dest_status a
 where a.db_unique_name in ('BASE1');

 

Physical Stby:

select thread#, low_sequence#, high_sequence# from v$archive_gap;

 

2. Verify all datafiles are online On Target Standby:

SQL> select name from v$datafile where status='OFFLINE';

 

If there are any OFFLINE datafiles, and these are needed after switchover, bring them ONLINE:

SQL> alter database datafile '<DATAFILE_NAME>' online;

 

3. Verify Primary and Standby tempfiles match:

select tmp.name filename, bytes, ts.name tablespace
  from v$tempfile tmp, v$tablespace ts
 where tmp.ts#=ts.ts#;

 

If the queries do not match, then you can correct the mismatch now or immediately after the open of the new primary database;

 

4. Stop Jobs in Primary

SQL> select * from dba_jobs_running;

Depending on what the running job is, be ready to terminate the job if necessary.

 

Block further job submission by setting the job_queue_processes parameter to 0 so that there would be no jobs running during switchover.

SQL> show parameter job_queue_processes

SQL> alter system set job_queue_processes=0 scope=spfile;

 

5. Create Guaranteed Restore Points

 Physical Stby:

SQL> alter database recover managed standby database cancel;

SQL> create restore point SWITCHOVER_START_GRP guarantee flashback database;

SQL> alter database recover managed standby database using current logfile nodelay disconnect from session parallel 10;

 

Primary: 

SQL> create restore point SWITCHOVER_START_GRP guarantee flashback database;

 

6. Check the primary database:

DGMGRL> show database verbose 'primary_dbunique';

 

7. Check the standby database that is the target of the switchover:

DGMGRL> show database verbose 'standby_dbunique';

 

8. Issue the switchover command:

DGMGRL> switchover to 'standby_dbunique';

Switchover always originates from Primary database. On the request of switchover sql statement "alter database commit to switchover to physical standby with session shutdown", Primary will generate special marker called EOR (end-of-redo) that is placed in the header of online redo log sequence. So this online redo log sequence will be archived locally and sent to all standby databases. Only upon receiving and applying EOR (end-of-redo), v$database.switchover_status will change from "not allowed" to "to primary" or "sessions active". At this stage Physical standby is ready to assume Primary database role.

 

9. Show the configuration:

DGMGRL> show configuration;

 

10. Check Primary and Standby:

SQL> select db_unique_name,total_gap,open_mode,database_role from v$database;

 

11. Drop any Switchover Guaranteed Restore Points on all databases.

DGMGRL> drop restore point SWITCHOVER_START_GRP;

 

 

Document:

https://docs.oracle.com/cd/E11882_01/server.112/e40771/sofo.htm#DGBKR330

Doc ID 1305019.1

 

اوراکل دیتاگارد

Oracle Data Guard


· Oracle Data Guard Overview

Oracle Data Guard یکی از optionهای Oracle Database Enterprise Edition است که نیاز به نصب و لایسنس جداگانه ندارد. (برای اولین بار در اوراکل 9i معرفی شد ).


پیکربندی دیتاگارد در واقع شامل  دو بخش کلی میشود :

1- دیتابیس production یا primary : دیتابیسی که بوسیله بیشتر اپلیکیشن ها قابل دسترسی است . دیتابیس اصلی میتواند RAC باشد یا Single Instance .

2- دیتابیس یا دیتابیس های استندبای : در واقع یک کپی از دیتابیس اصلی است. همانند دیتابیس اصلی ، دیتابیس استندبای هم میتواند RAC باشد یا Single Instance . با استفاده از بکاپ دیتابیس اصلی شما میتوانید تا حداکثر 30 دیتابیس استندبای ( در 11gr2 ) ایجاد کنید.

دیتابیس ها در پیکربندی Data Guard  با استفاده از Oracle Net به هم متصل میشوند . هیچ محدودیتی از این جهت که دیتابیس ها کجا میتوانند باشند وجود ندارد، مثلا شما میتوانید یک استندبای را روی همان سیستمی کانفیگ کنید که دیتابیس اصلی قرار دارد و استندبای دیگر را روی سیستمی که از لحاظ جغرافیایی در فاصله ای دورتر از دیتابیس اصلی قرار دارد.