3rb4techs: Methods to Configure Knowledge Guard Utilizing a Bodily Standby Database

Lately, I made a decision to check out the rollback technique that we have been going to make use of when updating our databases to Oracle 11g. At the moment, we used Oracle 10g, and we had the next information safety setting:

Major Database 10.2.0.4

Bodily backup database 1, 10.2.0.4

Bodily backup DB 2, 10.2.0.4

NOTE. The working system we use is Home windows Server 2003 with Service Pack 2 (SP2). Though these directions are for the Home windows setting, they may even work in every other setting, the one distinction is that a few of them relate to a particular Home windows configuration, equivalent to making a Home windows service.

Knowledge Guard Improve Plan

The plan was to improve each information safety databases to 11g concurrently with the primary one. As a part of the improve, we would have liked to have a failover restoration plan in order that in case of an replace failure, we might restore the first and backup databases to the time limit earlier than the improve. We didn't wish to rebuild the backup databases if the replace failed, as a result of it might take a number of time and would require rather more work. The rollback plan for the first database was comparatively easy:

Database shutdown

Take a snapshot of the LUN on the SAN stage

Increase the database and run the replace.

Drop the snapshot if the replace was profitable.

Rollback to snap if replace failed

Preliminary questions?

The issue we confronted with the backup databases was that we didn't have the power to bind drives to the SANs on which they labored, as a result of the SAN expertise was outdated and we didn't have licenses for it. We additionally had just a few questions on establishing information safety and the way it will work:

If we roll again the primary database, how can we roll again the bodily backup databases in the event that they used the logs throughout the replace?

Can we cease the backup databases utilizing logs, roll again the primary database to the Snap model and begin sending logs once more?

Will the bodily backup database be taken from the place the place it stopped, if we delete the logs that have been created throughout the replace?

If the first database was within the sequence of 100 archive logs throughout the snapshot, and it creates 50 logs throughout your complete replace course of, and we return it again, will it proceed the sequence of 100 once more?

We made affordable assumptions about what precisely we expect, however the questions above ought to offer you an thought of the sorts of questions that we weren't certain of earlier than we accomplished any testing. The easiest way to show one thing is to truly check it, so I made a decision to check our idea. What was the speculation? Effectively, we thought (I hope that ...) that if we canceled the supply of logs throughout the replace (SEND log archive locations), rolled again the first database to the model of the disks with binding, deleted all of the logs that have been created throughout replace time, after which re-enable log archive locations in order that bodily backup databases for information safety take them from the place they left off, which was not smart for an unsuccessful replace within the main database.

What are we going to examine

Here's a checklist of what I'll undergo within the following instance:

Configure information safety in model 10.2.0.4 (though this additionally applies to information safety 11g)

Create a backup of your main database to be able to restore it and create bodily backup databases.

Restoration course of to arrange your bodily backup databases

Methods to make log transport work from main to backup?

Setting a rollback technique increased

Simulation of unsuccessful replace try

Roll again to instantaneous database model (at SAN stage)

Check to see if every little thing works because it was earlier than the replace.

SAN Vs Flashback Database - Private View ...

I've to notice that on this check I labored with the storage workforce to get a snapshot of the disk (s) earlier than finishing any improve work. Personally, I feel it is a a lot better answer for this sort of work than utilizing Oracle's flashback expertise for a number of causes:

Reminiscence requires a considerable amount of area to retailer any modifications.

I bumped into issues utilizing Oracle's Flashback expertise whereas performing an replace, which broken my assured restore level. very dangerous!

The SAN snapshot could be very quick, clear and doesn't require any configuration modifications from an Oracle viewpoint — only a clear shutdown of the database throughout snapshot creation.

So, on this check, I'll present you methods to create a backup database out of your principal database with all of the instructions I wanted to make use of. I hope this all speaks for the well-informed Oracle database directors. If not, please ask any questions on the backside of the web page within the feedback part or e-mail me and I'll do my greatest to assist.

Step-by-step information to creating and configuring Knowledge Guard Bodily Standby

In your main database, reduce the scale of the database as a lot as doable so that you could again up, copy and restore to a backup database quicker. I typically use this little script to dynamically execute it for a particular tablespace. It would attempt to scale back every tablespace by 500 MB, however you'll be able to customise it as you want, and do that for every tablespace by eradicating a part of the “the place tablespace_name =” expression.

