Migrando para OpenEdge 10. Regis Martins Ezipato Sr Solution Engineer

Transcrição

1 Migrando para OpenEdge 10 Regis Martins Ezipato Sr Solution Engineer

2 Façam as perguntas durante a apresentação 2

3 Visão Geral Versão 7.2A 8.2A 8.3A 9.0A 9.1A 10.0A 10.1A Quando Passado distante Passado distante Agosto 1998 Dezembro 1998 Dezembro 1999 Dezembro 2004 Janeiro 2006 Idade ancião ancião ancião 7,5 anos 6,5 anos 2,5 anos 0,5 ano 3

4 Por que atualizar para OpenEdge 10 RDBMS? 4

5 Por que atualizar para OpenEdge 10 RDBMS? O 10.1A RDBMS é melhor, mais poderoso, mais rápido 5

6 Por que atualizar para o OpenEdge 10 RDBMS? Data archival Save key events Maintenance logfile format Defrag tables online AI archiving utility Add table/field/index online Add extents online Replication failback High Availability Truncate logfile online Clusters Datatypes XML support New IDE Business Agility OO ext to 4GL JTA support Fast quiet points index concurrency Adaptive transaction end locking Limits / Scalability Type II Storage Audit core service SQL Audit archive util DB defaults Audit roles defined & Multi-threaded enforced utilities Type 4 JDBC drivers Performance Security 6

7 Estratégia Geral de Atualização Backup Rode dbanayls & promon para referência Instale OpenEdge 10 (não precisa sobrepor av9) Atualize o Banco para OE10 Rode UPDATE STATISTICS para SQL Faça seus backups!!!! Recompile os programas em 4GL Rode suas aplicações 7

8 Os 5 Minutos da Atualização 8

9 Passos para conversão do Servidor de Banco de dados Atualize os client s primeiro, depois o Servidor de banco de dados Preparação Backup dos bancos de dados Trunque BI, Desabilite AI Instale OpenEdge 10 Rode o utilitário de conversão Backup da base de dados Inicie a base de dados 9

10 A regra dos 5 Minutos O utilitário de conversão roda em 5 minutos ou menos Geralmente, nós atualizamos o Schema das tabelas Nenhuma alteração para registros ou índices Nenhuma alteração na estrutura física 10

11 Conversão da base de dados proutil <db> -C conv910 -B 512 probkup <db> 11

12 O que acontece após os 5-minutos? Você pode rodas a base de dados! Você verá que rodará melhor que antes Fragmentação ainda existirá Os scripts de seu DBA rodarão sem problemas Todos os dados estarão em Storage Areas do Tipo I Otimize quando o tempo permitir... 12

13 Como eu consigo mais performance do que eu consegui com a rápida conversão? Fazendo mais alguns passos! 13

14 Mova os dados para Storage Areas do Tipo II 14

15 Movendo para Areas do Tipo II Antes: Primeira atualização com utilitário de conversão Mova o schema das tabelas Crie Areas do Tipo II Mova tabelas e índices Depois Trunque as Storage Areas velhas Apague as Storage Areas velhas 15

16 Antes de mover 16

17 Movendo schema das tabelas proutil <db> -C mvsch Renumera Areas existentes Cria nova schema area número 6 Copia schema das tabelas Deleta schema das tabelas velhas 17

18 Movendo Tabelas e Índices Tablemove e Indexmove Dump e Load 18

19 Definição das Storages Areas Tamanho dos blocos do banco: 4k ou 8k Blocos de bi & ai deverão ter o mesmo tamanho Tamanhos dos Clusters das Areas do Tipo II Area de Tabelas: 512 Area de Índices: 512 Dump e load requerido para alterar o tamanho dos blocos de dados e índices 19

20 Usando movimentação de Tabelas e Índices 20

21 Table Move proutil <db> -C tablemove \ [owner-name.]table-name table-area \ [ index-area ] Pode mover apenas tabelas ou tabelas e índices 21

22 Index Move proutil <db> -C idxmove \ [owner-name.]indexname area-name 22

23 Depois que mover 23

