В этой статье в основном рассказывается, как завершить процесс трансплантации системы приложений PHP на базе DB2 с платформы AIX на платформу Linux. В статье подробно описаны этапы трансплантации базовой базы данных DB2 и системы приложений PHP верхнего уровня, а также проблемы и решения, с которыми можно столкнуться в процессе трансплантации.
Обзор задачи
Работа по миграции системы в основном разделена на следующие аспекты:
1. Межплатформенная миграция системы баз данных DB2
. 2. Установка и настройка сервера Apache и системы приложений PHP.
Ниже мы представим конкретные этапы миграции и настройки в двух аспектах. .
Межплатформенная миграция системы баз данных DB2
Среда базы данных
Исходная среда: AIX+DB2 v8.1
Целевая среда: Linux+DB2 v8.1
Исходная база данных содержит 2 экземпляра базы данных: SRCDB1 и SRCDB2. База данных SRCDB1/SRCDB2 содержит сотни таблиц базы данных и имеет множество индексов, ограничений внешнего ключа, триггеров, хранимых процедур и некоторых таблиц с полями с автоматическим приращением (таблицы с полями, определенными GENERATED ALWAYS AS IDENTITY). Ситуация еще более усложняется тем, что у нас нет точных сценариев создания этих объектов базы данных.
Выбор плана миграции.
Если исходная система и целевая система, подлежащая миграции, относятся к одному и тому же типу операционной системы, например миграция между Linux или миграция между системами AIX, то ситуация относительно проста, и сама DB2 предоставляет соответствующие практические инструменты для достижения этой цели. Миграция базы данных между платформами одного типа, например команды BACKUP и RESTORE. Конечно, в зависимости от ситуации вам необходимо иметь четкое представление о параметрах, предоставляемых утилитой. Например, если исходная система и целевая система используют разные табличные пространства, возникнет проблема перенаправления табличного пространства. Поскольку в этой статье основное внимание уделяется кросс-платформенной трансплантации, это решение, очевидно, не может удовлетворить потребности и не будет обсуждаться здесь.
Итак, как решить проблемы межплатформенной миграции баз данных? Можно ли использовать утилиту db2move? db2move может переносить только данные в таблицах, но не может переносить объекты базы данных, такие как индексы, ограничения внешнего ключа, триггеры и хранимые процедуры. Кроме того, db2move также имеет определенные ограничения для таблиц, содержащих данные полей с автоинкрементом. А db2move может импортировать данные только в существующие таблицы базы данных и не может отображать расположение указанного табличного пространства. Поскольку в процессе миграции системы базы данных необходимо перенести не только данные в таблицах, но и объекты базы данных, такие как индексы, ограничения внешнего ключа, триггеры и хранимые процедуры. По сравнению с решением, выбранным в этой статье, последнее имеет смысл. больше преимуществ. Вы можете использовать db2move только как альтернативу перенастройке данных таблицы.
Для экспорта и импорта вы можете экспортировать и импортировать только одну таблицу за раз, и вам необходимо вручную вводить команды экспорта и импорта, а также имя таблицы данных, которая будет импортироваться и экспортироваться. Если количество таблиц базы данных невелико. , этот вариант еще можно рассмотреть, но это не лучший вариант. В случае большого количества таблиц в базе данных такой подход в принципе нереален, и команда импорта не гарантирует, что данные автоинкрементных полей будут соответствовать исходным данным таблицы.
В этой статье, основанной на механизме обработки объектов базы данных DB2, используется метод, который сочетает db2look со сценариями DDL и DML и отдельно обрабатывает триггеры, хранимые процедуры и ограничения внешнего ключа в исходной базе данных, чтобы обеспечить кроссплатформенность DB2. миграция системы баз данных.
Давайте возьмем SRCDB1 в качестве примера, чтобы представить общий процесс миграции базы данных в этом случае. В базе данных SRCDB1 имеется четыре режима базы данных: SRCDB1, ASN, DB2DBG и SQLDBA. Предположим, что имя пользователя базы данных SRCDB1 — user_srcdb1, а пароль — pw_srcdb1.
Связанные операции в исходной системе (AIX)
1. Используйте команду db2look для извлечения списка сценариев DDL, генерирующих объекты базы данных
. 1. Команда и параметры db2look
# db2look -d SRCDB1 -e -o srcdb1.ddl -a -i user_srcdb1 -w pw_srcdb1
db2look: Сгенерировать DDL для повторного создания объектов определено в базе данных
. Синтаксис: db2look -d Имя базы данных [-e] [-u Создатель] [-z Схема]
[-t Имя T1 Tимя2...TnameN] [-tw Tname] [-h] [-o Fname] [- a]
[- m] [-c] [-r] [-l] [-x] [-xd] [-f] [-fd] [-td x]
[-noview] [-i userID] [- w пароль]
[ -v Vname1 Vname2 ... VnameN] [-wrapper WrapperName]
[-server ServerName] [-nofed]
-d: имя базы данных, обязательный параметр
-e: извлечь файл DDL, необходимый для репликации базы данных, этот параметр сгенерирует файл DDL, содержащий сценарий для операторов
-o : Перенаправить вывод в заданное имя файла. Если опция -o не указана, вывод по умолчанию будет стандартным выводом
-a : Генерировать статистику для всех созданных программ, если этот параметр указан, он будет игнорироваться -u опция
-i: Укажите идентификатор пользователя, используемый для входа на сервер, на котором расположена база данных
-w: Укажите пароль, используемый для входа на сервер, на котором расположена база данных
2. Дифференцируйте сценарии DDL объектов базы данных в соответствии с различными типами объектов.
Поскольку данные каждой таблицы в исходной базе данных обрабатываются объектами базы данных, такими как триггеры и хранимые процедуры, чтобы обеспечить согласованность и целостность данных в базе данных, эта база данных. объекты следует создавать после импорта данных, чтобы предотвратить повторное выполнение объектов базы данных, таких как триггеры и хранимые процедуры, для генерации ошибочных данных при импорте данных таблицы. Используйте текстовый редактор для редактирования файла srcdb1.ddl, созданного db2look, разделите операторы DDL, которые создают таблицы и индексы, ограничения внешнего ключа, а также триггеры и хранимые процедуры, на четыре группы и сохраните их как следующие четыре сценария DDL:
srcdb1_tables.ddl srcdb1_foriegnkeys.ddl
srcdb1_triggers.ddl srcdb1_procedures.ddl
srcdb1_tables.ddl: Содержит операторы ddl для создания SEQUENCE, UDF, TABLE, VIEW и других объектов базы данных.
Листинг 2. Инструкция srcdb1_tables.ddl
CREATE SEQUENCE "SRCDB1"."SAMPLE_SEQ_1" AS INTEGER
MINVALUE 1 MAXVALUE 9999999999
START With 1 INCREMENT BY 1;
CREATE FUNCTION " SRCDB1"." SAMPLE _FUNC_1" (
VARCHAR(254),
VARCHAR(25) 4) ,
VARCHAR(254)
) ВОЗВРАЩАЕТ VARCHAR(254)
ОПРЕДЕЛЕННЫЙ ПРИМЕР _FUNC_1 ……;
CREATE
TABLE " SRCDB1"." SAMPLE _TAB_1" (
"TAB_COL1" CHAR(20) NOT NULL ,
"TAB_COL2" VARCHAR(70) NOT NULL ) ;
TABLE " SRCDB1"." SAMPLE _TAB_2" (…);
CREATE
TABLE " SRCDB1"." SAMPLE _TAB_N" (…);
CREATE VIEW SRCDB1.SAMPLE_VIEW_1 (VIEW_COL1,VIEW_COL2) КАК ВЫБРАТЬ отдельные
COL1, COL2 ИЗ SAMPLE_TAB WHERE … …;
CREATE VIEW SRCDB1.SAMPLE_VIEW_2 …;
…
CREATE VIEW SRCDB1.SAMPLE_VIEW_N …;
srcdb1_foriegnkeys.ddl: Содержит оператор ddl для создания ограничений внешнего ключа.
Листинг 3. Инструкция srcdb1_foriegnkeys.ddl
ALTER TABLE " SRCDB1"."SAMPLE_FK_1"
ADD CONSTRAINT "SQL030903143850120" FOREIGN KEY
("FK_COL1")
REFERENCES " SRCDB1"."SAMPLE_TABLE"
("COL1")
; LE_FK_2 " ADD ……;
……
ALTER TABLE " SRCDB1"."SAMPLE_FK_N" ADD ……;
srcdb1_triggers.ddl: Содержит операторы ddl для создания триггеров.
Листинг 4. Инструкция srcdb1_triggers.ddl
CREATE TRIGGER SRCDB1.SAMPLE_TRIG_1 AFTER UPDATE OF col1 ON SRCDB1.SAMPLE_TAB
ССЫЛКА НА НОВЫЙ КАК n ДЛЯ КАЖДОГО РЕЖИМА СТРОК DB2SQL WHEN ( n.col1 > 3)
BEGIN ATOMIC
update SAMPLE_TAB
set(col2) = 'anotherValue' где col1 = n.col1 ;--
END;
CREATE TRIGGER SRCDB1 …
…
CREATE TRIGGER. SRCDB1.SAMPLE_TRIG_N…;
srcdb1_procedures.ddl: Содержит операторы ddl для создания хранимых процедур SQL и хранимых процедур Java.
Листинг 5. Инструкция srcdb1_procedures.ddl
CREATE PROCEDURE " SRCDB1"." JAVA_PROCEDURE_1" (
OUT SQLSTATE CHARACTER(5),
OUT ROWS_SUBMITED INTEGER,
IN BATCH_ID INTEGER,
IN LEVEL VARCHAR(4000)
)
DYNAMIC RESULT SETS 0
SPECIFIC SUBMIT_BATCH
EX TERN AL NAME 'Submit_batch ! submit_batch'
ЯЗЫКСТИЛЬ ПАРАМЕТРОВ
JAVA
JAVAНЕ ДЕТЕРМИНИРОВАННЫЙ
ОГРАНИЧЕННЫЙ ПОТОКОВЫЙ ИЗМЕНЯЕТ
ДАННЫЕ SQL
НЕТ
DBINFO;
CREATE
PROCEDURE " SRCDB1"."JAVA_PROCEDURE_2" ……;
КОНКРЕТНЫЙ
SRCDB1
.SQL_PROCEDURE_1
ЯЗЫК SQL
--------------------------------------- -------- ---
-- Хранимая процедура SQL
---------------------------------- ----------- -------
P1: BEGIN
……
END P1 ;
CREATE PROCEDURE SRCDB1.SQL_PROCEDURE_2 ……
……
CREATE PROCEDURE SRCDB1.SQL_PROCEDURE_N ……
; Версия db2 v6 db2look еще не реализовала извлечение, такое как UDF, TRIGGER, UserSpace, NodeGroup, BufferPool и другие операторы ddl объектов базы данных. Начиная с db2 v7, db2look может извлекать DDL вышеупомянутых объектов, но по-прежнему не может извлечь оператор ddl, создающий объект хранимой процедуры. Начиная с db2 v8.2, улучшена поддержка функции db2look и реализована функция извлечения операторов ddl хранимой процедуры. Поскольку исходная система базы данных, рассматриваемая в этой статье, имеет более раннюю версию (DB2 v8.1), необходимо использовать приведенное выше решение для получения информации DDL всех объектов базы данных:
1). Из системы DB2 v8.2 в SRCDB1. (версия DB2 v8.1) выполните операцию КАТАЛОГ:
Каталог db2 db SRCDB1 как SRCDB1
2) Выполните процесс извлечения db2look на SRCDB1 из системы DB2 v8.2:
db2look -d SRCDB1 -e -o srcdb1.ddl -a -i user_srcdb1 -w pw_srcdb1
Таким образом вы можете получить полную информацию
;Информация об объекте базы данных DDL.
3． Создание сценария экспорта данных.
Используйте сценарий оболочки, чтобы сгенерировать и экспортировать сценарий DML для всех данных и перенаправить его в файл srcdb1_export.sql. Пользователи, знакомые с DB2, должны знать, что каждая таблица, представление и псевдоним, созданные в базе данных, соответствуют строке записей в SYSCAT.TABLES. Таким образом, всю необходимую информацию о таблицах базы данных можно получить с помощью соответствующего оператора выбора базы данных. При необходимости следующий сценарий оболочки выберет имена всех таблиц схемы вкладок в SRCDB1, то есть SRCDB1, ASN, SQLDBA и DB2DBG, на основе поля имени вкладки из системной таблицы SYSCAT.TABLES, и создаст соответствующие операторы экспорта на основе их имен. . Достижение цели пакетного экспорта. Функция rtrim используется для удаления пробелов в правой части данных поля имени вкладки.
Листинг 6. Создание сценария экспорта
# db2 "select 'export to ' rtrim(tabname) '.ixf of ixf select * from '
rtrim(tabname) ';' from syscat.tables,
где tabschema in('SRCDB1', 'ASN', 'SQLDBA', 'DB2DBG')" > srcdb1_export.sql;
Отредактируйте созданный srcdb1_export.sql, удалите статистическую информацию, отображаемую в заголовке и хвосте, и сохраните только необходимые операторы экспорта. Изменяя информацию о схеме вкладок, содержащуюся в приведенном выше сценарии, вы можете указать диапазон таблиц, которые необходимо экспортировать, то есть все имена таблиц, необходимые в процессе миграции. Сгенерированный оператор экспорта экспорта имеет следующую командную форму:
экспорт db2 в имя_таблицы.ixf из ixf select * from имя_таблицы
4; Создание сценария загрузки импорта данных.
Используйте сценарий оболочки для создания сценария загрузки для импорта данных в целевую систему: srcdb1_load.sql
Листинг 7. Создание сценария загрузки
# db2 "select 'load from ' rtrim(tabname) '.ixf из ixf, вставьте в '
rtrim( tabname) ';' из syscat.tables
, где tabschema in ('SRCDB1', 'ASN', 'SQLDBA', 'DB2DBG')" > srcdb1_load.sql;
Отредактируйте сгенерированный srcdb1_load.sql и удалите начальную и хвостовую статистику. , сохраняйте только необходимые операторы нагрузки. Подобно оператору экспорта, приведенный выше сценарий оболочки выбирает имена всех таблиц в SRCDB1 из системной таблицы и генерирует соответствующие операторы импорта на основе их имен для достижения цели пакетного импорта. Сгенерированная форма команды импорта импорта выглядит следующим образом:
загрузка db2 из tablename.ixf из ixf, вставка в tablename;