shrink.out coil set up server on to start for i in (choose “change database information file” || file_id || "resize" || TRUNC (bytes - 512000000) || &; 39 ;; & # 39; as cmd from dba_data_files, the place tablespace_name = & # 39; DW3_L1_X128Ok & # 39;) loop dbms_output.put_line (i.cmd); finish loop; finish; / spool @ shrink.out

RMAN Level0 and Archive Mode

Step one is to create a backup of RMAN stage 0, which you'll later use to revive and create a bodily backup database. I assume that you do not need to delete the database to finish the backup, so I hope your database is already operating in ARCHIVELOG mode? You possibly can examine with this request:

SELECT log_mode FROM v $ database;

In case your main database shouldn't be in ARCHIVELOG mode, you are able to do a chilly backup, that's, when the database shouldn't be working, or switch the database to ARCHIVELOG mode. To do that, configure the log_archive_dest_1 parameter and allow it as follows:

ALTER SYSTEM SET log_archive_dest_1 = & # 39; LOCATION = D: TEMP TESTDB ARCHLOGS & # 39; SCOPE = SPFILE; TRIP IMMEDIATELY STARTUP MOUNT ALTER DATABASE ARCHIVELOG; ALTER DATABASE OPEN; ALTER SYSTEM SWITCH LOGFILE;

Now make certain the archived redo logs seem within the location specified by the log_archive_dest_1 parameter.

Pressured database logging

If you're making a bodily backup database, it's vital that your database doesn't have unregistered transactions, equivalent to direct loading of the trail and transactions that don't generate REDO, as a result of your database is similar to the bodily main copy, due to this fact all transactions have to be utilized within the right okay To do that, you should run the next command:

ALTER DATABASE FORCE LOGGING;

So, now we're working in ARCHIVELOG mode and at all times register all transactions within the REDO stream, we will make a backup of stage Zero utilizing the next instructions:

rman goal sys /<pwd>@<SID> to run { backup as a compressed backup set with an incremental stage = Zero database plus a log archive; }

The time required for backup relies on the scale of your database. If you happen to use the traditional compression stage for RMAN, your backup might be about 20% of the scale of your database.

After stage Zero backup completes, it's essential to copy the recordsdata to a backup host, prepared for restoration, to create a bodily backup database.

Configuration parameter initialization

Earlier than restoring the bodily standby database, we have to configure some further parameters within the main database in order that information safety acts as the first database within the information safety configuration. Beneath I listed the parameters that I wanted to alter to be able to configure the primary database for Knowledge Guard:

NOTE. I additionally arrange some parameters which are required provided that the first database turns into the standby database, in different phrases, within the occasion of a failover or swap state of affairs.

NOTE. Within the examples under, TEST is the primary database and TESTDG is the bodily standby database.

NOTE. The situation of the recordsdata within the Knowledge Guard database will differ solely by the database identify. For instance, the trail & # 39; D: ORADATA TEST & # 39; will develop into & # 39; D: ORADATA TESTDG & # 39 ;.

change system set log_archive_config = & # 39; DG_CONFIG = (TEST, TESTDG) & # 39; scope = each; - This means that there have to be two databases within the Knowledge Guard configuration change the system set LOG_ARCHIVE_DEST_STATE_1 = ENABLE scope = each; - Contains first log archive vacation spot change the system set log_archive_dest_2 = & # 39; SERVICE = TESTDG ASYNC VALID_FOR = (ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME = TESTDG & # 39; scope = each; - customizes the supply of the archived REDO log when the database is in the primary position within the Knowledge Guard database (TESTDG) change the system set LOG_ARCHIVE_DEST_STATE_2 = DEFER scope = each; - Contains second vacation spot log archive change system set remote_login_passwordfile = EXCLUSIVE scope = spfile; - This worth have to be the identical in each databases to ship logs. change the system set LOG_ARCHIVE_FORMAT =% t_% s_% r.arc scope = each; - Customizes the format for the names of archived redo logs. change the system set LOG_ARCHIVE_MAX_PROCESSES = Four visibility = each; - That is the utmost variety of processes that may be despatched logs. Including extra information can improve CPU utilization if you should ship a lot of logs. change system set FAL_SERVER = TESTDG scope = each; - Putting in the Fetch Archive Log server as a TESTDG backup database - Required solely when main switches to standby change system set DB_FILE_NAME_CONVERT = & # 39; TESTDG & # 39 ;, & # 39; TEST & # 39; scope = spfile; - This converts all of the paths to the information recordsdata the place TESTDG is within the identify and replaces it with TEST. - Required solely when main switches to standby change the system set LOG_FILE_NAME_CONVERT = & # 39; TESTDG & # 39 ;, & # 39; TEST & # 39; scope = spfile; - It converts all paths to log recordsdata the place TESTDG is within the identify and replaces it with TEST. - Required solely when main switches to standby change system set STANDBY_FILE_MANAGEMENT = AUTO scope = each; - Ensures that when including and deleting recordsdata, they're additionally added and faraway from the Knowledge Guard database.

Management file and PFILE creation

Now that the initialization parameters are configured within the main database, it's time to create a backup management file and an information guard database parameter file.

ALTER DATABASE CREATE STANDBY CONTROLFILE AS & # 39; C: temp TEST.ctl & # 39 ;; CREATE PFILE = & # 39; C: temp initTEST.ora & # 39; FROM SPFILE = & # 39; G: Oracle oradata TEST admin pfile spfileTEST.ora; - Create parameter file for backup database - I at all times clearly outline the place the PFILE and SPFILE places are positioned, to keep away from issues with utilizing the fallacious file - Copy this file along with the backup management file to the Knowledge Guard database server, prepared for restoration.

Now it's a must to take the initTEST.ora parameter file and alter the settings in order that it may be used for the bodily standby database.

DB_NAME = TEST - DB_NAME stays the identical as the first database, I simply needed to level you right here DB_UNIQUE_NAME = TESTDG - Modify this to mirror the identify of your Knowledge Guard database, I exploit TESTDG right here Control_files = & # 39; D: ORADATA TESTDG CONTROL01.CTL & # 39 ;, & # 39; D: ORADATA TESTDG CONTROL02.CTL & # 39 ;, & # 39; D: ORADATA TESTDG CONTROL03 .CTL & # 39; - There have to be at the very least two of them, I exploit three, and the one distinction in the best way is that I modified TEST to TESTDG DB_FILE_NAME_CONVERT = & # 39; TEST & # 39 ;, & # 39; TESTDG & # 39; - The identical configuration as earlier than, however this interprets the names of the primary information recordsdata into the names of the Knowledge Guard LOG_FILE_NAME_CONVERT = & # 39; TEST & # 39 ;, & # 39; TESTDG & # 39; - As earlier than, the names of the log recordsdata within the path are modified to mirror their location on the disk LOG_ARCHIVE_DEST_1 = & # 39; LOCATION = O: flash_recover_TEST ArchLogs VALID_FOR = (ALL_LOGFILES, ALL_ROLES) DB_UNIQUE_NAME = TESTDG & # 39; - That is the place the place archived REDO logs might be positioned in standby mode and in principal roles. LOG_ARCHIVE_DEST_2 = & # 39; SERVICE = TEST ASYNC VALID_FOR = (ONLINE_LOGFILES, PRIMARY_ROLE) DB_UNIQUE_NAME = TEST & # 39; - Listed here are the parameters used when the database is in the primary position. - Required solely when the standby mode is switched to the primary LOG_ARCHIVE_DEST_STATE_1 = ENABLE LOG_ARCHIVE_DEST_STATE_2 = ENABLE - Ensure each archiving locations are enabled. FAL_SERVER = TEST - This means the identify of the first database.

So, we configured all of the initialization parameters for each the first and bodily backup databases, and added the suitable parameters in case of failure or switching of the first and backup roles within the Knowledge Guard configuration.

Home windows service, listener, TNSNames, and many others.

The following step is to configure the Home windows service on the server, listeners, TNSNames recordsdata, password recordsdata, and create SPFILE for the standby database. Let's see how we're going to do that.

1. Add TNSNames entries to current Oracle purchasers on the first and backup database servers.

After utilizing the database names TEST and TESTDG, as we did within the earlier components of this text, listed below are the TNSNames entries for these databases:

TEST.DEV.INT.COM = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (Host = TESTlistener) (Port = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = TEST.DEV.INT.COM) (SERVER = ALLOWED) ) ) TESTDG.DEV.INT.COM = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP) (Host = TESTDGListener) (Port = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = TESTDG.DEV.INTCOM) (SERVER = ALLOWED) ) )

