Database Upgrades : Perfect Performance Every Time

Transcrição

1 <Insert Picture Here> Database Upgrades : Perfect Performance Every Time Antonio Menezes Oracle Consulting antonio.menezes@oracle.com

2 Agenda Desafios Boas Práticas SQL Plan Management Real Application Testing O Caso Sicredi Q&A

3 O Grande Desafio : A Mudança é Constante e Incessante Globalização. Comunicação instantânea. Redes virtuais de negócios. Estas são algumas das mudanças vertiginosas que estão forçando as empresas a reinventar o modo como fazem negócios. Uma coisa é certa : Mudar já não é algo que acontece periodicamente. É algo contínuo, constante, incessante. Para atingir um alto desempenho, as empresas precisam aprimorar continuamente seu foco de mercado, e desenvolvier capacidades distintas para se adaptar às novas fontes de vantagem competitiva, bem como tirar partido da inovação para criar novos mercados.

4 Oracle Database 11gR2 Upgrade Principais agentes de mudança CRESCIMENTO DOS NEGÓCIOS As empresas precisam, continuamente, atualizar sua infraestrutura para continuar mantendo seus níveis de serviço. CONFORMIDADE O modelo tradicional de testes consome tempo e deixa margem para conjecturas e dúvidas. Há incertezas sobre os efeitos que as mudanças podem ter sobre o sistemas sob normas regulatórias. AMEAÇAS e OPORTUNIDADES COMERCIAIS A habilidade de se adaptar rapidamente para conter riscos ou explorar novas oportunidades é uma necessidade.

5 Agenda Desafios Boas Práticas SQL Plan Management Real Application Testing O Caso Sicredi Q&A

6 Gestão de Problemas de Desempenho Desafios Mais de 90% dos problemas de migração/atualização são problemas de desempenho que ocorreram após a mingração/atualização Áreas típicas: Otimizador planos de execução Incremento na demanda por recursos computacionais Mudanças de código Boas Práticas Avaliar o impacto das mudanças, num ambiente de testes, usando as WLs reais (do ambiente de produção)

7 Gestão de Problemas de Desempenho Produção Milhares de Usuários Online PRODUÇÃO

8 Gestão de Problemas de Desempenho Equipes de Teste tentando simular milhares de usuários PRODUÇÃO TESTE

9 Gestão de Problemas de Desempenho Oracle RAT Captura Capture Workload PRODUÇÃO

10 Gestão de Problemas de Desempenho Oracle RAT Database Replay Capture Workload Replay PRODUÇÃO TESTE

11 Gestão de Problemas de Desempenho Teste das mudanças como se estivesse no ambiente de produção Capture Workload Replay PRODUÇÃO TESTE

12 Avaliar Planos de Execução Desafios O desempenho de qualquer aplicação que use bancos de dados depende fundamentalmente da execução das consultas Os planos de execução para os comandos SQL podem mudar inesperadamente Não há garantias de que um plano de execução irá sempre mudar para melhor Boas Práticas SQL Plan Management (SPM) é uma ferramenta para a evolução controlada dos planos de execução Somenten planos verficados, com desempenho igual ou superior aos seus antecessores são utilizados

13 Gestão do Processo de Mudança Desafios Mudanças frequentemente introduzem períodos de instabilidade nos sistemas de TI Mudanças têm impacto sobre o desempenho Testes consistentes podem ser morosos e insuficientes Boas Práticas Reproduzir as cargas de trabalho do ambiente produtivo no ambiente de testes e assim avaliar o impacto real de cada mudança.

14 Agenda Desafios Boas Práticas SQL Plan Management Real Application Testing O Caso Sicredi Q&A

15 SQL Plan Management Evolução controlada dos planos de execução Feature SQL plan baseline capture SQL plan baseline selection SQL plan baseline evolution Função Criar as baselines para os planos de execução dos Encontrar planos correspondentes na baseline Avaliar todos os planos de execução nãoverificados Resultados Planos de execução para todos os comandos SQL relevantes Planos de execução aceitos (confiáveis) para todos os comandos SQL relevantes Identifica planos não aceitos que precisam ser verificados para tornarem-se aceitos

