Data Guard

[batmunkh (Batmunkh Moltov)]

Oracle Data Guard нь хуулбар баазын үүсгэхэд ашиглах бөгөөд үүнийг дараах 3 төрлөөр тохируулж болно.

1. Logical Standby
2. Physical Standby
3. Snapshot Standby

Logical Standby

Logical Standby бааз нь үндсэн баазын хуулбар мэдээллийг өөр дээрээ агуулах боловч датафайл болон баазын мэдээллээс бусад зүйлс өөр газар өөр хэлбэртэйгээр хадгалагдан байж болох тусдаа бие даасан ажиллагаа бүхий бааз юм. Жишээ нь үндсэн баазын datafile1.dbf дотор байгаа А гэх мэдээлэл Logical Standby серверийн datafile5.dbf дотор хадгалагдаж байж боломжтой бөгөөд бусад өөр төрлийн мэдээллүүдийг давхар хадгалж байх боломжтой гэсэн үг юм.

Physical Standby

Physical Standby төрөлд бааз mount горимд ажиллах бөгөөд үндсэн баазтай датафайл, мэдээлэл болон бүхий төрлөөрөө ижил байна. Үндсэн баазын аль нэг датафайлын блок өөрчилөгдөх хуулбар бааз дээр мөн ижил файлын тухайн блокыг өөрчлөн хадгална гэсэн үг юм. Тиймээс үндсэн баазын контрол файл, дата файл зэргүүд гэмтсэн тохиолдолд хуулбар баазын файлыг ашиглан шууд сэргээх боломжтой гэсэн үг.
Үндсэн бааз унасан тохиолдолд автоматаар шилжин ажиллах боломжтой (failover). Гар аргаар switchover хийж болно.
Шилжих үйлдлийг SQL коммандын тусламжтай гүйцэтгэх боломжтой бөгөөд data guard broker ашиглан автоматжуулж (failover) болно. Мөн уг тохиргоо нь баазыг унших горимд ажиллуулах боломжтой.

Snapshot Standby

Уг төрөл нь хуулбар баазыг бичих горимд аваачих бөгөөд түр зуур туршилт хийх зорилготойгоор ашиглагдана. Ажиллагаа нь physical standby баазыг түр хөрвүүлж, тухайн хөрвүүлсэн агшны мэдээллийг snapshot хийж хадгалснаар туршилт дуусан буцаан physical standby төрөл рүү шилжүүлэхэд snapshot standby үед хийгдсэн бүх өөрчлөлтүүдийг буцааж хуулбар баазын ажлыг үргэлжлүүлэх юм.

Жш:
Physical standby баазыг 2016.12.28 12:00:29 -д Snapshot standby болгон өөрчилөхөд уг бааз руу бичих эрхтэй болно. Үүний дараагаар уг бичих эрхтэй болсон бааз дээр өөрчлөлтүүд хийж байгаад 2 цагийн дараа буюу 2016.12.28 14:05:58-д буцаан Physical Standby горим руу шилжүүлэхэд тухайн physical standby бааз 2016.12.28 12:00:29 цагаас хойшхи мэдээллүүдийг үндсэн баазаас нөхөж авч хадгална гэсэн үг юм. Мэдээллийн шинэчилэлтийг үндсэн серверээс татахаас өмнө snapshot standby горимд хийсэн өөрчлөлтүүдийг бүгдийг 2016.12.28 12:00:29 үеийн байдлаар буцаах болно.

Жич: цаашид мэдээллийг шинэчилж нэмж оруулах болно.

[batmunkh (Batmunkh Moltov)]

Physical Standby setup

Snapshot standby

Switchover

Failover

[batchimeg.b]

Data Guard тохируулаад primary баазаас rman target.аар standby database-тэй холбогдоход доорх алдаа гарч байна. Шалтгааныг нь олоход туслана уу?

[tmdeft (Tuvshinzaya)]

password file -аа хуулж өгсөн үү ?

[batchimeg.b]

password file.аа хуулсан. өөрийнхөө rman target.рүү ороход ч ийм алдаа заагаад байдаг.

[batmunkh (Batmunkh Moltov)]