NOTE. I exploit the DNS entry for the HOST parameter. If you're utilizing DNS, make it possible for the DNS identify is resolved accurately utilizing the NSLOOKUP command from each servers.

NOTE. You will need to be sure that SQLNet visitors is allowed in each instructions in order that logs will be delivered.

2. Add listener information to the Knowledge Guard database server and the primary database server.

You possibly can create new listeners if they aren't already put in, or just add the configuration to the one already put in, that’s as much as you. Listed here are the entries that I've for the TEST and TESTDG databases:

- Knowledge Guard Listener Configuration 11GDGLIST = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = 10.63.41.57) (PORT = 1521)) ) ) SID_LIST_11GDGLIST = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = TESTDG.DEV.INT.COM) (ORACLE_HOME = D: oracle product.2.0 dbhome_11203) (SID_NAME = TEST) ) ) - Configuration of the primary database listener 11GLIST = (DESCRIPTION_LIST = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP) (HOST = 10.60.41.57) (PORT = 1521)) ) ) SID_LIST_11GLIST = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = TEST.DEV.INT.COM) (ORACLE_HOME = D: oracle product.2.0 dbhome_11203) (SID_NAME = TEST) ) )

NOTE. We hope that you simply seen that within the configuration for the Knowledge Guard listener SID_NAME = TEST, not TESTDG. It's because if you happen to do not forget that the precise DB_NAME is similar as the primary (TEST), however DB_UNIQUE_NAME is TESTDG.

