Já notou como esse erro é intermitente? Hora você consegue conectar e hora não? Pois bem meu amigo, você acaba de atingir o número de processos máximos do Oracle. Mas não se assuste, este comportamento é facilmente parametrizável.

Erro:

Motivo: Limite de processos atingidos. Não é mais possível criar novas sessões no banco.
Solução: Aumente a quantidade de processos e sessões do banco de Dados.

Para verificar o valor máximo de sessão e processo do banco é necessário executar a seguinte query (logado como SYSDBA):

E para verificar a quantidade de sessões e processos ativas no momento do erro, utilize a seguinte query:

Se quiser ver tudo de uma vez só pra facilitar o serviço:

Screenshot_20170213_113240

Constatado o erro, basta alterar os parâmetros no banco de Dados:

Lembrando que para alterar estes processos, temos que reiniciar o banco de dados (shutdown e startup).
Até!!!

Ao tentarmos inicar o dbconsole:

Obtemos uma série de erros. Ao analisarmos o log (emagent.trc):

Esse erro acontece comumente quando o Database Control não pode ser protegido via SSL. Em vias gerais, o certificado presente está vencido. Para corrigir, precisamos aplicar o seguinte patch:

https://updates.oracle.com/download/8350262.html

Basicamente o que o Patch faz é gerar outro certificado com validade de mais 10 anos. Antes de começarmos, certifique-se de que as variáveis de ambiente ORACLE_HOME, ORACLE_SID e ORACLE_HOSTNAME estão definidas no bash_profile do usuário oracle. Se não, exporte-as. Verifique também se os usuários SYS, SYSMAN e DBSNMP estão desbloqueados (você vai precisar deles futuramente).

Utilize o OPatch para aplicar a correção:

Após aplicar o Patch, remova o repositório do Enterprise Manager:

E crie outro repositório novo:

Aguarde o término do processo…

Se a sua mensagem foi parecida com essa aqui acima, tudo certo! Basta abrir o Enterprise Manager. Senão, seu problema pode ser outra coisa 😉

Até a próxima!

Bom dia galera!!! Primeiramente, este é o motivo pelo qual estou aplicando este patch:

Hit the following ORA-00600 on a production environment (Oracle 10g 10.2.0.5.0)
ORA-00600: internal error code, arguments: [kcblasm_1], [103], [], [], [], [], [], []

Um errinho chato, genérico e que causa grande desconforto no nosso ambiente. E pra detecção, a Oracle também não ajuda muito:

Pois bem, para  corrigir a primeira coisa que temos que fazer é aplicar o patch PSU 10.2.0.5.4, Patch 12419392 ou posterior.
Antes de começar, certifique-se de ter dados shutdown em todas as instâncias ativas, Enterprise Manager (emctl) e Listener (lsnrctl) e que possui a última versão do OPatch para sua versão do Oracle (Caso não tenha baixe e substitua em $ORACLE_HOME/OPatch). Pois bem, vamos começar…

Listando conteúdo do diretório do Patch:

Verificando se há alguma dependência obrigatória que ainda não foi instalada:

Caso haja alguma com a legenda “IS NOT INSTALLED” instale antes de prosseguir. Este passo é MUITO importante. Vou continuar assumindo que está com todas as dependências instaladas.

Realizando pré checagem para saber se há algum conflito entre a versão instalada e o patch a ser aplicado:

O resultado deverá ser semelhante a este:

Pronto, agora sabemos que podemos prosseguir sem problemas… Caso sua mensagem seja diferente da acima, verifique antes de continuar o que possa estar causando o conflito.

Aplicando o Patch:

Aguarde terminar…

Pronto.. Patch aplicado, vamos subir o listener e o banco de dados…

Subindo banco de Dados:

Aplicando catbundle.sql no Banco de Dados:

Este processo irá recriar algumas estruturas internas do Oracle após aplicação do Patch… Aguarde pois pode demorar alguns minutos… Após concluir, recompile os objetos inválidos:

Pronto!!! Para verificar se aplicamos o Patch PSU corretamente:

Pelo OPatch:

E é isso!!!! Até a próxima 😉

Olá galera, hoje me deparei com um cenário onde os arquivos de auditoria do Oracle encheram uma partição e o banco simplesmente parou de funcionar. Muito simples, bastava apenas apagar os arquivos da DUMP_AREA correto? Eis o problema: Eu possuia mais de 600.000 arquivos somente em uma pasta (adump) e o find com rm simplesmente não funcionava.