16 SEM SQL Plan Management Congelamento dos planos de execução de das estatísticas é um desafio Cenário: O comando foi analisado e um plano foi criado Verificação acontece durante a execução: GB Parse Execute Plan acceptable HJ HJ Agora, algumas condições mudaram (por exemplo, um upgrade) Um novo plano é criado ele será melhor ou pior??? GB Parse Execute Plan possibly NL not acceptable NL

17 SQL Plan Management Primeiro mecanismo preventivo, e totalmente transparente, para garantir a estabilidade do plano de execução Planos de execução dos comandos SQL serão gravados Um SQL baseline será criado Consiste de planos de execução aceitos Contém somente planos para comados que foram analisados/executados mais de uma vez Somente planos conhecidos E verificados E aceitos serão utilizados Package: DBMS_SPM

18 SQL Plan Management 3 fases para a estabilidade do plano Capture Cria um SQL baseline com os planos de execução confiáveis Baseline é armazenada no SMB (SQL Management Base) Selection Somente os planos aceitos serão utilizados Novos planos de execuçãop serão registrados no histórico de planos Evolution Avalia todos os planos não verificados no histórico para aceitá-los ou rejeitá-los

19 SQL Plan Management - Cenários Upgrade Cenário 1 Parametrize o otimizador para trabalhar com o comportamento antigo Método disponível desde a versão Upgrade Cenário 2 Transporte todos os planos bem conhecidos para a nova versão Versão 10gR2 em diante Implantar um novo aplicativo (módulo) com as SQL baselines apropriadas Entregar os melhores planos de execução para os novos comandos SQL e garantir que eles serão utilizados Versão 10gR2 em diante

20 Agenda Desafios Boas Práticas SQL Plan Management Real Application Testing SQL Performance Analyzer Database Replay O Caso Sicredi Q&A

21 Real Application Testing Gestão de Mudanças para Ambientes de Produção Feature Função Resultados SQL Performance Analyzer Avaliar o impacto no desempenho dos comandos SQL Identificação mais rápida e previsível de possíveis problemas de desempenho Database Replay Testar e validar os efeitos de uma mudança diante da reprodução de uma carga de trabalho real, obtida diretamente no ambiente de produção, sobre um ambiente de testes Compreensão plena do impacto que as mudanças irão provocar no ambiente de produção

22 Real Application Testing Ferramentas SQL Performance Analyzer Database Replay O que é? Como funciona? Quando usar? Prevê desvios de desempenho nos comandos SQL antes que os usuários finais sejam afetados. Ajuda a avaliar o impacto da mudança no tempo de resposta do comando SQL. Executa cada comando SQL, armazenado no SQL Tuning Set, isoladamente, usando o contexto de produção, para comparar os planos de execução anteriores e posteriores à mudança e as estatísticas geradas em tempo de execução Teste unitário de comandos SQL com o objetivo de identificar o conjunto de comandos SQL com melhoria ou regressão de desempenho Reproduz a carga de trabalho, obtida no ambiente de produção, sobre o ambiente de teste. Ajuda a avaliar o impacto da mudança mediante o throughput. Captura a carga de trabalho e a reproduz com as características de produção, incluindo concorrência, sincronização e dependências. Teste abrangente de todos os subsistemas do servidor de banco de dados, usando uma carga de trabalho real SQL Concurrency SQL Dependency Speed up/down

23 Real Application Testing Objetivo: Possibilitar a adoção bem sucedida de novas funcionalidades e tecnologias, com baixo custo e baixo risco Registrando e reproduzindo uma carga de trabalho real para ver como o novo sistema se comporta Descobrir regressões e mudanças de planos antes da atualização Exige licenciamento do pacote "Real Application Testing" Disponível com a versão Oracle Database Disponível com o patch set para a versão Disponível como um single patch para as versões e Consultar Note: para obter os número dos patches Pode ser usado para upgrade nos seguintes caminhos: / x / x

24 Real Application Testing Database Replay Recria a carga real da base de produção no ambiente de testes Captura a carga em produção incluindo concorrência crítica Re-executa a carga de produção no ambiente de teste Analisa e conserta problemas antes da produção Client Client Client Production Test Middle Tier Replay DB Workload Oracle DB Capture DB Workload Test migration to RAC Storage

