Roteiro básico para analisar problemas de desempenho em base de dados Oracle baseando em arquivos de trace de comandos SQL. [Leia mais]

Aprendendo a ativar o TRACE das sessões Oracle nos produtos Datasul e Logix. [Leia mais]

Existem algumas situações aonde se faz necessário rastrear os comandos que o banco de dados está recebendo. Dentre estas situações as mais comuns são questões relacionadas a desempenho e erros. O rastreamento dos comandos SQL é útil também para descobrir o comportamento de uma aplicação da qual não se tem acesso aos fontes, muito comum quando se administra bases de dados utilizadas por um ERP de mercado. No Oracle é possível rastrear comandos de todo o banco de dados, de alguns serviços ou algumas sessões, conforme veremos em um post futuro. Quando o rastreamento é habilitado, o(s) arquivo(s) de trace (.trc) são gerados no local assinalado pelo parâmetro ‘USER_DUMP_DEST’. Para evitar que sejam gerados arquivos exageradamente grandes, o seu tamanho pode ser limitado pelo parâmetro ‘MAX_DUMP_FILE_SIZE’. O arquivo de trace (.trc) geralmente é composto por um cabeçalho, que detalha a sessão que o gerou, e o restante do seu conteúdo apresenta os comandos SQL que esta sessão enviou ao banco de dados, detalhando as atividades de parser e montagem do plano de execução, bem como todas as execuções e fetches. A seguir veremos trechos deste arquivo gerado para uma sessão do ‘SQL Plus’ aonde foram executados estes dois comandos: select * from scott.dept; select * from scott.emp where deptno = 30; Para este simples teste o arquivo gerado possui 840 linhas de detalhamentos. Na figura a seguir temos o cabeçalho deste arquivo: Na próxima figura vemos os detalhes da execução do primeiro comando: Nesta figura o trecho com a execução do último comando:   O arquivo de trace, devido ao seu tamanho e complexidade não é de fácil leitura para análise de desempenho, pois para isto precisamos de alguns valores agregados e já consolidados. Para esta tarefa existe o utilitário TKPROF, capaz de gerar uma saída mais produtiva para isso. A seguir vemos um exemplo onde este arquivo de trace é processado pelo tkprof: Podemos observar nesta figura que o arquivo gerado (.lst) é bem menor que o arquivo de trace. Na próxima figura vemos um trecho do seu conteúdo: Em um post futuro veremos, em linhas gerais, o que observar neste arquivo para analisar situações de desempenho. Mais sobre o exposto aqui pode ser encontrado na documentação do Oracle, especificamente para a versão 10gR2, neste documento.

O produto Datasul com base Oracle desde as primeiras versões até a versão atual foi instalado com a padronização do conjunto de caracteres WE8ISO8859P1. Considerando as integrações com outros produtos e considerando-se os pré- requisitos definidos pela Progress, houve a necessidade de configurar um novo conjunto de caracteres. Sendo o conjunto WE8ISO8859P1 um subconjunto do WE8MSWIN1252 que contém 27 códigos a mais, este pode ser utilizado sem problemas.  Por exemplo, se na estação do usuário houver a configuração do conjunto WE8MSWIN1252 e no lado servidor for igual a WE8ISO8859P1 e caso a aplicação referenciar um dos novos caracteres, haverá a ocorrência de erro. Há casos onde o aplicativo pode consistir o conjunto de caracteres, como exemplo o aplicativo TSS, que verifica no banco se o valor é igual a "WE8MSWIN1252". Sendo este diferente, é reportado no arquivo "topconsole.log" uma mensagem de alerta. Nos ambientes onde já existe Datasul (base e estações) utilizando o conjunto WE8ISO8859P1 e haverá integração com o TSS, o ideal é seguir o pré- requisito. Neste caso é recomendado criar uma nova base de porte pequeno para comportar somente as tabelas do TSS. Caso tenhas a instalação TSS no esquema de outro produto e queiras separar, não se preocupe com a comunicação entre estes, pois ocorre via serviços. Optando por ter uma única base de dados para ambos (Datasul, TSS e outros), se recomenda usar o conjunto mais atualizado. Nossa equipe já realiza as novas instalações ou manutenção separando o TSS em esquema específico.  

Por se tratar de um aplicativo com um comportamento diferente em relação ao banco de dados é recomendável que suas tabelas fiquem em um esquema separado do ERP. Como na maioria das instalações as tabelas são criadas no mesmo esquema, um procedimento para movimentação dessas tabelas se faz necessário. Destacamos abaixo os passos necessários para a realização deste procedimento: ·         Criar um novo esquema com as mesmas permissões e características do esquema utilizado para o ERP (e.g. CREATE USER...; GRANT...;) ·         Instalar e configurar o TOTVS SPED SERVICE e TOTVS DBACCESS, utilizando este novo esquema (essa instalação é temporária) ·         Ao iniciar os serviços do TOTVS DBACCESS e TOTVS SPED SERVICE (e.g. totvsdbaccess -console;  totvsappserver -console), as tabelas utilizadas pelo sistema serão criadas no novo esquema (25 tabelas) ·         Parar os serviços atuais ·         Exportar as tabelas do esquema utilizado no ERP (e.g. expdp... include=TABLES:”LIKE ‘SPED%’” content=DATA_ONLY) ·         Importar as tabelas no novo esquema (e.g. impdp... remap_schema=...) ·         Configurar os serviços atuais para utilizarem o novo esquema ·         Iniciar os serviços atuais Para exportar e importar em um único passo, sem arquivos intermediários, veja esse post.  

Uma característica interessante do RMAN é a habilidade de duplicar um banco de dados, facilitando a atualização do ambiente de teste (a partir da versão 10g). No passo a passo abaixo utilizarei a clausula “from active database” (disponível somente no 11g).LegendaBanco de Produção = prdBanco de Testes = tstProcedimento• Adicionar o(s) banco(s) nos arquivos $ORACLE_HOME/network/admin/listener.ora e tnsnames.ora• Reiniciar o listener (e.g. $ORACLE_HOME/bin/lsnrctl stop; $ORACLE_HOME/bin/lsnrctl start)• ORACLE_SID=prd• $ORACLE_HOME/bin/sqlplus / as sysdbacreate pfile from spfile;• mv $ORACLE_HOME/dbs/initprd.ora $ORACLE_HOME/dbs/inittst.ora• vi $ORACLE_HOME/dbs/inittst.orasubstituir prd por tstincluir no fim do arquivo log_file_name_convert=’/caminho/prd’,’/caminho/tst’• ORACLE_SID=tst• $ORACLE_HOME/bin/orapwd file=$ORACLE_HOME/dbs/orapwtst password=senha• $ORACLE_HOME/bin/sqlplus / as sysdbastartup nomount• $ORACLE_HOME/bin/rman target sys/senha@prd auxiliary sys/senha@tstduplicate target database to tst from active databasedb_file_name_convert /caminho/prd/','/caminho/tst/';ObservaçãoO banco de origem (target) deve estar no modo ARCHIVELOG ou MOUNT.ReferênciaCapítulo 23 do Guia Backup and Recovery

Opção para transportar dados no Oracle via DataPump sem a criação de arquivos intermediários. [Leia mais]

Veja como é simples embutir sentenças SQL nos programas 4GL / ABL. [Leia mais]