1. tnsnames.ora шалга
2. $ORACLE_HOME/dbs/orapw{SID} файлаа шалга
3. Инстанс ассан эсэхээ шалга, Орчноо шалга
   …
   …

[tmdeft (Tuvshinzaya)]

remote_login_passwordfile = EXCLUSIVE байгаа юу ? alert log дээр юу гарч байна

[batmunkh (Batmunkh Moltov)]

@tmdeft

alert log дээр юу гарч байна

эхэлсэн арга нь буруу байсан байнаа… засаж байгаа… удахгүй өөр асуултууд орж ирэх байх аа. Бэлтгэлтэй байгаарай

[Batbold (Batbold Purevbaatar)]

Сайн байна уу,

Data Guard тохируулаад primary баазаас rman target.аар standby руу файлаа duplicate хийхэд standby дээрээ Datafile -уудаа хуулж эхэлсэн мөртлөө гүйцэд хуулаагүй зарим нэг datafile үлдээд /жишээ нь TEMP01.DBF / зурагт харуулсан алдаа заасан байна.
Уг нь бүх тохиргоогоо зөв хийсэн гэж бодож байгаа . Би юун дээр алдчихав ?

[batmunkh (Batmunkh Moltov)]

@Batbold

. Би юун дээр алдчихав ?

Physical Standby тохируулах

Өдөр RAC to Single DG тохируулж байхад гарч байсан алдаа байнаа. ASM -с файлсистем рүү хөрвүүлж чадахгүй болохоор нь set newname ашиглаад явуулчихсан. Араас нь duplicate коммандаа залгуулаад явуулна . run{ set newname for datafile 1 to '/u01/app/oracle/oradata/ORCL/datafile/01.dbf'; set newname for datafile 2 to '/u01/app/oracle/oradata/ORCL/datafile/02.dbf'; duplicate target database for standby from active database nofilenamecheck; } 19505 яг санаж байна db_file_name_con…

Энэ хэсгийг уншаарай

[batchimeg.b]

HI guys,
Надад нэг асуулт байна аа. Мэддэг нь хэлж өгч туслаач

1. Standby database restart хийгээд асаахаар recover хийхгүй, заавал primary database-ийг restart хийсний дараа standby дээрх recovery хийгдэх юм. Би ямар нэг тохиргоо буруу хийчэхсэн юм болов уу. Асуудал нь юундаа байна аа

[tmdeft (Tuvshinzaya)]

Hi, recover gj archive log apply хийхийг хэлж байна уу ? standby талдаа

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

ингсэн байгаа юу ? primary -гаа restart хийнэ гэж бүүр shutdown хийхийг хэлж байна уу эсвэл archive_dest -ээ enable defer хийхийг хэлж байна уу ?

[batchimeg.b]

standby taldaa alter database recover managed standby database using current logfile disconnect from session; ajilluulaad archive log apply hiihgu. tegeed primary database.ee shutdown hiiged startup hiihed standby.iin archive log.ууд apply hiigdej bga

[tmdeft (Tuvshinzaya)]

Ажиллахгүй байгаа үед

select * from v$archive_dest_status;

дээр ямар үр дүн харуулж байна, dest 2 дээр чинь ч юм уу status болон gap_status нтр мэдээлэл нь юу гэж байгаа юм болдоо, бас ажиллахгүй байх үед alert log дээр password file ч юм уу ямар нэг алдаа гарж байна уу шалгаарай

[batchimeg.b]

HI мундагуудаа туслаарай
windows oracle 12c дээр Data guard тохируулаад primary-аас standby-руугаа Rman> duplicate target database for standby from active database хийхэд datafile.уудаа хуулчихаад log file-уудаа/redo.log, standby.log, archive.log/ хуулахгүй гөлиичихөөд байгаа.

log_file_name_convert=D:\app\proddbdata\proddb, E:\app\Administrator\oradata\standbydb, F:\FRA\proddb, F:\FRA\standbydb
гэх мэт шаардлагатай тохиргоонуудыг хийсэн.
Асуудлаа олоход минь туслана уу

[batchimeg.b]

