Blog do Bruno Murassaki

Olá pessoal gostaria de compartilha uma experiência que tive esses dias com um cliente.
Muitos podem achar fácil, mas tenho certeza que algumas pessoas ainda irão passar por isso, principalmente iniciantes.
Como podemos ver pela mensagem de erro tem haver com o agendamento do Job “schedule”.
Um certo dia um cliente me ligou dizendo que o horário que ele tinha agendado não estava rodando o job.
Com isso entrei no AlertLog para verificar o problema e me deparei com a seguinte mensagem:

ORA-12012: error on auto execute of job 36
ORA-12005: may not schedule automatic refresh for times in the past

Com isso pedi para o cliente que me enviasse o comando que estava sendo agendado o Job:

Comando enviado pelo cliente:  trunc(sysdate)+22/24

Verificando o comando logo notei que falta +1 logo após o Sysdate. Com isso pedi que alterasse para o seguinte comando:

Comando sugerido:  trunc(sysdate+1)+22/24

Sendo assim foi resolvido o problema do agendamento do Job

Abraço

Bruno Murassaki

Olá Pessoal,

Sabe quando um cliente liga deseperado para poder desligar o Servidor de Banco de Dados pois a energia acabou e a bateria do Nobreak está acabando?  Sim, são nesses casos que o Suporte aciona o DBA, mas por algum motivo maior não conseguiram entrar em contato com DBA.

Então o Suporte mesmo pode parar o Banco de Dados corretamente, pois quando voltar o Banco de Dados o Processo de Background SMON não precisrá executar a recuperação da Instância. Evitando assim um crash do Banco de Dados.

Sei que para muitos DBAs esses comandos básicos ja estão mais que decorados, mas estou postando este material para iniciantes ou pessoas que sejam suporte e não conseguiram contactar o DBA. Com isso ele prescisa desligar o Banco de Dados corretamente com esses comandos.

Esse post é dedicado ao meu amigo Jasper que me solicitou esse artigo.

———————————————————————————

1- Iniciar e Parar o Listener

Inicar: lsnrctl start

Parar: lsnrctl stop

Status: lsnrctl status

———————————————————————————

2- Iniciar e Parar o Banco de Dados Oracle Linux

2.1- Iniciar o Banco de Dados:

Conectado como usuario oracle no Linux digite:

sqlplus /nolog

SQL> conn / as sysdba

SQL> startup
ORACLE instance started.
Total System Global Area  184549376 bytes
Fixed Size                             2019448 bytes
Variable Size                     109055880 bytes
Database Buffers                 71303168 bytes
Redo Buffers                          2170880 bytes
Database mounted.
Database opened.

———————————————————————————

2.2 - Declaração SQL para Verificar o Status do BAnco de Dados

SQL> SELECT status FROM V$INSTANCE;

———————————————————————————

2.3- Parar o Banco de Dados:

Conectado como usuario oracle no Linux digite:

sqlplus /nolog

SQL> conn / as sysdba

SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
———————————————————————————

3- Iniciar e Parar o Enterprise Manager

Inicar: emctl start dbconsole

Parar: emctl stop dbconsole

Status: emctl status dbconsole

———————————————————————————

4- Desligar o Linux Red Hat

Pronto, após o Banco de Dados estar parado e todos

os seus serviços, agora iremos desligar o Linux:

Não tenho certeza se todos as distribuições

funcionam dessa forma, mas no Red Hat é asssim:

halt -p

———————————————————————————

Abraço

Bruno Murassaki

Olá, hoje iremos falar um pouco sobre um recurso do Oracle muito interessante para rotina de inserção dos dados. Resumable Space. O que fazer quando você tem que rodar uma grande carga DML e não correr o risco de perder tudo com o estouro de Tablespace?
Uma solução seria utilizar Resumable Space, que ao rodar um DML (Insert) com inserção de milhões de registros caso venha estourar a Tablespace, não ocorrerá problema de alocação de espaço(Tablespace). Com isso não finalizará sua sessão ocorrendo rollback, apenas irá travar em segundos esperando uma  ação do DBA.

Podemos ativar Resumable Space de duas formas:

1-Por Parametro do Banco resumable_timeout:
SQL> Alter system set resumable_timeout=900 scope=both;

2- Por Sessão inserindo o seguinte commando:

Para utilizar o commando abaixo é necessário privilégio RESUMABLE:

SQL> GRANT RESUMABLE TO NOME_DO_USUARIO;

SQL> Alter session enable resumable timeout 900;

Quando o usuario inserir o commando o DBA deve ficar atento monitorando com SQL e Enterprise Manager pois caso trave a rotina por estouro de Tablespace será necessário extender um datafile.Para monitoramento via SQL temos a seguinte view:
SQL> SELECT name, SQL_TEXT, STATUS, TIMEOUT FROM dba_resumable;

Poderá visualizar o problema de Alocação de Espaço em Tablespace utilizando RESUMABLE SPACE no arquivo ALERTLOG.
Exemplo:
statement in resumable session User HR(62), Session 131, Instance 1 was suspended due to
ORA-01653: não é possível estender a tabela HR.T_TESTE em 1024 no tablespace USERS.

Abraço

Bruno Murassaki