3. Create a Home windows service on the Knowledge Guard database server.

We are going to use the ORADIM utility to create a Home windows service on the Knowledge Guard database server.

D: oracle product.2.0 dbhome_11203 oradim - NEW -SID TESTDG -STARTMODE m

NOTE. I specify the complete path to the oradim utility, for the reason that server is multi-home, and I wish to keep away from doable confusion as to which executable file it makes use of. It's at all times safer to explicitly point out which executable / file / and many others. You wish to use. Then you already know precisely what you'll get.

NOTE. You possibly can change the settings for this Home windows service at any time by opening the registry settings (start-> run-> regedit HKEY_LOCAL_MACHINE-> software-> Oracle-> your_oracle_home_name)

4. Create a password file for the Knowledge Guard database.

D: oracle product 11.2.0 dbhome_11203 orapwd file = & # 39; D: ORADATA TESTDG pwdTEST.ora & # 39; password = change_on_install

5. Create an SPFILE for the Knowledge Guard database.

SET ORACLE_SID = TEST SQLPLUS "sys / change_on_install as sysdba" STARTUP NOMOUNT PFILE = & # 39; D: ORADATA TESTDG ADMIN PFILE initTEST.ora & # 39; CREATE SPFILE = & # 39; D: ORADATA TESTDG ADMIN PFILE SPFILETEST.ora & # 39; FROM PFILE = & # 39; D: ORADATA TESTDG ADMIN PFILE initTEST.ora & # 39;

Nearly there ... We're making good progress. We made a number of settings, now it's time to seek out out if that is actually right! The following step is to revive the backup copy of the RMAN stage, which was taken from the first database and copied.