25 Passo 1: Workload Capture Todos as solicitações de clientes externos são capturadas em arquivos binários Client Client Production System Client Atividades internas e de sistema são excluídas Overhead mínimo de performance para a captura Escolha um período interessante para a captura, ex: picos de carga, fechamento de mês, etc. Pode capturar no e reproduzir no 11g Middle Tier Storage File System File 1 File 2 File n

26 Opções de Captura O workload pode ser filtrado para customizar o que é capturado Tipos de filtro Filtros de Inclusão: Especifica quais sessões devem ser capturadas Filtros de Exclusão: Especifica quais sessões NÃO devem ser capturadas Atributos de filtro: A captura pode ser filtrada usando qualquer dos seguintes atributos de sessão User Program Module Action Service Session ID A captura pode ser executada sob demanda ou programada para o futuro

27 Passo 2: Processar os Workload Files Configure o ambiente de testes Test DB deve estar no mesmo ponto no tempo que a produção antes da captura Use o RMAN para restaurar o banco de produção fisicamente a partir do backup Use imp/exp, Data Pump, etc. O processamento transforma os dados capturados para o formato replay Uma vez processada, a carga pode ser reproduzida várias vezes File 1 File 2 File n Capture Files Test System File 1 File 2 File n Metadata Replay Files

28 Passo 3: Reproduzir o Workload Reproduz o workload preservando a ordem, concorrência e dependências do sistema capturado Test System Replay Driver Replay Driver é um programa cliente especial que consome a carga processada e envia requisições para o sistema de teste O Replay Driver consiste em um ou mais clientes. Para cargas com alta concorrência, pode ser necessário inicializar múltiplos clientes File 1 File 2 File n Metadata Replay Files

29 Database Replay Mudanças Suportadas Mudanças não suportadas Client Client Middle Tier Client Mudanças suportadas Database Upgrades, Patches Schema, Parameters RAC nodes, Interconnect OS Platforms, OS Upgrades CPU, Memory Storage Etc. Storage Recording of External Client Requests

30 Restrições Atuais do Database Replay O Database Replay não suporta as seguintes funcionalidades na versão atual SQL Loader direct path load, import/export OCI based object navigation (ADTs) e REF binds Non-PL/SQL based AQ Transações distribuidas, operações remotas describe/commit Funionalidades de Flashback

31 Database Replay Novidades no Oracle Database 11g Release 2 Workload Analyzer Nova ferramenta para avaliar a qualidade da carga capturada e sua reprodução Identifica potenciais problemas e recomenda correções apropriadas Quantifica o percentual de DB Time capturado que não conseguirá ser reproduzido Analise baseada em regra executada como parte do préprocessamento Suporte ao EM e API (DB release e superior) Download a partir do OTN para versões anteriores e novas regras

32 Workload Analyzer Recomendações Execute o Workload Analyzer em cargas capturadas e siga as recomendações para melhorar a qualidade da reprodução, por ex: Transações em andamento significantes: Captura durante um período maior ou restart da base Carga sensível a sysdate/tempo: Reset system clock

33 SQL Performance Analyzer Avalia o impacto de qualquer mudança no desempenho dos comandos SQL Prevê e previne os problemas de desempenho nos comandos SQL decorrentes de modificações no sistema Visão granular do impacto gerado pelas mudanças sobre os planos de execução dos comandos SQL e sobre suas estatísticas de execução Compara os resultados da execução dos comandos SQL, obtidos antes e após a mudança Gera um relatório descrevendo os benefícos ou regressões decorrentes da mudança Integra-se com outras ferramentas SQL Tuning Set (STS) SQL Tuning Advisor SQL Plan Management

34 SQL Performance Analyzer SQL Performance Analyzer Stages Produção Teste Capture SQL Transport SQL Execute SQL Prechange Execute SQL Postchange Compare Performance

35 SQL Performance Analyzer Cenários mais comuns Upgrades do banco de dados Mudanças de parâmetros de inicialização Mudanças de esquema Renovação das estatísticas do otimizador Etc.

