Este artículo presenta principalmente cómo completar el proceso de trasplante del sistema de aplicación PHP basado en DB2 de la plataforma AIX a la plataforma Linux. El artículo contiene los pasos detallados para trasplantar la base de datos DB2 subyacente y el sistema de aplicación PHP de capa superior, así como los problemas y soluciones que pueden surgir durante el proceso de trasplantación.
Descripción general de la tarea
El trabajo de migración del sistema se divide principalmente en los siguientes aspectos:
1. Migración multiplataforma del sistema de base de datos DB2
2. Instalación y configuración del servidor Apache y el sistema de aplicación PHP
A continuación, presentaremos los pasos específicos de la migración y configuración en dos aspectos. .
Migración multiplataforma del sistema
de base de datos DB2 Entorno de
base de datosEntorno de origen: AIX+DB2 v8.1
Entorno de destino: Linux+DB2 v8.1
La base de datos de origen contiene 2 instancias de base de datos: SRCDB1 y SRCDB2. La base de datos SRCDB1/SRCDB2 contiene cientos de tablas de bases de datos y tiene muchos índices, restricciones de clave externa, activadores, procedimientos almacenados y algunas tablas con campos de incremento automático (tablas con campos definidos GENERADOS SIEMPRE COMO IDENTIDAD). Para complicar aún más las cosas, no contamos con scripts de creación precisos para estos objetos de base de datos.
Selección del plan de migración
Si el sistema de origen y el sistema de destino a migrar pertenecen al mismo tipo de sistema operativo, como la migración entre Linux o la migración entre sistemas AIX, la situación es relativamente simple, el propio DB2 ha proporcionado herramientas prácticas relevantes para lograrlo. Migración de bases de datos entre plataformas del mismo tipo, como comandos BACKUP y RESTORE. Por supuesto, dependiendo de la situación, es necesario tener una comprensión clara de los parámetros proporcionados por la herramienta de utilidad. Por ejemplo, si el sistema de origen y el sistema de destino utilizan diferentes espacios de tabla, estará involucrado el problema de la redirección del espacio de tabla. Dado que este artículo se centra en el trasplante multiplataforma, esta solución obviamente no puede satisfacer las necesidades y no se discutirá aquí.
Entonces, ¿cómo abordar los problemas de migración de bases de datos multiplataforma? ¿Es posible utilizar la utilidad db2move? db2move sólo puede migrar datos en tablas, pero no puede migrar objetos de bases de datos como índices, restricciones de clave externa, activadores y procedimientos almacenados. Además, db2move también tiene ciertas limitaciones para tablas que contienen datos de campos de incremento automático. Y db2move sólo puede importar datos a tablas de bases de datos existentes y no puede mostrar la ubicación del espacio de tablas especificado. Dado que durante el proceso de migración del sistema de base de datos, no solo es necesario migrar los datos de las tablas, sino también los objetos de la base de datos, como índices, restricciones de clave externa, activadores y procedimientos almacenados, esta última tiene la solución seleccionada en este artículo. más ventajas. Puede utilizar db2move sólo como alternativa a la migración de datos de tablas.
Para exportar e importar, solo puede exportar e importar una tabla a la vez, y debe ingresar manualmente los comandos de exportación e importación y el nombre de la tabla de datos que se importará y exportará cuando la cantidad de tablas de la base de datos no sea grande. , esta opción aún puede considerarse, pero no es la mejor opción. En el caso de una gran cantidad de tablas en la base de datos, este método es básicamente poco realista y el comando de importación no garantiza que los datos de los campos incrementados automáticamente sean consistentes con los datos de la tabla original.
Basado en el mecanismo de procesamiento de objetos de base de datos de DB2, este artículo utiliza un método que combina db2look con scripts DDL y DML y maneja por separado desencadenadores, procedimientos almacenados y restricciones de clave externa en la base de datos original para proporcionar un DB2 multiplataforma. Migración del sistema de base de datos.
Tomemos SRCDB1 como ejemplo para presentar el proceso general de migración de la base de datos en este caso. Hay cuatro modos de base de datos: SRCDB1, ASN, DB2DBG y SQLDBA en la base de datos SRCDB1. Supongamos que el nombre de usuario de la base de datos SRCDB1 es user_srcdb1 y la contraseña es pw_srcdb1.
Operaciones relacionadas en el sistema fuente (AIX)
1. Utilice el comando db2look para extraer la lista de secuencias de comandos DDL que genera objetos de base de datos
1. Comando y parámetros de db2look
# db2look -d SRCDB1 -e -o srcdb1.ddl -a -i user_srcdb1 -w pw_srcdb1
db2look: Generar DDL para recrear los objetos definido en la base de datos
Sintaxis: db2look -d DBname [-e] [-u Creator] [-z Schema]
[-t Tname1 Tname2...TnameN] [-tw Tname] [-h] [-o Fname] [- a]
[- m] [-c] [-r] [-l] [-x] [-xd] [-f] [-fd] [-td x]
[-noview] [-i ID de usuario] [- w contraseña]
[ -v Vname1 Vname2 ... VnameN] [-wrapper WrapperName]
[-server ServerName] [-nofed]
-d: nombre de la base de datos, parámetro requerido
-e: extrae el archivo DDL requerido para replicar la base de datos, esta opción generará un archivo DDL que contiene script para declaraciones
-o: redirige la salida al nombre de archivo dado, si no se especifica la opción -o, la salida predeterminada es stdout
-a: genera estadísticas para todos los programas creados, si se especifica esta opción, se ignorará -u opción
-i: especifique la ID de usuario utilizada para iniciar sesión en el servidor donde se encuentra la base de datos
-w: especifique la contraseña utilizada para iniciar sesión en el servidor donde se encuentra la base de datos
2. Diferenciar los scripts DDL de objetos de bases de datos según los diferentes tipos de objetos.
Dado que los datos de cada tabla en la base de datos de origen han sido procesados por objetos de la base de datos, como activadores y procedimientos almacenados, para garantizar la coherencia e integridad de los datos en la base de datos. Los objetos deben crearse después de importar datos para evitar que la ejecución repetida de objetos de la base de datos, como activadores y procedimientos almacenados, generen datos erróneos al importar datos de tablas. Utilice un editor de texto para editar srcdb1.ddl generado por db2look, divida las declaraciones DDL que crean tablas e índices, crean restricciones de clave externa y crean desencadenadores y procedimientos almacenados en cuatro grupos, y guárdelos como los siguientes cuatro scripts DDL:
srcdb1_tables.ddl srcdb1_foriegnkeys.ddl
srcdb1_triggers.ddl srcdb1_procedures.ddl
srcdb1_tables.ddl: contiene declaraciones ddl para crear SEQUENCE, UDF, TABLE, VIEW y otros objetos de base de datos.
Listado 2. Sentencia srcdb1_tables.ddl
CREAR SECUENCIA "SRCDB1". "SAMPLE_SEQ_1" COMO INTEGER
MINVALUE 1 MAXVALUE 9999999999
COMENZAR CON 1 INCREMENTAR EN 1;
CREAR FUNCIÓN " SRCDB1"." SAMPLE _FUNC_1" (
VARCHAR(254),
VARCHAR(25 4) ,
VARCHAR(254)
) DEVUELVE VARCHAR(254)
MUESTRA ESPECÍFICA _FUNC_1 ……;
CREAR
TABLA " SRCDB1"." MUESTRA _TAB_1" (
"TAB_COL1" CHAR(20) NO NULL,
"TAB_COL2" VARCHAR(70) NO NULL);
TABLA " SRCDB1"." MUESTRA _TAB_2" (…);
…
CREAR TABLA " SRCDB1"." MUESTRA _TAB_N" (…);
CREAR VISTA SRCDB1.SAMPLE_VIEW_1 (VIEW_COL1,VIEW_COL2) COMO SELECCIONAR
COL1 distinto, COL2 DE SAMPLE_TAB DONDE… …;
CREAR VISTA SRCDB1.SAMPLE_VIEW_2……
CREARVISTA
SRCDB1.SAMPLE_VIEW_N…;
srcdb1_foriegnkeys.ddl: Contiene la declaración ddl para crear restricciones de clave externa.
Listado 3. Sentencia srcdb1_foriegnkeys.ddl
ALTER TABLE " SRCDB1". "SAMPLE_FK_1"
ADD CONSTRAINT "SQL030903143850120" FOREIGN KEY
("FK_COL1")
REFERENCIAS " SRCDB1". "SAMPLE_TABLE"
("COL1")
; LE_FK_2 " AGREGAR ……;
……
ALTER TABLE " SRCDB1". "SAMPLE_FK_N" AGREGAR ……;
srcdb1_triggers.ddl: Contiene declaraciones ddl para crear desencadenadores.
Listado 4. Sentencia srcdb1_triggers.ddl
CREAR DISPARADOR SRCDB1.SAMPLE_TRIG_1 DESPUÉS DE LA ACTUALIZACIÓN DE col1 EN SRCDB1.SAMPLE_TAB
REFERENCIAR NUEVO COMO n PARA CADA MODO DE FILA DB2SQL CUANDO (n.col1 > 3)
COMIENCE
LA actualización ATÓMICA SAMPLE_TAB
set(
col2) = 'otroValor'
donde col1 = n.col1;--
CREAR
DISPARADOR SRCDB1…;
SRCDB1. SAMPLE_TRIG_N…;
srcdb1_procedures.ddl: Contiene declaraciones ddl para crear procedimientos almacenados SQL y procedimientos almacenados Java.
Listado 5. Sentencia srcdb1_procedures.ddl
CREAR PROCEDIMIENTO " SRCDB1"." JAVA_PROCEDURE_1" (
OUT SQLSTATE CHARACTER(5),
OUT ROWS_SUBMITED INTEGER,
IN BATCH_ID INTEGER,
IN LEVEL VARCHAR(4000)
)
CONJUNTOS DE RESULTADOS DINÁMICOS 0
ESPECÍFICO SUBMIT_BATCH
NOMBRE EXTERNO 'Submit_batch ! submit_batch'
IDIOMA JAVA
PARÁMETRO ESTILO JAVA
NO DETERMINISTA
FENCED THREADSAFE
MODIFICA DATOS SQL
SIN
DBINFO
CREAR
PROCEDIMIENTO " SRCDB1". "JAVA_PROCEDURE_2" ……;
ESPECÍFICO
SRCDB1
.SQL_PROCEDURE_1
IDIOMA SQL
--------------------------------------- -------- ---
-- Procedimiento almacenado SQL
---------------------------------- ----------- -------
P1: COMENZAR
……
FINALIZAR P1 ;
CREAR PROCEDIMIENTO SRCDB1.SQL_PROCEDURE_2 ……
……
CREAR PROCEDIMIENTOSRCDB1.SQL_PROCEDURE_N
……;
La versión db2 v6 de db2look aún no ha implementado extracción como UDF, TRIGGER, UserSpace, NodeGroup, BufferPool y otras declaraciones ddl de objetos de base de datos. A partir de db2 v7, db2look puede extraer el DDL de los objetos anteriores, pero aún no puede extraer la declaración ddl que crea el objeto de procedimiento almacenado. A partir de db2 v8.2, se mejoró el soporte para la función db2look y se implementó la función de extracción de declaraciones ddl de procedimientos almacenados. Dado que el sistema de base de datos fuente involucrado en este artículo es de una versión inferior (DB2 v8.1), se debe adoptar la solución anterior para obtener la información DDL de todos los objetos de la base de datos:
1). (versión DB2 v8.1) realice la operación CATALOGO:
db2 cataloga db SRCDB1 como SRCDB1;
2). Realice el proceso de extracción de db2look en SRCDB1 desde el sistema DB2 v8.2:
db2look -d SRCDB1 -e -o srcdb1.ddl -a -i user_srcdb1 -w pw_srcdb1
; Base de datos Objeto Información DDL.
3． Generar script de exportación de exportación de datos
Utilice un script de shell para generar y exportar un script DML para todos los datos y redirigirlo al archivo srcdb1_export.sql. Los usuarios familiarizados con DB2 deben saber que cada tabla, vista y alias creados en la base de datos corresponde a una fila de registros en SYSCAT.TABLES. Por lo tanto, toda la información requerida de la tabla de la base de datos se puede obtener a través de la declaración de selección de la base de datos correspondiente. Según sea necesario, el siguiente script de shell seleccionará los nombres de las tablas de todas las tablas de esquema de pestañas en SRCDB1 que son SRCDB1, ASN, SQLDBA y DB2DBG según el campo de nombre de pestaña de la tabla del sistema SYSCAT.TABLES y generará las declaraciones de exportación correspondientes en función de sus nombres. Lograr el propósito de la exportación por lotes. La función rtrim se utiliza para eliminar los espacios en el lado derecho de los datos del campo de nombre de pestaña.
Listado 6. Generar script de exportación
# db2 "select 'export to ' rtrim(tabname) '.ixf of ixf select * from '
rtrim(tabname) ';' from syscat.tables
donde tabschema in('SRCDB1', 'ASN', 'SQLDBA', 'DB2DBG')" > srcdb1_export.sql;
edite el srcdb1_export.sql generado, elimine la información estadística que se muestra en el encabezado y la cola y conserve solo las declaraciones de exportación necesarias. Al modificar la información del esquema de pestañas contenida en el script anterior, puede especificar el rango de tablas que deben exportarse, es decir, todos los nombres de tablas necesarios durante el proceso de migración. La declaración de exportación generada tiene la siguiente forma de comando:
db2 export to tablename.ixf of ixf select * from tablename
4. Generar script de carga de importación de datos
Utilice el script de shell para generar un script de carga para importar datos al sistema de destino: srcdb1_load.sql
Listado 7. Generar script de carga
# db2 "select 'load from ' rtrim(tabname) '.ixf of ixf insert into '
rtrim( tabname) ';' de syscat.tables
donde tabschema in ('SRCDB1', 'ASN', 'SQLDBA', 'DB2DBG')" > srcdb1_load.sql;
Edite el srcdb1_load.sql generado y elimine las estadísticas de cabecera y cola. Sólo mantenga las declaraciones de carga necesarias. De manera similar a la declaración de exportación, el script de shell anterior selecciona los nombres de todas las tablas en SRCDB1 de la tabla del sistema y genera las declaraciones de importación correspondientes en función de sus nombres para lograr el propósito de la importación por lotes. El formato del comando de declaración de importación generado es el siguiente:
db2 carga desde tablename.ixf de ixf insert into tablename;