Проучваме мигрирането на база данни на Oracle от екземпляр EC2 към RDS за управлявана услуга. В първата от четирите статии, „Мигриране на база данни на Oracle от AWS EC2 към AWS RDS, част 1“, създадохме екземпляри на база данни на EC2 и RDS. Във втората статия, „Мигриране на база данни на Oracle от AWS EC2 към AWS RDS, част 2“, създадохме IAM потребител за миграция на база данни и също така създадохме таблица на база данни за мигриране. Само във втората статия създадохме екземпляр на репликация и крайни точки на репликация. В третата статия, „Мигриране на база данни на Oracle от AWS EC2 към AWS RDS, част 3“, създадохме задача за мигриране за мигриране на съществуващи промени. В тази статия-продължение ще мигрираме текущите промени в данните. Тази статия има следните раздели:
- Създаване и изпълнение на задача за репликация за мигриране на текущи промени
- Добавяне на допълнително регистриране
- Добавяне на таблица към екземпляр на база данни на Oracle на EC2
- Добавяне на таблични данни
- Проучване на таблицата с реплицирани бази данни
- Изпускане и презареждане на данни
- Спиране и стартиране на задача
- Изтриване на бази данни
- Заключение
Създаване и изпълнение на задача за репликация за мигриране на текущи промени
В следващите подраздели ще създадем задача за възпроизвеждане на текущи промени. За да демонстрираме текущата репликация, първо ще стартираме задачата и впоследствие ще създадем таблица и ще добавим данни. Изхвърлете таблицата DVOHRA.WLSLOG , както е показано на фигура 1; ще създадем същата таблица, за да демонстрираме текущата репликация.
Фигура 1: Отпадаща таблица DVOHRA.WLSLOG
Добавяне на допълнително регистриране
Услуга за мигриране на бази данни изисква допълнителното регистриране да бъде активирано, за да се даде възможност за събиране на данни за промени (CDC), което се използва за репликиране на текущи промени. Допълнителното регистриране е процесът на съхраняване на информация за това кои редове данни в таблицата са се променили. Допълнителното регистриране добавя допълнителни или допълнителни данни за колони в регистрационните файлове за повторно изпълнение всеки път, когато се извършва актуализация на таблица. Колоните, които са се променили, се записват като допълнителни данни в регистрационни файлове за повторно изпълнение заедно с идентификационен ключ, който може да бъде първичен ключ или уникален индекс. Ако дадена таблица няма първичен ключ или уникален индекс, всички скаларни колони се записват в регистрационните файлове за повторно изпълнение, за да се идентифицира уникално ред данни, което може да направи регистрационните файлове за повторно изпълнение големи по размер. Oracle Database поддържа следните видове допълнително регистриране:
- Минимално допълнително регистриране: Само минималното количество данни, което се изисква от LogMiner за промените в DML, се записва в регистрационни файлове за повторно изпълнение.
- Регистриране на ключове за идентификация на ниво база данни: Поддържат се различни видове регистриране на ключове за идентификация на ниво база данни—ВСИЧКИ, ПЪРВИЧЕН КЛЮЧ, УНИКАЛЕН и ВЪНШЕН КЛЮЧ. При ниво ALL всички колони (с изключение на LOBs, Longs и ADT) се записват в регистрационни файлове за повторно изпълнение. За ПЪРВИЧЕН КЛЮЧ само колоните с първичен ключ се съхраняват в регистрационни файлове за повторно изпълнение, когато се актуализира ред, съдържащ първичен ключ; не се изисква колона с първичен ключ да се актуализира. Видът ВЪНШЕН КЛЮЧ съхранява само външните ключове на ред в регистрационни файлове за повторно изпълнение, когато някой от червените регистрационни файлове се актуализира. Видът UNIQUE съхранява само колоните в уникален съставен ключ или индекс на растерна карта, когато която и да е колона в уникалния съставен ключ или растерен индекс се е променила.
- Допълнително регистриране на ниво таблица: Указва на ниво таблица кои колони се съхраняват в регистрационни файлове за повторно изпълнение. Регистрирането на идентификационни ключове на ниво таблица поддържа същите нива, както при регистрирането на идентификационни ключове на ниво база данни; ВСИЧКИ, ПЪРВИЧЕН КЛЮЧ, УНИКАЛЕН И ВЪНШЕН КЛЮЧ. На ниво таблица също се поддържат дефинирани от потребителя допълнителни регистрационни групи, които позволяват на потребителя да дефинира кои колони да бъдат допълнително регистрирани. Дефинираните от потребителя допълнителни регистрационни групи могат да бъдат условни или безусловни.
За текуща репликация трябва да зададем минимално допълнително регистриране и допълнително регистриране на ниво таблица за ВСИЧКИ колони.
В SQL*Plus изпълнете следния оператор, за да зададете минимално допълнително регистриране:
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
Резултатът е както следва:
SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; Database altered.
За да намерите състоянието на минималното допълнително регистриране, изпълнете следния оператор. И ако изходът има стойност на колона SUPPLEME като ДА, минимално допълнително регистриране е разрешено.
SQL> SELECT supplemental_log_data_min FROM v$database; SUPPLEME -------- YES
Задаването на минимално допълнително регистриране и проверка на състоянието е показано на Фигура 2.
Фигура 2: Задаване и проверка на минимално допълнително регистриране
Ние също така ще зададем регистриране на ключ за идентификация на ниво таблица, когато добавяме данни от таблица и таблица, за да демонстрираме текуща репликация след стартиране на задачата. Ако добавим данни от таблици и таблици, преди да създадем и стартираме задача – няма да можем да демонстрираме текущо репликация.
За да създадете задача за текуща репликация, щракнете върху Създаване на задача , както е показано на фигура 3.
Фигура 3: Задачи>Създаване на задача
В Създаване на задача съветника, посочете име и описание на задачата и изберете екземпляр на репликация, изходна крайна точка и целева крайна точка, както е показано на фигура 4. Изберете Тип миграция като Мигриране на съществуващи данни и копиране на текущи промени .
Фигура 4: Избор на тип миграция за текуща репликация
Съобщение, показано на фигура 5, показва, че е необходимо да се активира допълнително регистриране за текуща репликация. Съобщението не означава, че допълнителното регистриране не е активирано, а само като напомняне. Вече сме активирали допълнително регистриране. Поставете отметка в квадратчето Стартиране на задачата при създаване .
Фигура 5: Съобщение за допълнително изискване за регистриране за възпроизвеждане на текущи промени
Настройки на задачата са същите като при мигриране само на съществуващи данни (вижте фигура 6).
Фигура 6: Настройки на задачите
За съпоставяния на таблици е необходимо поне едно правило за избор. Добавете правило за избор, за да включите всички таблици в DVOHRA таблица, както е показано на фигура 7.
Фигура 7: Добавяне на правило за избор
Добавеното правило за избор е показано на фигура 8.
Фигура 8: Правило за избор
Кликнете върху Създаване на задача за да създадете задачата, както е показано на фигура 9.
Фигура 9: Създайте задача
Добавя се нова задача със състояние Създаване , както е показано на Фигура 10.
Фигура 10: Добавена задача със състояние Създаване
Когато се прилагат правилата за избор и трансформация за всички съществуващи данни и данните се мигрират, състоянието на задачата става Зареждането завършено, репликацията продължава (вижте Фигура 11).
Фигура 11: Зареждането завърши, репликацията е в ход
Статистика на таблицата tab не изброява таблици като мигрирани или репликирани, както е показано на Фигура 12.
Фигура 12: Статистика на таблицата
За да разгледате регистрационните файлове на CloudWatch, щракнете върху Журнали раздел и щракнете върху връзката, както е показано на фигура 13.
Фигура 13: Дневници
Регистрите на CloudWatch се показват, както е показано на Фигура 14. Последният запис в регистрационните файлове е за стартиране на репликация. Текущата задача за репликация не се прекратява след зареждане на съществуващи данни, ако има такива, а продължава да се изпълнява.
Фигура 14: Регистрационни файлове на CloudWatch
Добавяне на таблица към екземпляр на база данни на Oracle на EC2
След това създайте таблица и добавете данни от таблицата, за да демонстрирате текуща репликация. Изпълнете следните два оператора заедно, така че допълнителното регистриране на ниво таблица да бъде зададено, когато таблицата е създадена. Променете скрипта, за да направите схемата различна.
CREATE TABLE DVOHRA.wlslog(time_stamp VARCHAR2(255) PRIMARY KEY, category VARCHAR2(255),type VARCHAR2(255),servername VARCHAR2(255),code VARCHAR2(255),msg VARCHAR2(255)); alter table DVOHRA.WLSLOG add supplemental log data (ALL) columns;
Допълнителното регистриране на ниво таблица се задава при създаването на таблицата.
SQL> CREATE TABLE DVOHRA.wlslog(time_stamp VARCHAR2(255) PRIMARY KEY,category VARCHAR2(255),type VARCHAR2(255),servername VARCHAR2(255),code VARCHAR2(255),msg VARCHAR2(255)); alter table DVOHRA.WLSLOG add supplemental log data (ALL) columns; Table created. SQL> Table altered.
Резултатът е показан в SQL*Plus на Фигура 15.
Фигура 15: Създаване на таблица и настройка на допълнително регистриране
Засега ние само създадохме таблицата и не добавихме никакви таблични данни. DDL за таблицата се мигрира, както е показано от статистическите данни на таблицата на фигура 16.
Фигура 16: DDL за мигрирана таблица
Добавяне на таблични данни
След това изпълнете следния SQL скрипт, за да добавите данни към създадената таблица. Променете скрипта, за да направите схемата различна.
SQL> INSERT INTO DVOHRA.wlslog(time_stamp,category,type,
servername,code,msg) VALUES('Apr-8-2014-7:06:16-PM-PDT',
'Notice','WebLogicServer','AdminServer','BEA-000365','Server
state changed to STANDBY');
INSERT INTO DVOHRA.wlslog(time_stamp,category,type,servername,
code,msg) VALUES('Apr-8-2014-7:06:17-PM-PDT','Notice',
'WebLogicServer','AdminServer','BEA-000365','Server state
changed to STARTING');
INSERT INTO DVOHRA.wlslog(time_stamp,category,type,servername,
code,msg) VALUES('Apr-8-2014-7:06:18-PM-PDT','Notice',
'WebLogicServer','AdminServer','BEA-000365','Server state
changed to ADMIN');
INSERT INTO DVOHRA.wlslog(time_stamp,category,type,servername,code,
msg) VALUES('Apr-8-2014-7:06:19-PM-PDT','Notice',
'WebLogicServer','AdminServer','BEA-000365','Server state
changed to RESUMING');
INSERT INTO DVOHRA.wlslog(time_stamp,category,type,servername,code,
msg) VALUES('Apr-8-2014-7:06:20-PM-PDT','Notice',
'WebLogicServer','AdminServer','BEA-000361','Started WebLogic
AdminServer');
INSERT INTO DVOHRA.wlslog(time_stamp,category,type,servername,code,
msg) VALUES('Apr-8-2014-7:06:21-PM-PDT','Notice',
'WebLogicServer','AdminServer','BEA-000365','Server state
changed to RUNNING');
1 row created.
SQL>
1 row created.
SQL>
1 row created.
SQL>
1 row created.
SQL>
1 row created.
SQL>
1 row created.
След това изпълнете оператора Commit.
SQL> COMMIT; Commit complete.
Проучване на таблицата с реплицирани бази данни
Статистиката на таблицата изброява вмъквания като броя на добавените редове данни, както е показано на фигура 17.
Фигура 17: Таблица със статистически списък 6 вмъквания
Задачата продължава да се изпълнява след репликиране на текущи промени. Добавете още един ред данни.
SQL> INSERT INTO DVOHRA.wlslog(time_stamp,category,type,
servername,code,msg) VALUES('Apr-8-2014-7:06:22-PM-PDT',
'Notice','WebLogicServer','AdminServer','BEA-000360','Server
started in RUNNING mode');
1 row created.
SQL> COMMIT;
Commit complete.
SQL>
Кликнете върху Опресняване на данните от сървъра, както е показано на Фигура 18.
Фигура 18: Обновете данните от сървъра
Общият брой на вмъкванията в статистиката на таблица става 7, както е показано на фигура 19.
Фигура 19: Статистика на таблицата с вмъквания като 7
Изпускане и презареждане на данни
За да пуснете и презаредите табличните данни, щракнете върху Пускане и презареждане на таблични данни , както е показано на Фигура 20.
Фигура 20: Пуснете и презаредете данните на таблицата
Щракнете върху Опресняване на данните от сървъра (вижте Фигура 21).
Фигура 21: Обновете данните от сървъра
Иконата и Състояние колона за таблицата показва, че таблицата се презарежда, както е показано на Фигура 22.
Фигура 22: Таблицата се презарежда
Когато презареждането на таблицата приключи, колоната за състояние на таблицата става Таблицата е завършена , както е показано на фигура 23. След презареждане на данните от таблицата, Пълно зареждане на редове показва стойност 7, а Inserts е 0, тъй като презареждането не е текуща репликация, а пълно натоварване.
Фигура 23: Презареждането на таблицата приключи
Тъй като данните от таблицата се изпускат и презареждат и данните от таблицата източник не са се променили, регистрационните файлове на CloudWatch включват съобщение „Някои промени от изходната база данни не оказаха влияние, когато се прилагат към целевата база данни.“, както е показано на Фигура 24.
Фигура 24: Някои промени от изходната база данни не оказаха влияние, когато бяха приложени към целевата база данни
При презареждане на DVOHRA.wlslog таблицата приключи, съобщението „Зареждането приключи за таблица DVOHRA.wlslog. 7 реда получени“ се показва, както е показано на Фигура 25.
Фигура 25: CloudWatch log Съобщението за зареждане е завършено
Спиране и стартиране на задача
Задача от типа, която включва текуща репликация, не спира сама, освен ако не възникне грешка. За да спрете задачата, щракнете върху Стоп (вижте Фигура 26).
Фигура 26: Спиране на задача
В Спиране на задача диалогов прозорец, щракнете върху Стоп , както е показано на Фигура 27.
Фигура 27: Диалогов прозорец за потвърждение за спиране на задача
Състоянието на задачата става Спиране , както е показано на Фигура 28.
Фигура 28: Спиране на задача
Когато дадена задача спре, състоянието става Спр. , както е показано на Фигура 29.
Фигура 29: Задачата е спряна
За да стартирате спряна задача, щракнете върху Старт/Възобновяване , както е показано на Фигура 30.
Фигура 30: Стартиране или възобновяване на задача
В Стартиране на задача диалогов прозорец, щракнете върху Старт за да стартирате задачата от спряната точка (вижте Фигура 31). Другата опция е да рестартирате задачата.
Фигура 31: Стартиране на задача след спиране
Състоянието на задачата става Стартиране , както е показано на Фигура 32.
Фигура 32: Стартиране на задача
Когато миграцията на съществуващи данни приключи, задачата продължава да се изпълнява със състояние Зареждането завършено, репликацията продължава , както е показано на Фигура 33.
Фигура 33: Зареждането завърши, репликацията е в ход
Изтриване на бази данни
Инстанцията на RDS DB може да бъде изтрита с Действия на екземпляра>Изтриване команда. Базата данни на Oracle на екземпляра EC2 може да бъде спряна с Действия>Състояние на екземпляра>Стоп , както е показано на Фигура 34.
Фигура 34: Спиране на EC2 екземпляр
Заключение
В четири статии обсъдихме мигрирането на база данни на Oracle от AWS EC2 към AWS RDS.
