poplus2: Tips on how to Configure Knowledge Guard Utilizing a Bodily Standby Database

Just 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 knowledge safety setting:

Main 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 surroundings, they will even work in another surroundings, the one distinction is that a few of them relate to a particular Home windows configuration, akin to making a Home windows service.

Knowledge Guard Improve Plan

The plan was to improve each knowledge safety databases to 11g concurrently with the principle one. As a part of the improve, we wanted 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 cut-off date earlier than the improve. We didn't need to rebuild the backup databases if the replace failed, as a result of it could take loads of time and would require far more work. The rollback plan for the first database was comparatively easy:

Database shutdown

Take a snapshot of the LUN on the SAN stage

Elevate 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 a number of questions on establishing knowledge safety and the way it will work:

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

Can we cease the backup databases utilizing logs, roll again the principle 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 through the replace?

If the first database was within the sequence of 100 archive logs through the snapshot, and it creates 50 logs throughout the 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 provide you with an concept of the sorts of questions that we weren't certain of earlier than we accomplished any testing. One of the simplest ways to show one thing is to truly take a look at it, so I made a decision to check our idea. What was the idea? Effectively, we thought (I hope that ...) that if we canceled the supply of logs through 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 knowledge safety take them from the place they left off, which was not clever for an unsuccessful replace within the major database.

What are we going to test

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

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

Create a backup of your major database with a view to restore it and create bodily backup databases.

Restoration course of to arrange your bodily backup databases

Tips on how to make log delivery work from major to backup?

Setting a rollback technique increased

Simulation of unsuccessful replace try

Roll again to prompt database model (at SAN stage)

Take a look at to see if every part works because it was earlier than the replace.

SAN Vs Flashback Database - Private View ...

I've to notice that on this take a look at I labored with the storage staff to get a snapshot of the disk (s) earlier than finishing any improve work. Personally, I believe this can be a significantly better resolution for this type of work than utilizing Oracle's flashback expertise for a number of causes:

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

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

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

So, on this take a look at, I'll present you how one can create a backup database out of your important 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 finest to assist.

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

In your major database, reduce the scale of the database as a lot as attainable as a way to again up, copy and restore to a backup database sooner. I typically use this little script to dynamically execute it for a particular tablespace. It's going to attempt to scale back every tablespace by 500 MB, however you possibly can 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 knowledge 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 working in ARCHIVELOG mode? You may test with this request:

SELECT log_mode FROM v $ database;

In case your major database is just not in ARCHIVELOG mode, you are able to do a chilly backup, that's, when the database is just not 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 be sure the archived redo logs seem within the location specified by the log_archive_dest_1 parameter.

Compelled database logging

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

ALTER DATABASE FORCE LOGGING;

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

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

The time required for backup will depend on the scale of your database. Should you use the conventional compression stage for RMAN, your backup shall be about 20% of the scale of your database.

After stage Zero backup completes, you need to copy the information 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 extra parameters within the major database in order that knowledge safety acts as the first database within the knowledge safety configuration. Beneath I listed the parameters that I wanted to alter with a view to configure the principle 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 beneath, TEST is the principle database and TESTDG is the bodily standby database.

NOTE. The placement of the information within the Knowledge Guard database will differ solely by the database title. 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 should 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 principle 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 should 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 knowledge can enhance CPU utilization if you have to ship numerous logs. change system set FAL_SERVER = TESTDG scope = each; - Putting in the Fetch Archive Log server as a TESTDG backup database - Required solely when major 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 info information the place TESTDG is within the title and replaces it with TEST. - Required solely when major 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 information the place TESTDG is within the title and replaces it with TEST. - Required solely when major switches to standby change system set STANDBY_FILE_MANAGEMENT = AUTO scope = each; - Ensures that when including and deleting information, 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 major database, it's time to create a backup management file and a knowledge 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 all the time clearly outline the place the PFILE and SPFILE areas are positioned, to keep away from issues with utilizing the incorrect file - Copy this file along with the backup management file to the Knowledge Guard database server, prepared for restoration.

Now it's important 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 wished to level you right here DB_UNIQUE_NAME = TESTDG - Modify this to replicate the title 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 should be no less than two of them, I exploit three, and the one distinction in the way in which 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 principle knowledge information 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 information within the path are modified to replicate 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 shall be positioned in standby mode and in important 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 principle position. - Required solely when the standby mode is switched to the principle LOG_ARCHIVE_DEST_STATE_1 = ENABLE LOG_ARCHIVE_DEST_STATE_2 = ENABLE - Ensure that each archiving locations are enabled. FAL_SERVER = TEST - This means the title 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 so on.

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

1. Add TNSNames entries to current Oracle shoppers 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, guarantee that the DNS title is resolved accurately utilizing the NSLOOKUP command from each servers.

NOTE. You could make sure that SQLNet site visitors is allowed in each instructions in order that logs might be delivered.

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

You may 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 principle 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 observed that within the configuration for the Knowledge Guard listener SID_NAME = TEST, not TESTDG. It's because for those who do not forget that the precise DB_NAME is identical as the principle (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 total path to the oradim utility, because the server is multi-home, and I need to keep away from attainable confusion as to which executable file it makes use of. It's all the time safer to explicitly point out which executable / file / and so on. You need to use. Then you recognize precisely what you'll get.

NOTE. You may 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 loads of settings, now it's time to search 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; - Bear in mind that you've already assigned a database STARTING THE CATALOG C & # 39; O: Oracle flash_recover_TESTDG flashback TEST BACKUPSET12_05_29 & # 39 ;; - A listing of RMAN information of stage Zero in order that the database is aware of concerning the existence of information SELECT & # 39; set a brand new title for the info file & # 39; & # 39; & # 39; || file_name || & # 39; & # 39; & # 39; in & # 39; & # 39; & # 39; || exchange (filename, & # 39; TEST & # 39 ;, & # 39; TESTDG & # 39;) || & # 39; & # 39; & # 39 ;; & # 39; as a knowledge file from dba_data_files; - The command used to get the names of the information for the operation of switching / setting a brand new title - To work with the first database and use within the RUN block beneath 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 title for the info file & # 39; D: ORADATA TEST DATA SYSTEM01.DBF & # 39; in & # 39; D: ORADATA TESTDG DATA SYSTEM01.DBF & # 39 ;; Set a brand new title for the info file & # 39; D: ORADATA TEST DATA UNDOTBS01.DBF & # 39; in & # 39; D: ORADATA TESTDG DATA UNDOTBS01.DBF & # 39 ;; Set a brand new title for the info file & # 39; D: ORADATA TEST DATA SYSAUX01.DBF & # 39; в &#39;D: ORADATA TESTDG DATA SYSAUX01.DBF&#39;; установите новое имя для файла данных &#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.

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

poplus2

Tips on how to Configure Knowledge Guard Utilizing a Bodily Standby Database

No comments:

Post a Comment

Contact Us