Este artigo apresenta principalmente como concluir o processo de transplante do sistema de aplicação PHP baseado em DB2 da plataforma AIX para a plataforma Linux. O artigo contém as etapas detalhadas de transplante do banco de dados DB2 subjacente e do sistema de aplicativos PHP da camada superior, bem como os problemas e soluções que podem ser encontrados durante o processo de transplante.
Visão geral da tarefa
O trabalho de migração do sistema é dividido principalmente nos seguintes aspectos:
1. Migração entre plataformas do sistema de banco de dados DB2
2. Instalação e configuração do servidor Apache e do sistema de aplicativos PHP
A seguir apresentaremos as etapas específicas de migração e configuração em dois aspectos. .
Migração entre plataformas do sistema de banco de dados DB2
Ambiente de banco de dados
Ambiente de origem: AIX+DB2 v8.1
Ambiente de destino: Linux+DB2 v8.1
O banco de dados de origem contém 2 Instâncias de banco de dados: SRCDB1 e SRCDB2. O banco de dados SRCDB1/SRCDB2 contém centenas de tabelas de banco de dados e possui muitos índices, restrições de chave estrangeira, gatilhos, procedimentos armazenados e algumas tabelas com campos de incremento automático (tabelas com campos definidos GENERATED ALWAYS AS IDENTITY). Para tornar as coisas ainda mais difíceis, não temos scripts de criação precisos para esses objetos de banco de dados.
Seleção do plano de migração
Se o sistema de origem e o sistema de destino a serem migrados pertencerem ao mesmo tipo de sistema operacional, como a migração entre Linux ou a migração entre sistemas AIX, a situação é relativamente simples, o próprio DB2 forneceu ferramentas práticas relevantes para conseguir isso. . Migração de banco de dados entre plataformas do mesmo tipo, como comandos BACKUP e RESTORE. Claro, dependendo da situação, você precisa ter uma compreensão clara dos parâmetros fornecidos pela ferramenta utilitária. Por exemplo, se o sistema de origem e o sistema de destino usarem espaços de tabela diferentes, o problema de redirecionamento do espaço de tabela estará envolvido. Como o foco deste artigo é o transplante multiplataforma, esta solução obviamente não pode atender às necessidades e não será discutida aqui.
Então, como lidar com problemas de migração de banco de dados entre plataformas? É possível usar o utilitário db2move? O db2move só pode migrar dados em tabelas, mas não pode migrar objetos de banco de dados, como índices, restrições de chave estrangeira, gatilhos e procedimentos armazenados. Além disso, o db2move também possui certas limitações para tabelas que contêm dados de campo de incremento automático. E o db2move só pode importar dados para tabelas de banco de dados existentes e não pode exibir a localização do espaço de tabela especificado. Como durante o processo de migração do sistema de banco de dados, não apenas os dados das tabelas precisam ser migrados, mas também os objetos do banco de dados, como índices, restrições de chave estrangeira, gatilhos e procedimentos armazenados. Em comparação com a solução selecionada neste artigo, esta última possui. mais vantagens. É possível usar o db2move apenas como uma alternativa à migração de dados da tabela.
Para exportar e importar, você só pode exportar e importar uma tabela por vez e precisará inserir manualmente os comandos de exportação e importação e o nome da tabela de dados a ser importada e exportada quando o número de tabelas do banco de dados não for grande. , esta opção ainda pode ser considerada, mas não é a melhor opção. No caso de um grande número de tabelas no banco de dados, essa abordagem é basicamente irrealista e o comando de importação não garante que os dados dos campos incrementados automaticamente sejam consistentes com os dados originais da tabela.
Com base no mecanismo de processamento do DB2 para objetos de banco de dados, este artigo usa um método que combina db2look com scripts DDL e DML e lida separadamente com gatilhos, procedimentos armazenados e restrições de chave estrangeira no banco de dados original para fornecer um DB2 multiplataforma. migração do sistema de banco de dados.
Tomemos o SRCDB1 como exemplo para apresentar o processo geral de migração do banco de dados neste caso. Existem quatro modos de banco de dados: SRCDB1, ASN, DB2DBG e SQLDBA no banco de dados SRCDB1. Suponha que o nome de usuário do banco de dados SRCDB1 seja user_srcdb1 e a senha seja pw_srcdb1.
Operações relacionadas no sistema de origem (AIX)
1. Use o comando db2look para extrair a lista de scripts DDL que gera objetos de banco de dados
1. Comando e parâmetros db2look
# db2look -d SRCDB1 -e -o srcdb1.ddl -a -i user_srcdb1 -w pw_srcdb1
db2look: Gere DDL para recriar os objetos definido no banco de dados
Sintaxe: 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 do usuário] [- w senha]
[ -v Vname1 Vname2 ... VnameN] [-wrapper WrapperName]
[-server ServerName] [-nofed]
-d: nome do banco de dados, parâmetro obrigatório
-e: extraia o arquivo DDL necessário para replicar o banco de dados, esta opção irá gerar um arquivo DDL contendo script para instruções
-o: Redireciona a saída para o nome de arquivo fornecido, se a opção -o não for especificada, a saída será padrão para stdout
-a: Gere estatísticas para todos os programas criados, se esta opção for especificada, ela será ignorado -u opção
-i: Especifique o ID do usuário usado para efetuar login no servidor onde o banco de dados está localizado
-w: Especifique a senha usada para efetuar login no servidor onde o banco de dados está localizado
2. Diferencie scripts DDL de objetos de banco de dados de acordo com diferentes tipos de objetos.
Como cada dado da tabela no banco de dados de origem foi processado por objetos de banco de dados, como gatilhos e procedimentos armazenados, a fim de garantir a consistência e integridade dos dados no banco de dados, esses bancos de dados. objetos devem ser criados após a importação de dados para evitar a execução repetida de objetos de banco de dados, como gatilhos e procedimentos armazenados, para gerar dados errados ao importar dados da tabela. Use um editor de texto para editar srcdb1.ddl gerado pelo db2look, divida as instruções DDL que criam tabelas e índices, crie restrições de chave estrangeira e crie gatilhos e procedimentos armazenados em quatro grupos e salve-os como os quatro scripts DDL a seguir:
srcdb1_tables.ddl srcdb1_foriegnkeys.ddl
srcdb1_triggers.ddl srcdb1_procedures.ddl
srcdb1_tables.ddl: Contém instruções ddl para criar SEQUENCE, UDF, TABLE, VIEW e outros objetos de banco de dados.
Listagem 2. Instrução 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)
) RETORNA VARCHAR(254)
AMOSTRA
ESPECÍFICA
_FUNC_1
……;
TABELA "SRCDB1"." AMOSTRA _TAB_2" (…);
CREATE
TABLE
" SRCDB1"." AMOSTRA _TAB_N" (…)
;
CREATE VIEW SRCDB1.SAMPLE_VIEW_2 …;
…
CREATE VIEW SRCDB1.SAMPLE_VIEW_N …;
srcdb1_foriegnkeys.ddl: Contém a instrução ddl para criar restrições de chave estrangeira.
Listagem 3. Instrução 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: Contém instruções ddl para criar gatilhos.
Listagem 4. Instrução srcdb1_triggers.ddl
CREATE TRIGGER SRCDB1.SAMPLE_TRIG_1 APÓS ATUALIZAÇÃO DE col1 ON SRCDB1.SAMPLE_TAB
REFERENCIANDO NOVO COMO n PARA CADA MODO DE LINHA DB2SQL WHEN (n.col1 > 3)
BEGIN
ATOMIC
update SAMPLE_TAB
set(col2) = 'anotherValue' onde col1 = n.col1 ;
--
END
;
SRCDB1.SAMPLE_TRIG_N…;
srcdb1_procedures.ddl: Contém instruções ddl para criar procedimentos armazenados SQL e procedimentos armazenados java.
Listagem 5. Instrução 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
EXTERN AL NAME 'Enviar _lote !submit_batch'
IDIOMA JAVA
ESTILO DE PARÂMETRO JAVA
NÃO DETERMINÍSTICO
FENCED THREADSAFE
MODIFICA
DADOS SQL
NO
DBINFO
"SRCDB1"."JAVA_PROCEDURE_2" ……;
SRCDB1
ESPECÍFICO
.SQL_PROCEDURE_1
LANGUAGE SQL
--------------------------------------- -------- ---
-- Procedimento armazenado SQL
---------------------------------- ----------- -------
P1: BEGIN
……
END P1 ;
CREATE
PROCEDURE
SRCDB1.SQL_PROCEDURE_2
……;
A versão db2 v6 do db2look ainda não implementou extração como UDF, TRIGGER, UserSpace, NodeGroup, BufferPool e outras instruções ddl de objetos de banco de dados. A partir do DB2 v7, o db2look pode extrair o DDL dos objetos acima, mas ainda não consegue extrair a instrução ddl que cria o objeto de procedimento armazenado. A partir do DB2 v8.2, o suporte para a função db2look foi aprimorado e a função de extração de instruções ddl do procedimento armazenado foi implementada. Como o sistema de banco de dados de origem envolvido neste artigo é de uma versão inferior (DB2 v8.1), a solução acima precisa ser adotada para obter as informações DDL de todos os objetos do banco de dados:
1). De um sistema DB2 v8.2 para SRCDB1). (versão DB2 v8.1) execute a operação CATALOG:
catálogo db2 db SRCDB1 como SRCDB1
2). Execute o processo de extração db2look no SRCDB1 do sistema DB2 v8.2:
db2look -d SRCDB1 -e -o srcdb1.ddl -a -i user_srcdb1 -w pw_srcdb1
; informações DDL do objeto do banco de dados.
3. Gerar script de exportação de exportação de dados
Use um script de shell para gerar e exportar um script DML para todos os dados e redirecioná-lo para o arquivo srcdb1_export.sql. Para usuários familiarizados com o DB2, você deve saber que cada tabela, visualização e alias criado no banco de dados corresponde a uma linha de registros em SYSCAT.TABLES. Portanto, todas as informações necessárias da tabela do banco de dados podem ser obtidas por meio da instrução de seleção do banco de dados correspondente. Conforme necessário, o script de shell a seguir selecionará os nomes de todas as tabelas do esquema de guias em SRCDB1 que são SRCDB1, ASN, SQLDBA e DB2DBG com base no campo tabname da tabela de sistema SYSCAT.TABLES e gerará instruções de exportação correspondentes com base em seus nomes Alcançar o objetivo da exportação em lote. A função rtrim é usada para remover os espaços no lado direito dos dados do campo tabname.
Listagem 6. Gere o script de exportação
# db2 "select 'export to ' rtrim(tabname) '.ixf of ixf select * from '
rtrim(tabname) ';' from syscat.tables
where tabschema in('SRCDB1', 'ASN', 'SQLDBA', 'DB2DBG')" > srcdb1_export.sql;
Edite o srcdb1_export.sql gerado, exclua as informações estatísticas exibidas no cabeçalho e na parte final e retenha apenas as instruções de exportação necessárias. Ao modificar as informações do esquema de guias contidas no script acima, você pode especificar o intervalo de tabelas que precisam ser exportadas, ou seja, todos os nomes de tabelas necessários durante o processo de migração. A instrução export export gerada possui o seguinte formato de comando:
db2 export to tablename.ixf of ixf select * from tablename
4. Gerar script de carregamento de importação de dados
Use shell script para gerar script de carregamento para importar dados para o sistema de destino: srcdb1_load.sql
Listagem 7. Gerar script de carregamento
# db2 "select 'load from ' rtrim(tabname) '.ixf of ixf insert into '
rtrim( tabname) ';' from syscat.tables
where tabschema in ('SRCDB1', 'ASN', 'SQLDBA', 'DB2DBG')" > srcdb1_load.sql;
Edite o srcdb1_load.sql gerado e exclua as estatísticas iniciais e finais. , mantenha apenas as instruções de carregamento necessárias. Semelhante à instrução de exportação, o script de shell acima seleciona os nomes de todas as tabelas em SRCDB1 da tabela do sistema e gera instruções de importação correspondentes com base em seus nomes para atingir o objetivo de importação em lote. O formulário de comando da instrução import import gerado é o seguinte:
db2 load from tablename.ixf of ixf insert into tablename;