Estava executando:

E obtia o erro:

Em suma, este erro é devido à uma limitação do comando find (como ocorre no rm e em outros também) que não permitem gerenciar um grande número de argumentos. Como solução, iremos usar o XARGS para localizar e canalizar os resultados. O xargs combina o argumento inicial com os argumentos recebidos da entrada padrão, de forma a executar o comando especificado uma ou mais vezes.

No meu caso eu simplesmente utilizei:

Explicando: Eu utilizei o comando FIND com o argumento -mtime +7 para trazer os arquivos com extensão *.aud maiores que 7 dias. Os parâmetros -P e -H serve para que o find não siga links simbólicos. Veja que para cada resultado encontrado o XARGS irá repassar o comando RM -F.

Saliento apenas na cautela em executar este comando em horários de pico, pois o I/O da máquina subirá consideravelmente enquanto o mesmo executa.

Abraços!!!

Bem, para começar vou explicar o cenário que enfrentei onde se fez necessário aumentar o tamanho dos logs de red (ou redologs). Vejamos a figura a seguir:

LGWR no Enterprise Manager

Percebam que o processo de escrita de logs (LGWR) está em segundo lugar na lista de processos mais ativos. Isso significa que servidor está quase enlouquecido escrevendo e lendo blocos de dados diretamente do disco (I/O). E porque isto está acontecendo?

Para entrarmos mais afundo neste cenário é necessário entender um pouco melhor sobre o papel dos redologs. Quando o processo de checkpoint (CPK) do Oracle é executado, ele transfere (faz flush) de todas as transações realizadas do log de buffer para os redologs. Esta operação é essencial para recuperações em caso de falhas. Basicamente, esta transferência pode ser realizada nas seguintes condições:

  1. A cada 3 segundos (default);
  2. A cada commit;
  3. Quando 1/3 da área está cheia;
  4. Quando está com 1Mb de dados (default);

Como falei anteriormente, para fazer essa transferência, o Oracle utiliza um processo chamado Logwritter, ou o famoso LGWR. Este processo atua de maneira cíclica, ou seja, quando ele termina de escrever no último arquivo de redolog, ele volta para o primeiro sobrescrevendo tudo que há nele. Veja na figura a seguir:

LGWR Escrita nos logs de redo

A cada mudança de um grupo de redolog para outro é chamada LogSwitch, e gera um ArchiveLog, que nada mais é do que um backup do redolog (caso o banco esteja em modo de archivelog). A Oracle, recomenda que a média padrão de logswitchs seja um intervalo de 15 a 30 minutos. Caso esse intervalo seja superior a isso, será necessário avaliar 2 pontos:

  1. O tamanho dos logs de redo;
  2. A quantidade de transações no banco de Dados (na maioria das vezes independe do DBA)

Como o segundo caso implica numa mudança de comportamento da aplicação, e muitas vezes foge das atribuições do administrador de banco de dados, vamos pela abordagem número 1. Tentaremos aumentar o tamanho dos logs de redo para diminuir os intervalos de logswitch.

Primeiramente, temos que avaliar a quantidade de archives que estão sendo gerados por hora. Se há muitos archives, logo, temos também uma grande quantidade de logswitchs. Utilize a seguinte query:

Caso você verifique que estão sendo gerados mais de 6 archives por hora, significa que está havendo um número de logswitchs acima do esperado.

Quantidade de Archives por Hora

Agora, para que não haja tanto impacto no nosso ambiente, iremos realizar o aumento do tamanho dos redologs de modo online. Primeiramente iremos verificar o tamanho dos arquivos de redo com a seguinte query:

O resultado será parecido com esse:

Tamanho dos arquivos de Redolog

Numero e localização dos arquivos de redologs

Agora iremos incluir mais 3 grupos de redolog:

OBS: Repeti esse mesmo processo criando os grupos 5 e 6. Por padrão, quando usamos o ORACLE-MANAGED FILES (OMF) o banco irá criar os arquivos de redolog dentro dos diretórios informados nos parâmetros DB_CREATE_FILE_DESTDB_RECOVERY_FILE_DEST (flash_recovery_area).

Uma vez criados os logs novos com 200Mb, será necessário apagar os logs antigos de 50mb (1,2 e 3). Para verificar o status de cada log, use a seguinte query:

Status dos logs de redo

Você só poderá apagar os logs de redo que estão com status INACTIVE, para mudar o status dos logs que estão em modo ACTIVE, faça um checkpoint no banco de dados:

Agora com os logs 1,2 e 3 em modo INACTIVE, poderemos apagar tranquilamente com a query:

Abaixo, scripts adiconais que podem te ajudar a personalizar a criaçao/edição dos arquivos de redolog.

  • Para criar um grupo de redolog com mais de um arquivo, siga o exemplo abaixo:

  • Para mover o arquivo de redolog de um diretório para outro:

OBS: Antes de executar a query acima, o arquivo a ser movido deverá estar obrigatoriamente no novo local. Portanto antes de movê-lo certifique-se de que o grupo da qual o arquivo pertence está INACTIVE, para só então movê-lo. Para forçar um logswitch, use o comando abaixo:

Com isso, terminamos o processo de otimização dos arquivos de redologs. Fácil não?

Até a próxima.

Exceto por razões catastróficas, nunca há a necessidade de promover um servidor hot standby para servidor primário. Porém, se um dia precisar (tomara que não) será necessário alguns passos bem fáceis até para transformar seu servidor secundário (hot standby) para primário.

  • Desligue ou desconecte da rede o servidor primário (que possívelmente já estará offline pois aconteceu algo muito sério com ele).
  • No standby, crie o arquivo de failover que irá disparar o gatilho de recuperação do servidor. Basicamente, quando você cria este arquivo no diretório configurado, o servidor automaticamente sai do estado de READ ONLY e vai para o modo READ/WRITE.

Para configurar este gatilho, basta editar o arquivo RECOVERY.CONF e acrescente o parametro trigger_file. Veja o exemplo abaixo:

  • Portanto, ao criar o arquivo pg_standby (pode ser o nome que você quiser) no diretório /tmp, automaticamente o servidor sairá da condição de standby e irá se transformar em servidor primário. Tecnicamente falando, o servidor irá finalizar todos os processo secundários do standby e recuperar todos os archives que ainda não foram recuperados, irá renomear o arquivo recovery.conf para recovery.done e subir o banco no modo de escrita e leitura (sem fazer shutdown).

  • Talvez você precise alterar seu arquivo PG_HBA.CONF para que os clients possam acessar o novo servidor.
  • Altere sua estrutura de rede para que os clients não consigam mais “enxergar” o servidor primário que foi desativado. Em seu lugar, faça com que enxergue apenas o novo servidor primário. Isso pode ser feito simplesmente mudando o IP do novo servidor para IP que antes era utilizado pelo servidor que foi desligado.
  • Agora que tudo deverá estar “normal”, conserte o servidor com problemas, enquanto isso o standby deverá cumprir bem o seu papel….
  • Quando for para voltar ao cenário original (Servidor Primário e Hot Standby), você deverá fazer um backup do standby para o servidor primário, e de lá (quando estiver no ar) refazer completamente o standby.

PROCEDIMENTO ALTERNATIVO UTILIZANDO PG_CTL

Existe um procedimento que não precisa utilizar o trigger_file. basta logar como Postgres e executar o comando PG_CTL PROMOTE. Nesse momento o banco irá automaticamente sair do modo de recuperação e assumir o papel de servidor primário:

Simples assim.

Para maior informações visite a documentação oficial do Postgres: http://www.postgresql.org/docs/current/static/warm-standby-failover.html

Até 😉

Bom dia gente!

Hoje ao realizar minhas tarefas diárias de administração de algumas bases Oracle, me daparei com a seguinte mensagem no log de alerta:

Basicamente, o Oracle possui uma área chamada de “Dump Area” que nada mais é do que alguns diretórios físicos onde são armazenados arquivos de Dump e arquivos de Trace. Quando esta área chega perto de sua capacidade limite, o Oracle começa a disparar esta mensagem para que nós, DBA’s tomemos algumas medidas. Para realizar esta manutenção, iremos utilizar um comando muito conhecido no Linux: o FIND.

Iremos fazer uma busca nos diretórios de dump do Oracle por arquivos de trace com mais de 7 dias e passar o argumento -EXEC para remover estes arquivo. Basicamente é assim:

Note que a primeira parte do script (antes do -exec) mostra todos os arquivos de trace (*.trc) com mais de 7 dias:

e a segunda parte (-exec rm {} \;) é o comando que utilizamos para que os arquivos econtrados pelo FIND sejam deletados.

Valeu!

 

 

Gente essa é rápida! Basicamente, o oracle possui toda uma estrutura de auditoria prontinha para usar, você só precisa habilitar. Vamos a documentação:

Auditing can enabled by setting the AUDIT_TRAIL static parameter, which has the following allowed values.

Sendo as opções (De acordo com a documentação):

Portanto, por exemplo, se quiser habilitar a auditoria para toda a base de modo que consiga ver absolutamente TUDO, você deverá fazer assim:

Feche e abra novamente o Banco de Dados

Agora habilite a auditoria para o usuário (No exemplo usei um usuário chamado teste):

E para ler os logs de acesso e auditar o que o usuário fez basta acessar o conteúdo da tabela DBA_AUDIT_TRAIL:

Lembrando que, como os dados de acesso serão gravados em uma tabela, fisicamente estes logs terão uma volumetria MUITO GRANDE! Portanto, audite apenas o que for estritamente necessário.

Fui!

 

 

Prezados, muitas vezes precisamos de uma instalação “stand alone” do oracle em nosso ambiente de teste para verificar consistência dos dados, auditoria, desenvolvimento, etc… Contudo, como fazer quando estamos em uma máquina que não possui acesso a rede? Simples, vamos lá:

1) Se não existir a variável de ambiente ORACLE_HOME, exporte-a. (Não vou explicar porque vou assumir todos os DBA’s do planeta sabem fazer isso).

2) Desative o listener do oracle:

LSNRCTL STOP

3) Conecte-se ao SQLPLUS com sysdba e verifique dois parâmetros:

show parameter local listener

4) O retorno deverá ser:

5) Repare que em LOCAL_LISTENER está vazio. É aqui que a mágica acontece. Veja o que este parâmetro faz:

6) Altere este valor de acordo com o comando abaixo:

7) Ative novamente o Listener

E seja Feliz!!!
Até a próxima.

Para quem não conhece, o serviço de agentes heterogêneos (ou Heterogeneous Services Agents) da oracle é uma solução que provê o acesso de um modo genérico a outras soluções não-oracle. Basicamente o serviço roda em cima de uma plataforma ODBC e permite usar o Oracle para acessar de forma transparente os dados que estão armazenados em outras bases de dados não-oracle e tratar tais dados como se estivessem dentro deste servidor.

O Heterogeneous Services (HS) permite provê 3 serviços:

  1. Serviço de Transações (para manipular sessões)
  2. Serviço SQL (acesso aos dados utilizando SQL)
  3. Serviço Procedural (chamada de procedimentos remotos – RPC)

No caso do exemplo que figuro a seguir, utilizei uma base de Dados Oracle 10g (10.2.0.5) para integrar-se com uma base Postgres 9 (9.2.7). Os testes a seguir foram elaborados em um ambiente Oracle Linux 5.

1 ) Instalar dependências no sistema operacional. Você precisar ter os seguinte pacotes:

  • unixODBC
  • postgresql-odbc

2) No servidor Oracle, configuração do arquivo /etc/odbc.ini

3) No servidor Oracle, configuração do arquivo /etc/odbcinst.ini (Alterar só o trecho abaixo e deixar o resto do arquivo inalterado)

4) Criação do arquivo em $ORACLE_HOME/hs/admin/init<SID>.ora (no meu caso o nome do arquivo ficou initDB_PGSQL.ora)

OBS: Neste momento o ODBC do seu servidor já encontra-se plenamente instalado e configurado. Para testar se está tudo configurado corretamente, utilize a seguinte linha de comando:

Veja se aparece a seguinte tela:

Caso sim, está tudo correto!

5) No servidor Oracle, configuração do $TNS_ADMIN/listener.ora

Prestem atenção à chamada em SID_LIST_LISTENER para o programa /ora/oracle/102/bin/hsodbc (este é o programa utilizado pelo HS). Modifique os caminhos para se adequar ao seu ambiente.

6) No servidor Oracle, configuração do $TNS_ADMIN/tnsnames.ora

Verifique a entrada DB_PGSQL, é lá onde a conexão com o serviço ODBC (Instalado na máquina onde está o servidor Oracle) é efetuada.

7) No servidor Oracle, criação do DB_LINK:

8) Testando conexão entre as bases. No servidor oracle, no Sqlplus, faça a consulta:

Caso seja listado o conteúdo da tabela remota, tudo certo!

  • Utilizar aspas duplas no owner e objeto remoto (como no exemplo acima).
  • Você poderá realizar operações de Insert, Delete e Update apenas se o parâmetro Readonly do odbc esteja setado para off (ver quadro do item 1).
  • A configuração do tnsnames.ora é necessária somente no Servidor.

Enjoy!
Até a próxima.