ялгаагүй байна аа. log.руу ийм мэдээлэл бичигдэж байна.
Thu Jun 06 16:53:12 2019
ALTER SYSTEM SET log_archive_dest_state_2=‘ENABLE’ SCOPE=MEMORY SID=’*’;
Thu Jun 06 16:53:12 2019
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\proddb\proddb\trace\proddb_arc2_4164.trc:
ORA-16058: standby database instance is not mounted
Thu Jun 06 16:53:12 2019
PING[ARC2]: Heartbeat failed to connect to standby ‘standbydb’. Error is 16058.
Thu Jun 06 16:53:12 2019
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\proddb\proddb\trace\proddb_tt00_3988.trc:
ORA-16058: standby database instance is not mounted
Thu Jun 06 16:53:12 2019
Error 16058 for archive log file 3 to ‘standbydb’
Thu Jun 06 16:53:12 2019
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\proddb\proddb\trace\proddb_tt00_3988.trc:
ORA-16058: standby database instance is not mounted
Thu Jun 06 16:53:12 2019
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\proddb\proddb\trace\proddb_tt00_3988.trc:
ORA-16058: standby database instance is not mounted
Thu Jun 06 16:53:14 2019
Thread 1 advanced to log sequence 253 (LGWR switch)
Current log# 1 seq# 253 mem# 0: D:\APP\PRODDBDATA\PRODDB\REDO01A.LOG
Current log# 1 seq# 253 mem# 1: F:\FRA\PRODDB\REDO01B.LOG
Thu Jun 06 16:53:14 2019
Archived Log entry 230 added for thread 1 sequence 252 ID 0x2cac5b05 dest 1:
Thu Jun 06 17:21:35 2019
Active Session History (ASH) performed an emergency flush. This may mean that ASH is undersized. If emergency flushes are a recurring issue, you may consider increasing ASH size by setting the value of _ASH_SIZE to a sufficiently large value. Currently, ASH size is 67108864 bytes. Both ASH size and the total number of emergency flushes since instance startup can be monitored by running the following query:
select total_size,awr_flush_emergency_count from v$ash_info;

[batchimeg.b]

@batchimeg.b

select total_size,awr_flush_emergency_count from v$ash_info;

*** 2019-06-06 16:49:13.700
*** SESSION ID:(721.45389) 2019-06-06 16:49:13.700
*** CLIENT ID:() 2019-06-06 16:49:13.700
*** SERVICE NAME:() 2019-06-06 16:49:13.700
*** MODULE NAME:() 2019-06-06 16:49:13.700
*** CLIENT DRIVER:() 2019-06-06 16:49:13.700
*** ACTION NAME:() 2019-06-06 16:49:13.700

Created 2 redo writer workers (2 groups of 1 each)

*** 2019-06-06 16:55:03.878
kcrfw_slave_adaptive_updatemode: scalable->single group0=507 all=516 rw=638 single=1258 scalable_nopipe=1276 scalable_pipe=701 scalable=1265

*** 2019-06-06 16:55:03.878
Adaptive scalable LGWR disabling workers

*** 2019-06-06 17:04:22.659
kcrfw_slave_adaptive_updatemode: single->scalable redorate=9774 switch=3256

*** 2019-06-06 17:04:22.659
Adaptive scalable LGWR enabling workers
kcrfw_slave_adaptive_updatemode: scalable->single group0=1536 all=1543 rw=622 single=926 scalable_nopipe=1244 scalable_pipe=684 scalable=1241

*** 2019-06-06 17:26:06.396
Adaptive scalable LGWR disabling workers
kcrfw_slave_adaptive_updatemode: single->scalable redorate=12062 switch=1610

*** 2019-06-06 18:04:32.818
Adaptive scalable LGWR enabling workers

[batmunkh (Batmunkh Moltov)]

DB mount хийгдээгүй байна гэдэг нь наад үйлдэл дээр чинь очихоос өмнө асуудал байна даа…

[zolboo (Zolboo Bayanbulag)]

@batmunkh

Failover

Fast start failover идэвхжүүлэхийн давуу тал log oo харах мөн REINSTATE DATABASE primary гэж гараар команд ажиллуулахын оронд идэвхжүүлж байна гэж ойлголоо