Novos parâmetros para desempenho do processo de indexação [Leia mais]

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

Como otimizar a conversão para o Datasul 11. [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 Open Edge dispõe de uma funcionalidade na qual é possível compartilhar uma instalação do Cliente Progress em um servidor para múltiplos clientes efetuarem o acesso através de um mapeamento de rede ou UNC (Universal Naming Conventions).  Para tal, é utilizada a funcionalidade de Shared Network Installation Utility (NetSetup).  Em uma instalação completa (Complete Installation) o NetSetup é instalado automaticamente em um diretório denominado “netsetup”.  Em uma instalação customizada (Custom Installation), o NetSetup deve ser selecionado durante a instalação.  Para efetuar a instalação nas estações, executar o “setup.exe” localizado no diretório “netsetup” do servidor, através de um mapeamento de rede ou UNC, conforme abaixo Unidade:\caminho destino\netsetup\setup.exe  \\servidor\nome do compartilhamento\caminho destino\netsetup\setup.exe     Neste tipo de instalação todo o processamento dá-se de forma local (diretório de trabalho), porém tem-se um aumento no tráfego da rede, o que pode ocasionar certa espera no início de execução das rotinas, como por exemplo, o carregamento da aplicação. Para médios e grandes ambientes, recomenda-se a instalação de cliente local.   Para agilizar o processo de instalação em cada estação, pode ser utilizada a funcionalidade de instalação silenciosa, conforme post publicado neste blog.   Havendo dúvidas ou necessidade de acesso remoto para configuração do ambiente, entre em contato com a consultoria de Banco de Dados, pelo telefone 4003-0015, opções  "02" Software, "03" Consultoria Técnica, "04" Datasul, "08" Tecnologia e "03" Banco de Dados. 

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.  

Como utilizar o Jconsole para monitorar instâncias do Jboss e aplicações Java. [Leia mais]

Desabilitar todos os índices pode atrapalhar mais do que ajudar. [Leia mais]