SET NLS_DATE_FORMAT = YYYY-MM-DD: HH24: MI: SS RMAN TARGET sys / change_on_install @ TESTDG ALTER DATABASE MOUNT; - Keep in mind that you've got already assigned a database STARTING THE CATALOG C & # 39; O: Oracle flash_recover_TESTDG flashback TEST BACKUPSET12_05_29 & # 39 ;; - A listing of RMAN recordsdata of stage Zero in order that the database is aware of concerning the existence of recordsdata SELECT & # 39; set a brand new identify for the information file & # 39; & # 39; & # 39; || file_name || & # 39; & # 39; & # 39; in & # 39; & # 39; & # 39; || substitute (filename, & # 39; TEST & # 39 ;, & # 39; TESTDG & # 39;) || & # 39; & # 39; & # 39 ;; & # 39; as an information file from dba_data_files; - The command used to get the names of the recordsdata for the operation of switching / setting a brand new identify - To work with the first database and use within the RUN block under to run { CHANNEL DISTRIBUTION DEVICE TYPE DISC FORMAT c1 & # 39; O: Oracle flash_recover_TEST flashback TEST BACKUPSET12_05_29 & # 39 ;; FORMAT DISC TYPE OF CHANNEL DISCHARGE DEVICE c2 & # 39; O: Oracle flash_recover_TEST flashback TEST BACKUPSET12_05_29 & # 39 ;; Set a brand new identify for the information file & # 39; D: ORADATA TEST DATA SYSTEM01.DBF & # 39; in & # 39; D: ORADATA TESTDG DATA SYSTEM01.DBF & # 39 ;; Set a brand new identify for the information file & # 39; D: ORADATA TEST DATA UNDOTBS01.DBF & # 39; in & # 39; D: ORADATA TESTDG DATA UNDOTBS01.DBF & # 39 ;; Set a brand new identify for the information file & # 39; D: ORADATA TEST DATA SYSAUX01.DBF & # 39; in & # 39; D: ORADATA TESTDG DATA SYSAUX01.DBF & # 39 ;; Set a brand new identify for the information file & # 39; D: ORADATA TEST DATA USERS01.DBF & # 39; в &#39;D: ORADATA TESTDG DATA USERS01.DBF&#39;; ВОССТАНОВИТЬ БАЗУ ДАННЫХ ИЗ TAG &#39;TAG20120529T110507&#39;; БАЗА ДАННЫХ ВОССТАНОВЛЕНИЯ; ПЕРЕКЛЮЧИТЬ ДАННЫЕ ВСЕ; } - Этот блок RUN выделяет два канала для использования при восстановлении и восстановлении. Вы можете использовать больше каналов, если у вас больше лошадиных сил! - Команды «set newname» являются производными от предыдущего сценария динамического SQL. Скопируйте и вставьте в - Команда RESTORE указывает TAG для резервной копии RMAN уровня 0 - Затем команды восстанавливают базу данных и переключают все имена файлов данных в соответствии с заданными командами новых имен

Это оно! Восстановление файлов данных займет некоторое время. Чем больше БД, тем больше время восстановления.

Теперь пришло время убедиться, что основная БД включена для отправки журналов REDO:

ALTER SYSTEM SET log_archive_dest_state_2 = ENABLE SCOPE = оба; - на первичной БД База данных ALTER DATABASE RECADER, управляемая STANDBY, ОТКЛЮЧЕНА ОТ СЕССИИ; - В резервной БД

Надеюсь, вы все настроили правильно, и это будет работать впервые ... Для большинства из тех, кто этого не сделал, вот несколько советов, которые помогут вам:

Возможные проблемы конфигурации Knowledge Guard

Ошибка 1017 при входе в режим ожидания -------------------------------------------------- ---------- Убедитесь, что основной и резервный используют файл паролей и remote_login_passwordfile установлен на SHARED или EXCLUSIVE, и что пароль SYS одинаков в файлах паролей. возвращая ошибку ORA-16191 -------------------------------------------------- ----------

Убедитесь, что вы сделали следующее:

1. Добавлены записи TNS как на основной, так и на резервной БД. Если у вас есть несколько домов, убедитесь, что вы изменили правильный

2. Убедитесь, что записи были добавлены для слушателей на обоих серверах БД.

3. Проверьте вход SQL Plus с первичной БД в резервную и наоборот.

4. Скопируйте файл паролей с первичной и используйте его для резервной БД

5. Проверьте сетевое подключение к резервному хосту на правильном порту (по умолчанию 1521)

Теперь у нас должна быть настроена база данных Knowledge Guard и мы рады, что журналы отправляются с первичной базы данных на резервную. Сначала проверьте это, переключив журналы на первичной базе данных несколько раз. Вы можете проверить, что журналы применяются к физическому резервированию, используя этот запрос:

установить линии 120 набор страниц 1000 изменить сессионный набор nls_date_format = &#39;ДД-ММ-ГГГГ ЧЧ24: MI: SS&#39;; ВЫБЕРИТЕ SEQUENCE #, APPLIED, FIRST_TIME, NEXT_TIME FROM V $ ARCHIVED_LOG ГДЕ FIRST_TIME> SYSDATE -3 ЗАКАЗ ПО ПОСЛЕДОВАТЕЛЬНОСТИ #;

Следующим этапом эксперимента является создание снимков, имитация неудачного обновления и проверка отката. Это то, что я проведу тебя сейчас.

