—————————————————–

— Criar procedure de verificação e envio de e-mail
— Alterar:
— @EmailRecipients
— @profilename

— Obs.: Deve estar configurado o Database Mail
—————————————————–

USE msdb
GO

CREATE procedure [dbo].[sp_lock_job] AS
BEGIN
create table #temp
(SPID int,
EventType nvarchar(30),
Parameters int,
EventInfo nvarchar(4000) )

DECLARE @EmailRecipients varchar(255)
SET @EmailRecipients = ‘dba@example.com’
DECLARE @profilename varchar(255)
SET @profilename = ‘DBAAlerts’

declare @spid varchar(100)
declare @blocked varchar(100)
declare @waittime int
declare @dbid int
DECLARE @dbname varchar(255)
DECLARE @vcSubject varchar(255)
DECLARE @vcMessage varchar(255)
DECLARE @SqlText varchar(4000)

Select top 1 @spid = spid,

@blocked = blocked,
@waittime = waittime/1000,
@dbid = dbid
from sys.sysprocesses
where blocked>0
and waittime > 300000
order by waittime desc

SELECT @dbname = DB_NAME(@dbid)

insert into #temp(EventType, Parameters, EventInfo)
exec (‘DBCC INPUTBUFFER(‘ + @blocked +’) WITH NO_INFOMSGS’)

Leia o resto deste post »

/*

CREATE TYPE TableParameter AS TABLE
(
TableName varchar(1000),
IndexName varchar(1000),
IndexType varchar(1000),
IndexId int,
ColumnId int,
ColumnName varchar(1000)
)

CREATE TYPE IndexParameter AS TABLE
(
TableName varchar(1000),
IndexName varchar(1000),
CountColumns int
)

CREATE TYPE TableEqualParameter AS TABLE
(
TableName varchar(1000),
IndexName varchar(1000),
IndexType varchar(1000),
IndexId int,
ColumnId int,
ColumnName varchar(1000),
TableName2 varchar(1000),
IndexName2 varchar(1000),
IndexType2 varchar(1000),
IndexId2 int,
ColumnId2 int,
ColumnName2 varchar(1000)
)
GO

DROP TYPE TableParameter;
DROP TYPE IndexParameter;
DROP TYPE TableEqualParameter;

*/

DECLARE @Index_table AS TableParameter;
DECLARE @Index_table_result AS TableParameter;
DECLARE @Index_count AS IndexParameter;
DECLARE @Index_table_equal AS TableEqualParameter;
DECLARE @TableName varchar(1000);
DECLARE @IndexName varchar(1000);
DECLARE @IndexType varchar(1000);
DECLARE @IndexId int;
DECLARE @ColumnId int;
DECLARE @ColumnName varchar(1000);
DECLARE @Count_Column int;
DECLARE @count int;
DECLARE @teste int;
DECLARE @TableNameDiff varchar(1000);
DECLARE @IndexNameDiff varchar(1000);
DECLARE @IndexTypeDiff varchar(1000);
DECLARE @IndexIdDiff int;
DECLARE @ColumnIdDiff int;
DECLARE @ColumnNameDiff varchar(1000);
DECLARE @Count_ColumnDiff int;

Leia o resto deste post »

Ao tentar instalar o plugin do Oracle Database na versão 12.1.0.1.0  no Red Hat 4.8 foi apresentado o seguinte erro:

u01/app/oem/agent12c/core/12.1.0.1.0/bin/nmocat: error while loading shared libraries: requires glibc 2.5 or later dynamic linker

Ao verificar a certificação de matrix do agent para o OS em questão, vi que somente a versão 32 bits está liberada, mesmo o sistema sendo 64 bits.

Screen Shot 03-22-16 at 10.46 AM.PNG

Com isso, tive que desinstalar o agent 64 bits e instalar o de 32 bits seguindo os seguintes passos:

1) Parar o OEM Agent.

emctl stop agent

2) Deletar os targets do OEM. (Servidor do OMS)

emcli delete_target -name=”mtzsrverpprod.com:1836″ -type=”oracle_emd” -delete_monitored_targets

3) Desinstalar o OEM Agent pelo OUI gráfico.

$AGENT_HOME/oui/bin/runInstaller -deinstall ORACLE_HOME=/u01/app/oracle/agent/core/12.1.0.1.0/ -removeallfiles

– Remover os plugins primeiro.
– Depois remover o sbin.
– E por último, remover o agent.

4)  Via OEM Cloud Control, instalar o Agent e o Plugin do Oracle Database no servidor em questão.

Screen Shot 03-23-16 at 02.56 PM.PNG

Depois o monitoramento funcionou normalmente.

Links:
12c Plugin Deployment Failed with requires glibc 2.5 or later dynamic linker (Doc ID 1504584.1)
Deinstalling Oracle Management Agents

 

Otimizando o tamanho do Redo Log

Publicado: março 7, 2016 em Uncategorized

Bem, para começar vamos primeiro entender melhor o que é o Redo Log. O Redo Log é o arquivo de banco de dados que armazena todas as alterações realizadas no banco, essas informações são essenciais para restaurar o banco de dados em caso de falhas. Por isso, a extrema importância desses arquivos.