24 Truncando area proutil <db> -C truncate bi proutil <db> -C truncate area \ <area-name> Area logicamente truncada Extensões podem ser apagadas prostrct remove <db> <extent-type> \ <area-name> 24

25 Se você não pode usar tablemove: Dump e Load 25

26 Estratégia de Dump e Load Antes: Backup Atualize com utilitário de conversão Mova schema das tabelas Dump das definições e tabelas Crie nova base de dados com Storage Areas do Tipo II Load das definições Load dos dados das tabelas Reconstrua os índices Backup 26

27 Dump das definições dos dados Use Data Administration tool Dump de todas as definições das tabelas e índices Produza arquivos.df 27

28 Escolhas para Dump/Load Dump pelo Dicionário (para texto) Load pelo Dicionário Bulkload Dump através de programas customizados Load também customizado Programas customizados com buffer-copy Dump Binário Load Binário 28

29 Dump pelo Dicionário Fácil Lento 2 GB de tamanho limite Não pode escolher a ordem de dump Somente Dump da tabela inteira 29

30 Bulkload proutil <db> [-yy n] -C \ BULKLOAD fd-file -B 1000 Use o dicionário ou código customizado para exportar os dados Load de uma tabela por vez Mais rápido do que o dicionário de dados Mais lento do que Load Binário 30

31 Programas customizados para Dump Você terá que escrevê-los Use os comandosexport e IMPORT Pode exportar subconjuntos de dados Pode rodar multiplos loads simultaneamente Mas não em Areas do Tipo I 31

32 buffer-copy Você terá que escrever programas Requer planejamento Pode ser feito enquanto aplicações usam o banco antigo Pode copiar parte dos dados Pode escolher a ordem do dump via índice Não necessita de arquivo de dump Pode ler múltiplas tabelas ao mesmo tempo 32

33 Dump e Load Binário Fácil Não tem o limite de arquivos maiores de 2 GB Pode escolher a ordem do dump (-index) Pode exportar parte dos dados Pode ler múltiplas tabelas ao mesmo tempo 33

34 Usando Dump e Load Binário 34

35 Dump e Load Binário Dump à partir de Areas de Dados do Tipo I Crie nova estrutura de base de dados (.st) Load para Areas do Tipo II proutil <db> -C dump <table>. index 0 Velocidade Dump vs Velocidade Load Escolha um índice baseado na ordem de leitura 10 x mais rápido proutil <db> -C load <table>.bd build Load com build indexes Load para uma nova Area ou para uma Area truncada (truncada ao invés de esvaziada ) 35

36 Grandes Bancos de Dados: Dump e Load Processos mais rápidos Dump e load binário Múltiplos processos (3-5 por CPU) Dump usando o maior índice (# blocos) Reindexação no mesmo comando do Load Uma fase a menos É mais rápido Load paralelo para Areas do Tipo II 36

37 Grandes Bancos de dados: Dump e Load Processos mais rápidos Ajustes para altas atividades: Dump com RO e alto B Load com Alto B, r 1-2 APW s por CPU, -pwqdelay 10, -pwscan 1024, -pwwmax K de blocos de BI, clusters de BI grandes, Não use AI/2PC Para cada passo, divida as atividades através de discos / controladoras 37

38 Depois do load 38

39 Depois do Load você precisa rodar build indexes Pode ser feito em grupos ou todos de uma vez Por area, tabela ou owner Por area faz mais sentido Não se esqueça de usar sort scratch space (-SS) backup de sua base de dados 39

40 Reconstrução de Índices depois do Load Reconstrução de índices por area, tabela, ou schema proutil <db> -C idxbuild table <table> proutil <db> -C idxbuild area <area> Outros valores -SG 64 (sort groups) -SS arquivo (scratch space location list) -TM 32 (merge buffers) -TB 32 (temp block size) -B

41 Resumindo 41

42 Sumário 10.1A RDBMS é melhor, mais poderoso, mais rápido SEM alterações nas aplicações Conversão é rápida Otimiza seu tempo livre Melhora a produtividade no gerenciamento do ambiente 42

43 Perguntas 43

44 44