Тестирование отката с помощью Snaps

1. Переключите файл журнала на основной

ALTER SYSTEM SWITCH LOGFILE;

2. Убедитесь, что применяется в режиме ожидания

установить линии 120 набор страниц 1000 изменить сессионный набор nls_date_format = &#39;ДД-ММ-ГГГГ ЧЧ24: MI: SS&#39;; <xmp> ВЫБЕРИТЕ SEQUENCE #, APPLIED, FIRST_TIME, NEXT_TIME FROM V $ ARCHIVED_LOG ГДЕ FIRST_TIME> SYSDATE -3 ЗАКАЗ ПО ПОСЛЕДОВАТЕЛЬНОСТИ #; 3. Отложите архив журнала 2 Dest ALTER SYSTEM SET log_archive_dest_state_2 = DEFER SCOPE = оба; 4. Отключить основную БД ОТКЛЮЧЕНИЕ НЕМЕДЛЕННО; 5. Защелкните основной диск (и) БД Попросите инженера по хранению сделать это 6. Поднимите основную БД ЗАПУСКАТЬ 7. Запустите несколько примеров скриптов / работы с БД. Это может быть что угодно, но я использую простой пример, чтобы немного действия через базу данных. <xmp> создать таблицу rj_test ( Идентификационный номер (10), ИМЯ VARCHAR2 (25)); to start для меня в петле 1..100000 вставить в значения rj_test (1, &#39;Rob&#39;); концевой цикл; конец; /

COMMIT;

8. Завершите работу БД (требуется поддельный откат)

ОТКЛЮЧЕНИЕ НЕМЕДЛЕННО

9. Вернитесь обратно к отключенному диску

Попросите инженеров по хранению данных вернуться к оснастке

*** Удалите все архивы, созданные за это время ***

Если вы этого не сделаете, может возникнуть конфликт, когда база данных попытается создать другие архивы с такими же именами. Кроме того, вы не хотите, чтобы заархивированные журналы повторов отправлялись в вашу резервную базу данных, поэтому перемещайте / удаляйте их, чтобы быть в безопасности.

10. Поднимите базу данных

ЗАПУСКАТЬ

11. ВКЛЮЧИТЬ архивлог 2 dest

ALTER SYSTEM SET log_archive_dest_state_2 = ENABLE SCOPE = оба;

12. Снова включите доставку архивного журнала, выполнив эту команду в базе данных Knowledge Guard.

База данных ALTER DATABASE RECADER, управляемая STANDBY, ОТКЛЮЧЕНА ОТ СЕССИИ;

13. Проверьте архивы доставки и отправки в резервную БД

установить линии 120 набор страниц 1000 изменить сессионный набор nls_date_format = &#39;ДД-ММ-ГГГГ ЧЧ24: MI: SS&#39;; ВЫБЕРИТЕ SEQUENCE #, APPLIED, FIRST_TIME, NEXT_TIME FROM V $ ARCHIVED_LOG ГДЕ FIRST_TIME> SYSDATE -3 ЗАКАЗ ПО ПОСЛЕДОВАТЕЛЬНОСТИ #;

Теперь, когда вы выполнили все эти шаги, вы должны надеяться, что архивные журналы повторов снова отправляются в вашу физическую резервную базу данных для защиты данных. И, самое главное, этот тест подтвердил, что моя теория верна, и вы можете использовать моментальные снимки, чтобы откатить неудачное обновление первичной базы данных и позволить физическим резервным базам данных продолжить восстановление с того места, на котором они остановились перед обновлением.

Здесь я должен указать, что это также возможно, если вы хотите запустить долгосрочное обновление своей основной базы данных и не остановить доставку журналов, чтобы можно было одновременно делать снимки дисков в физической резервной базе данных. Выполнение этого будет означать, что вам придется восстанавливать базу данных Knowledge Guard, если обновление завершится неудачно, но если оно прошло успешно, оно уже будет соответствовать первичному, поэтому не потребуется подгонка журналов REDO.

Какой вариант вы решите выбрать, зависит от вас и будет зависеть от ваших конкретных требований и того, что вы считаете приемлемым и необходимым.

3rb4techs

Methods to Configure Knowledge Guard Utilizing a Bodily Standby Database

No comments:

Post a Comment

Contact Us