36 Oracle Technical Resources Get Started on the Upgrade Path Oracle 11gR2 Upgrade Companion Note SQL Plan Management abase/pdf/ow07/spm_white_paper_ow07.pdf SQL Performance Analyzer abase/pdf/ow07/spa_white_paper_ow07.pdf Database Replay abase/pdf/ow07/db_replay_white_paper_ow07_1.pdf

37 Agenda Desafios Boas Práticas SQL Plan Management Real Application Testing O Caso Sicredi Q&A

38 O Sicredi Sistema de Crédito Cooperativo SICREDI: - Opera com 128 (cento e vinte e oito) cooperativas de crédito; - 5 (cinco) Centrais Estaduais; - 1 (um) Banco; - 1 (uma) Confederação; - Empresas de apoio (Administradora de Consórcios, Corretora de Seguros, Administradora de Cartões); - Mais de (treze mil) colaboradores; - Mais de (mil) unidades de atendimento; - Unidades em 13 (treze) estados brasileiros; - Mais de (um milhão e setecentos mil) associados.

39 O Caso Sicredi Migração das versões do sistema operacional e do banco de dados que atendem o core bank do Sicredi em 07 de setembro de Como foi programado, quais testes foram realizadas como mitigadores, quais problemas enfrentamos e como foram superados. Informações do Ambiente a ser migrado Sistema Operacional 5.2 Banco de Dados Conexões Simultâneas Aprox Tamanho da base de dados 6TB Aplicativos que utilizam essa infraestrutura 83

40 Planejamento - Inicio do planejamento do projeto em 13 de outubro de 2008; - Definição do escopo da migração; - Definição do escopo de teste de aplicativos; - Definição das ferramentas que auxiliariam nos testes; - Definição de testes refletindo um dia de uso por parte dos usuários; - Inicio do projeto em 04 de abril de 2009 para entrega em 07 de setembro de 2009.

41 Planejamento - Para Qual Versão? Oracle10g Oracle11g Suporte até Julho de 2010 Após o SICREDI poderá contratar o Extended Suport o qual possui valor adicional. Solução mais madura Risco de migração tende a ser menor Maior número de Cases de mercado Comportamento em testes similar a produção Recomendação Accenture Suporte até agosto de 2012 Solução com maior foco de suporte por parte do fornecedor Maior longevidade da migração Funcionalidades Técnicas Superiores Comportamento em testes similar a produção Recomendação Oracle

42 Planejamento - Ofensores vs. Mitigadores Ofensor Mitigador Abrangência do Projeto Complexidade técnica Mudança do otimizador do banco Aplicações impactadas Continuidade do Desenvolvimento Projeto sem entrega de negócio Aplicações 24x7 Janela para migração Apoio da Diretoria Executiva e do Conselho de Administração Dedicação de 3 analistas para o projeto Teste de stress para rotinas de processamento Testes integrados e unitários em todas as aplicações Pacotes com datas definidas e homologação em dois ambientes (Atual e Novo), com período de congelamento antes e depois do projeto Envolvimento das cooperativas nos testes finais Criação de tecnologia para empilhamento de transações Realização de 4 simulações de migração

43 Testes Realizados horas de testes em aplicativos realizadas por 210 colaboradores da equipe de Qualidade; horas de análise de infraestrutura realizadas por 23 colaboradores da equipe de Infraestrutura; - 5 migrações em ambientes de teste (todas geraram redução na duração da migração); - Processamento completo de 4 encerramentos diários, acumulando 48 horas de processamento maciço; horas de simulação de uma dia real da cooperativa, realizadas por colaboradores das cooperativas;

44 Testes Realizados As Simulações Simulações de Processamento Simulação de Dia Real Data a ser simulada Quando realizamos 13 de abril de 2009, 30 de abril de 2009, 15 de junho de 2009 e 01 de julho de de abril de 2009, 05 de maio de 2009, 20 de junho de 2009 e 04 de julho de de agosto de de agosto de 2009 Quantos Envolvidos 12 pessoas pessoas Quem foi envolvido Foco Como foi realizado Colaboradores de TI e da área de Processamento Comparar o tempo de processamento do fim do dia da versão migrada com as versão em produção Armazenamento da posição antes do processamento e migração da versão Colaboradores das cooperativas, áreas de TI e consultorias externas Acompanhar o comportamento do ambiente de infraestrutura sobe carga e realizar ajustes de parâmetros Armazenamento da posição do inicio do dia e dos documentos necessárias e repetir as operações do dia e migração da versão.

