Os comando COMMIT e ROLLBACK são usados para controle de transações, mas o engine SQL do OpenEdge não aceita estes comandos diretamente. [Leia mais]

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]

Testar conexão a um banco Informix por meio de ODBC no Linux. Útil para testar conectividade a partir do appserver TOTVSTEC. [Leia mais]

· Criar novos chunks (zerados) necessários para o retorno do banco de dados. Ex: original: /dadosifx/wms/rlv_wms /dadosifx/wms/rlv_wms1 novo: /dados/wms/tst/wms1 /dados/wms/tst/wms2 · Criar as seguintes linhas no arquivo sqlhosts. Ex: original: wmsshm onipcshm 10.10.10.3 wms wmssoc onsoctcp 10.10.10.3 wmssrv novo: wms1shm onipcshm 10.10.10.3 wms wms1soc onsoctcp 10.10.10.3 wms1srv · Copiar o arquivo onconfig.wms para o arquivo onconfig.wms1 e alterar as seguintes variáveis. Ex: SERVERNUM DBSERVERNAME DBSERVERALIASES Nada impede de alterar as outras variáveis, como por exemplo, BUFFERS, NETTYPE, NUMCPUVPS, LOCKS Deixar a variável ROOTPATH com o caminho original na hora de retornar o backup, pois, após o retorno do backup a mesma será alterada pelo comando ontape. Ex.: original: ROOTPATH /dadosifx/wms/rlv_wms novo: ROOTPATH /dadosifx/wms/tst/wms1 (Após o restore) · Criar um arquivo com os caminhos e offsets dos chunks originais e com os caminhos e offsets dos novos chunks. Ex.: /dadosifx/wms/rlv_wms 0 /dadosifx/wms/tst/wms1 0 /dadosifx/wms/rlv_wms1 0 /dadosifx/wms/tst/wms2 0 No exemplo acima utilizamos o offset = 0 porque, por padrão, não utilizamos chunks configurados com o offset. Se algum cliente utilizar offset verificar o numero do offset antes de restaurar o mesmo. · Restaurar o archive com o seguinte comando. Ex: ontape -r -rename -f nome_arquivo_criado_com_conf_ chunk Ex.: ontape -r -rename -f teste

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

Em continuidade a série de arquitetura de banco de dados do OpenEdge, um post rápido sobre os arquivos de log de mensagens. [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.