Para retirar os dados do log buffer (estrutura de memória), o Oracle realiza o flush dessa estrutura nos seguintes cenários:
– A cada 3 segundos.
– A cada commit.
– Quando está 1/3 cheio.
– Quando está com 1 MB de dados.

Para realizar essa ação, ele utiliza o processo de background LGWR. Ele, por sua vez, escreve no grupos de redo log existentes de maneira cíclica. Ou seja, quando termina de escrever no último grupo de redo log, ele voltará para o primeiro grupo, sobrescrevendo os dados existente no mesmo. Como demonstrado na figura abaixo.
Screen Shot 03-07-16 at 01.30 PM.PNG
Leia o resto deste post »

Flashback Database

Publicado: março 4, 2016 em Features, RMAN, Uncategorized
Tags:

O database, a fronteira final. Essas são as viagens da nave na edição Enterprise, em sua missão de vários restore points, para explorar novos mundos, buscar novas formas de Flashback, novas incarnations. Audaciosamente indo, aonde nenhum DBA jamais esteve.

Para a abordagem do Flashback Database resolvi fazer uma brincadeira com o filme Star Trek, dirigido pelo J. J. Abrams. Pois vi uma certa semelhança na forma como o roteiro foi feito para utilizarem os antigos personagens do ponto onde a história tinha parado, porém iniciando uma história alternativa com o funcionamento do Flashback Database da Oracle.

No filme, Spock, seguindo a linha do tempo original, promete aos romulanos salvar o planeta deles utilizando uma tecnologia vulcana. Porém, a missão não termina com sucesso e o planeta é destruído. E como resultado, um romulano o persegue na tentativa de se vingar. Com isso, Spock sente-se obrigado a entrar em um buraco negro criado por ele mesmo, ocasionando a volta dele para um determinado ponto do passado. Após o fato de Spock voltar parcialmente no tempo, é gerada uma realidade paralela. Alterando assim, o curso da vida para um novo futuro.

Imagine se Spock fosse um DBA em vez de vulcano (coisas bem parecidas, pois os dois não podem demonstrar emoções e devem ser muito racionais, na hora da pressão), e ao aplicar scripts para correção de erros no banco de dados, ocorressem problemas alarmantes e precisasse recuperar o banco para o momento anterior. Ele teria a opção de utilizar a tecnologia Flashback Database. Criaria um restore point anteriormente à aplicação dos scripts com alterações no banco de dados, e após o acontecimento dos erros, voltaria a base ao restore point criado ou à um tempo passado após o restore point. E como para ter acesso ao banco onde foi utilizado o Flashback, deve ser utilizado o Resetlogs ao abri-lo, criaria uma nova linha do tempo para o banco, chamada também de nova Incarnation.

Vamos agora para a parte prática desse recurso!
Leia o resto deste post »

Opa, Pessoal!

Recentemente passei na certificação do Oracle Enterprise Manager 12c Essentials (1Z0-457). Então resolvi compartilhar os materiais que utilizei para estudar para ela.

Guia de estudo:

Oracle Enterprise Manager 12c Essentials Exam Study Guide

Livros:
Oracle Enterprise Manager Cloud Control 12c Deep Dive
Expert Oracle Enterprise Manager 12c

Link da Documentação Oficial do produto:
Oracle Enterprise Manager Cloud Control Documentation 12c Release 4

Dica:
É importante ler White Papers da Oracle sobre alguns recursos que a ferramenta oferece. Pois a prova foi menos técnica do que pensei. Então é bom só entender como esses recursos funcionam. Exemplo:
Enterprise Manager 12c Cloud Control Metering and Chargeback

Então é isso! Divirtam-se nos estudos!

Estarei falando nesse post sobre a configuração e execução Automatic SQL Tuning. Tarefa que é executada automaticamente nas janelas de manuntenção do banco de dados e utiliza o SQL Tuning Advisor (STA) para obter recomendações de melhorias nas querys mais pesadas encontradas nas estatísticas do AWR.
    
O Automatic SQL Tuning tem diversos parâmtros que compõe a sua configuração, tais como:
– ACCEPT_SQL_PROFILES: Aceita automáticamente os SQL Profiles recomendados para as instruções SQL.
– TIME_LIMIT: Tempo total para execução do Automatic SQL Tuning.
– LOCAL_TIME_LIMIT: Tempo para execução da análise de cada SQL selecionado.
    
Para consultar os parâmetros do Automatic SQL Tuning utilizo a seguinte query:
SET lines 200 pages 100
col DESCRIPTION FOR a100
col parameter_value FOR a15
SELECT parameter_name,parameter_value,is_default,description
 FROM DBA_ADVISOR_PARAMETERS
 WHERE task_name='SYS_AUTO_SQL_TUNING_TASK'
ORDER BY parameter_name;    
    
Agora vamos habilitar
– Idenficar melhores caminhos e objetos que satisfaçam a possibilidade de utilizá-los (indexes, materialized views).
– Restruturação da instrução.