45 Os Problemas Antes da Migração O que Ação Mudança do Algoritmo de Group By. Duas variáveis declaradas com o mesmo nome em uma package Impossibilidade de utilização do Database Replay devido a versão utilizada Bug no instalador da versão 11 do cluster no AIX 6.1 Bug de restart do cluster devido a timeout no OPROCD Impossibilidade de utilização do Database Vault devido a um bug do produto Inclusão da cláusula Order By quando a ordenação era necessária Ajuste na codificação Testes Manuais. Solução encontrada internamente, aberto um chamado onde nossa solução foi validada Aberto chamado na Oracle e na IBM, ajustamos parâmetro de Time Out posteriormente referendado pela Oracle. Exclusão do projeto

46 A Migração - Optou-se por Export e Import em uma nova instalação devido a: - Reorganização de objetos; - Evitar eventuais problemas com o migrate devido as versões; - Mudança da forma de armazenamento de Raw Device para ASM; - Utilização de filas de impressão para execução de scripts de ksh (korn shell) para todo o processo; - Segmentação das importações de dados e criação de índices e constraints; - Monitoramento dos processo através de trace, o qual também era enviado por ; - Tempo Total de Export e Import 16:00:00.

47 A Migração P 595-P6 62x2.3 Ghz 64 Gb Aplicações 24x7 Banco Produção 9i P 595-P5 30x2.3Ghz 64 Gb Flash Copy Data Center Secundário P 595-P6 62x5Ghz 192 Gb Banco Clone 9i Export NFS File System montado remotamente 30 Processos de Export 2 TB Banco Produção 11g 48 Processos de Import

48 Os Problemas Após a Migração O que Ação Queda de uma das máquinas Lentidão nas rotinas batch devido a mudança do otimizador Quedas diárias após uma semana Quedas no mês de janeiro de 2010 Quedas no mês de fevereiro de 2010 Bug de Firmware em uma máquina P595, Implantação de um fix da IBM. Ajuste do cálculo de estatísticas, otimização de comandos e ajustes de parâmetros dos sistemas Desabilitamos todos os gerenciamentos de memória automáticos Bug no gerenciamento de processos distribuídos (dblink), a Oracle desenvolveu um pacth para o SICREDI, o qual está aplicado em desenvolvimento e irá para produção em abril Bug no change track Write (CTWR), não foi possível a Oracle identificar o bug, desabilitamos a opção

49 O Que Poderia Ser Melhor O que Ação Testes de carga simulada Verificação de impactos das alterações do otimizador Estimativa de gastos com testes e consultoria Comunicação com os afetados O uso do Real Application Test foi cogitado a época, porém por compatibilidade não foi possível a utilização. Em necessidades posteriores a essas fizemos uso da ferramenta. O uso do SQL Plan Management poderia ter mitigado problemas de desempenho enfrentados após a migração, porém não congitamos o uso da ferramenta a epoca. Superestimamos os testes e subestimamos a consultoria, em um projeto dessa magnitude é importante dividir responsabilidades com os provedores, em nosso caso foram envolvidos Oracle, IBM, Accenture e EMC, todos participaram in-loco do teste final e da migração ao menos A magnitude do projeto exigiu um forte aparato para comunicação, a abrangência sistêmica do projeto e seu impacto requeriam um núcleo de comunicação dedicado ao mesmo

50 O Uso do RAT

51 Os Ganhos O que Suporte a nova versão Compactação de dados Novos tipos de particionamento ASM Queda de 50% no consumo de Hardware Monitoramento através do Oracle Enterprise Manager Economia com licenciamento do software de cluster

52 Agenda Desafios Boas Práticas SQL Plan Management Real Application Testing O Caso SICREDI Q&A

53 Perguntas e Respostas

54