Agent XPs disabled

Quem nunca se deparou com esta situação e por isso pensei que seria útil escrever a respeito. Os jobs não estavam sendo executados mas o SQL Server Agent estava rodando nos serviços do Windows. Clicando com o botão direito sobre o Agent as opções de Start, Stop e Restart estão lá mas não é possível iniciar com o seguinte erro:

 

 

 

Ao lado do SQL Server Agent, um aviso entre parênteses:

 

 

Isto acontece porque nas configurações avançadas, o Agent XPs está com o valor 0. Geralmente este valor é automaticamente configurado para 1 na instalação mas por algum motivo esta configuração falhou e agora está com o valor 0. Também acontece se a base MSDB estiver com acesso RESTRICTED USER.

Para resolver vamos ativar as configurações avançadas e configurar o Agent XPs utilizando o sp_configure. Através do sp_configure podemos alterar diversas configurações do SQL, vamos executar sp_configure apenas para ver as configurações atuais:

 

 

Nesta lista temos os itens que podemos configurar e os possíveis valores mínimos, máximos, configurados e utilizados atualmente. Repare que apesar de termos diversas configurações, a opção Agent XPs não está nesta lista, mas na linha 15 temos a opção show advanced options com os valores 0 no configurado e também 0 no utilizado atualmente.

Vamos alterar para 1, para que as opções avançadas passem a fazer parte desta lista:

sp_configure ‘show advanced options’,1

A sintaxe é sempre esta – sp_configure ‘opção entre aspas simples’, valor

 

 

Veja que a mensagem diz que a configuração mudou de 0 para 1 mas é necessário executar o RECONFIGURE para que esta configuração entre em vigor. Para entendermos melhor, vamos executar o sp_configure novamente para vermos as configurações atuais:

 

 

 

Veja que agora a configuração é 1 mas o que está em execução ainda é 0, ou seja, ainda não foi aplicado. Agora vamos rodar o RECONFIGURE:

 

 

E agora vamos ver as configurações novamente com o sp_configure:

 

 

Agora temos todas as opções configuráveis, veja que nosso Agent XPs está com o valor 0 mas já vamos alterá-lo:

 

sp_configure ‘Agent XPs’,1
RECONFIGURE 

 

Dê um refresh e veja que o Agent já está normalizado. Pode ser que seja necessário iniciá-lo manualmente, ou seja, clicar com o direito e depois em Start.

 

Identificando o tempo de Backup /Restore

Olá Pessoal,

 

 

Hoje me perguntaram como fazer para identificar o tempo de backup/restore em execução.

Sendo assim, resolvi postar o script capaz de trazer esta informação.

 

 

 

-- Verifica Tempo restante de Backup /restore

--  Funciona no SQLSEVER 2005, 2008 e 2008 R2

 

SELECT start_time,

       (total_elapsed_time/1000/60) AS MinutesRunning,

       percent_complete,

       command,

       b.name AS DatabaseName,

              -- MASTER will appear here because the database is not accesible yet.

       DATEADD(ms,estimated_completion_time,GETDATE()) AS StimatedCompletionTime,

      (estimated_completion_time/1000/60) AS MinutesToFinish

FROM  sys.dm_exec_requests a

          INNER JOIN sys.DATABASES b ON a.database_id = b.database_id

WHERE command LIKE '%restore%'

          OR command LIKE '%backup%'

          AND estimated_completion_time > 0

Oracle x Db2 comparativo

Pessoal, achei este material  legal ..  e resolvi compartilhar

A instalação em Oracle: com root criamos os grupos, usuário Oracle e nele fizemos a instalação de binários, criação de instância e para RAC segue a mesma linha. Se precisamos de mais uma instância criaremos mais um usuário. Em DB2: pode ser instalado em um usuário normal o binário, mas é sugerido instalar o binário como root por ser mais seguro não apagar os binários erroneamente. Após isso cada usuário de SO pode criar a sua instância, seu(s) database(s).

Os usuários em Oracle: dentro da instância create user. Em DB2: é necessário que o usuário seja do SO.

As configurações realizadas em Oracle: do banco e da instância é tudo junto. Em DB2: existe do DB (banco de dados) é da DBM (instância) essas são separadas.

Os logs de alertas do banco em Oracle: Quem nos auxilia muito é ‘Alert.log’ além de possuirmos os trace files. Em DB2: tem um semelhante com o nome de db2diag.log (inclusive este db2diag.log possui uma ferramenta para filtro do db2diag.log chamada db2diag). O List History File (db2 list history …) armazena informacoes sobre backup, restore, criacao – alteracao – delecao de tablespaces, quando uma tabela sofre alguma alteracao ou reorganizacao etc (db2 list history …).

As tablespaces tem o mesmo príncípio mas em Oracle: Temos os Datafiles. Em DB2: Temos os Conteiners.

Comparações dos comandos entre os dois:

No Oracle temos o Automatic Storage Management (ASM) e no DB2 Automatic Storage Table Space que trabalha exclusivamente com Storage, diferente do ASM nesse ponto.

Também tem uma ferramenta semelhante (ou melhor) de SQL LOADER (sqlldr) que é DB2 Load Utility, esse teria que instalar e começar a rodar, mas parece melhor.
Outras ferramentas de exportação e importação tipo o DATA PUMP do Oracle, me parecem meio fracas, chamam DB2 Export Utility e DB2 Import Utility. Existe outras duas a DB2LOOK Utility que exporta todo o database em DDL e DB2MOVE Utility que copia ou move schemas entre databases, também executa as funções do Export Utility e Import Utility acima citado.

O Oracle RAC tem uOraclem concorrente forte (no meu ponto de vista nesse momento, sem testar é claro) chamado pureScale que parece realmente melhor que o RAC, pois vem de toda a expertise da IBM em trabalhar com processamento distribuído.

Também possui o particionamento de tabelas, pouco diferente, terei que executar testas para citar corretamente as diferenças.

As views materializadas do Oracle são chamados de MQT no DB2, a idéia é a mesma.

A compressão de dados do DB2, segundo o instrutor é bem melhor que do Oracle, no entando disse que quase nem é necessário executar rebuild de indices quando temos muitas exclusões, que esse processo de compactação se encarrega disso. Esse sim, merece um teste com um comparitivo forte entre eles, quero ver se faço isso, mas não deve ser em breve.

Uma visão geral dessa comparação:

 

 

O IBM DB2 versão 9.7 já possui um compilador próprio para PL/SQL, sendo assim não precisa ficar ‘executando um de – para’ em toda a análise, já faz a compilação e grava da forma como o interpretador precisa. Para o TSQL (SQL Server e Sybase) que é bem parecido com SQL PL do DB2 existe esse de – para, passando pelo mesmo compilador gravando da forma que o interpretador precisa.

O interpretador nesse caso será o mesmo para as duas saídas, a figura abaixo mostra isso:

Para que esse interpretador funcione, essa opção precisa ser configurada DB2_COMPATIBILITY_VECTOR, abaixo quais as features que podem ser habilitadas, as com * precisam fazer o procedimento de parar e iniciar a instância. Para habilitar todas de uma vez utilizar palavra ORA:

Criando um database com todas as features habilitadas:

Obs.: O database tem que ser criado depois que é habilitada a compatibilidade ou não serão utilizadas, pois ficará um database nativo DB2.

Alguns tipos de dados e onde eram os maiores problemas nas migrações em versões anteriores, que agora podem não ser tão problemáticas:

Uma outra coisa que achei interessante (ou não, a prática daria essa resposta) é que pode ‘misturar’ o PL/SQL, TSQL e SQL PL no desenvolvimento dos mesmos objetos (function or procedures), poderia rolar pegar o que cada uma tem de melhor e fazer acontecer, agora, isso como mencionei somente o desenvolvimento do dia a dia daria a resposta, mas seria interessante avaliar.

Itens que no PL/SQL estão funcionais são alguns que utilizo diariamente e acabei listando abaixo sem ter certeza como era/é no DB2 (precisaria testar tudo para dar um veredito final e ai sim ter certeza):
– Os cursores, para retornos em procedures;
– Utilização normal de de Packages.Procedures e Packages.Funcitions;
– Os privilegios para outras roles (usuários) executar, normal;
– Utilização do %type para tabela.campo e %rowtype para tabela na declaração de variáveis;

 

Verificando consumo de CPU por banco de dados

Verificando consumo de CPU por banco de dados

Olá pessoal, o script abaixo é capaz de verificar o consumo de CPU por database. Ele poder se muito útil na administração de ambiente.

WITH DB_CPU_Stats

AS
(SELECT DatabaseID, DB_Name(DatabaseID) AS [DatabaseName], SUM(total_worker_time) AS [CPU_Time_Ms]
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY (SELECT CONVERT(int, value) AS [DatabaseID]
FROM sys.dm_exec_plan_attributes(qs.plan_handle)
WHERE attribute = N'dbid') AS F_DB
GROUP BY DatabaseID)
SELECT ROW_NUMBER() OVER(ORDER BY [CPU_Time_Ms] DESC) AS [row_num],
DatabaseName, [CPU_Time_Ms],
CAST([CPU_Time_Ms] * 1.0 / SUM([CPU_Time_Ms]) OVER() * 100.0 AS DECIMAL(5, 2)) AS [CPUPercent]
FROM DB_CPU_Stats
WHERE DatabaseID > 4 -- system databases
AND DatabaseID <> 32767 -- ResourceDB
ORDER BY row_num OPTION (RECOMPILE);

 

ENTENDENDO OS DEADLOCKS

Os DeadLocks ocorrem quando existe um ciclo de dependência entre duas ou mais transações pelo mesmo recurso. Uma transação (T1) pode adquirir um ou mais recursos (por exemplo, locks). Se o recurso sendo adquirido por T1 já estiver sendo utilizado por outra transação (T2), T1 terá que aguardar a segunda transação (T2) liberar o recurso desejado. Neste caso, dizemos que T1 tem uma dependência de T2, que mantêm o recurso.

Agora imagine que a transação que mantêm o recurso (T2), também quer adquirir um recurso que está sendo utilizado pela primeira transação (T1). Esta situação ocasiona o famoso deadlock - ambas as transações não podem liberar os recursos que elas utilizam até elas serem concluídas (commit) ou desfeitas (rollbak) e estas transações não podem ser concluídas ou desfeitas porque elas estão aguardando por recursos uma das outras. Confuso?

Para tentar melhorar o entendimento, vamos a um exemplo:

Imagine que você possui uma aplicação e que a mesma abre duas transações no servidor, T1 e T2. A transação T1, adquiri um lock exclusivo na tabela Supplier. A transação T2, adquiri um lock exclusivo na tabela Part e também tenta adquirir um lock na tabela Supplier. A transação T2 não pode obter o lock porque T1 já possui o recurso, sendo assim, a transação T2 é bloqueada e fica aguardando pela conclusão da transação T1.

Enquanto isso, a transação T1 também tenta adquirir um lock na tabela Part, mas não pode obter o lock porque a transação T2 já possui o recurso. As transações não podem liberar os recursos até que elas sejam efetivadas (commit) ou desfeitas (rollback), porém, as transações não podem ser efetivadas ou desfeitas porque para continuar, estão aguardando pelo recurso uma da outra. Ou seja, T1 espera pela conclusão de T2 que espera pela conclusão de T1.

Na ilustração abaixo, a Transação 1 está aguardando a Transação 2 liberar o Lock na tabela Part, enquanto a Transação 2 também está aguardando a Transação 1 liberar o Lock na tabela Supplier.

Para resolver o deadlock, uma das transações do ciclo precisa ser derrubada e para escolher a "vítima" do deadlock, o SQL Server 2000 verifica todas as threads que estão participando da transação e o quanto estão sendo utilizadas. Geralmente, o SQL Server escolhe a thread que esta trabalhando menos para ser a "vítima" do deadlock. Quando um deadlock ocorre, o usuário recebe a seguinte mensagem de erro (Error 1205):

Your transaction (process ID #52) was deadlocked on {lock | communication buffer | thread} resources with another process and has been chosen as the deadlock victim. Rerun your transaction.

O DBA também pode verificar a ocorrência de deadlocks no error log do SQL Server. Por default, os deadlocks não são logados no error log do SQL Server mas o DBA pode habilitar esta funcionalidade ativando os trace flags 3605 e 1204 no QA.

-- Ativa os trace flags
dbcc traceon (1204, 3605, -1)
go
-- Mostra os trace flags ativos no servidor
dbcc tracestatus(-1)
go

O trace flag 1204 coleta informações sobre os processos e os recursos utilizados quando um deadlock for detectado e o trace flag 3605 escreve estas informações para o error log do SQL Server.

Uma vez estando ativos estes trace flags, sempre que ocorrer um deadlock o SQL Server adicionará em seu erro log uma mensagem semelhante a apresentada abaixo:

Deadlock encountered .... Printing deadlock information
2005-04-06 10:31:09.01 spid3                          
2005-04-06 10:31:09.01 spid3     Wait-for graph       
2005-04-06 10:31:09.01 spid3                          
2005-04-06 10:31:09.01 spid3     Node:1               
2005-04-06 10:31:09.01 spid3     RID: 16:1:112430:3             CleanCnt:1 Mode: U Flags: 0x2
2005-04-06 10:31:09.01 spid3      Grant List 2::                                            
2005-04-06 10:31:09.01 spid3        Owner:0x6f724b60 Mode: U        Flg:0x0 Ref:0 Life:00000001...
2005-04-06 10:31:09.01 spid3        SPID: 191 ECID: 0 Statement Type: UPDATE Line #: 352
2005-04-06 10:31:09.01 spid3        Input Buf: RPC Event: sp_deadlock1             
2005-04-06 10:31:09.01 spid3      Grant List 3::                                       
2005-04-06 10:31:09.01 spid3      Requested By:                                        
2005-04-06 10:31:09.01 spid3        ResType:LockOwner Stype:'OR' Mode: U SPID:68 ECID:0....
2005-04-06 10:31:09.01 spid3                                                                
2005-04-06 10:31:09.01 spid3     Node:2                                                     
2005-04-06 10:31:09.01 spid3     RID: 16:1:101962:22            CleanCnt:1 Mode: X Flags: 0x2
2005-04-06 10:31:09.01 spid3      Grant List 3::                                            
2005-04-06 10:31:09.01 spid3        Owner:0x6b119400 Mode: X        Flg:0x0 Ref:0 Life:02000000...
2005-04-06 10:31:09.01 spid3        SPID: 68 ECID: 0 Statement Type: UPDATE Line #: 251
2005-04-06 10:31:09.01 spid3        Input Buf: RPC Event: sp_deadlock2
2005-04-06 10:31:09.01 spid3      Requested By:                                    
2005-04-06 10:31:09.01 spid3        ResType:LockOwner Stype:'OR' Mode: U SPID:191...
2005-04-06 10:31:09.01 spid3     Victim Resource Owner:                         
2005-04-06 10:31:09.01 spid3      ResType:LockOwner Stype:'OR' Mode: U SPID:191...

Com o log acima é possível obter as seguintes informações:

-- As conexões que causaram o deadlock ==> SPID: 191 e SPID: 68
-- A base de dados ==> RID: 16 (select db_name(16), para saber o nome da base)
-- Os objetos envolvidos no deadlock ==> procedures sp_deadlock1 e sp_deadlock2
-- O número das linhas dentro das procedures onde provavelmente ocorreu o deadlock ==>  UPDATE Line #: 352 e UPDATE Line #: 251

Neste exemplo, se abrirmos as procedures sp_deadlock1 e sp_deadlock2 e navegarmos até o número das linhas indicado, teremos os statements que causaram o deadlock.

MINIMIZANDO OS DEADLOCKS

É muito difícil eliminar os DeadLocks completamente, entretanto, o número de deadlocks pode ser minimizado. Minimizando os deadlocks, podemos aumentar o throughput das transações e reduzir o overhead do sistema.

Algumas das atividades que um DBA ou desenvolvedor podem estar reallizando para minimizar a ocorrência de deadlocks são as seguintes:

A) Acessar os objetos na mesma ordem: Se todas as transações acessarem os objetos na mesma ordem, será pouco provável ocorrer um deadlock. No exemplo abaixo, se duas transações concorrentes obterem lock na tabela Supplier e depois na tabela Part, uma delas ficará bloqueada na tabela Supplier até a outra transação terminar, então, a segunda continua e o DeadLock não ocorrerá.

B) Evitar a interação de usuários nas transações: Deve-se evitar transações de escritas que incluem a interação de usuários, porque a velocidade de execução de um batch sem a intervenção de usuários é muito maior em relação ao tempo de resposta de uma query executada manualmente por um usuário. Por exemplo, se uma transação está esperando por uma entrada (input) de um usuário e o usuário foi tomar um cafezinho, a transação ficará esperando para poder ser concluida. Mesmo se não ocorrer uma situação de deadlock, outras transações que acessem o mesmo recurso serão bloqueadas esperando que a transação seja concluída ou desfeita.

C) Fazer transações curtas e em um único batch: Um deadlock ocorre tipicamente quando executamos transações de longa duração concorrendo no mesmo objeto. Em uma transação muito longa, a possibilidade de locks exclusivos ou de update é muito maior,  o que bloqueia outras atividades e ocasiona possíveis situações de DeadLocks. Procure manter as transações em um único batch (uma batch termina quando você coloca a palavra GO), assim minimizamos o tráfego de rede durante a transação e reduzimos possíveis atrasos para completar a transação.

D) Use um nível de isolamento baixo: Determinar se a transação pode rodar em um nível de isolamento baixo. Implementando um nível de isolamento alto como o  "read commited", somente será permitido que a transação leia dados que não estão sendo alterados, ou seja, se estiver sendo efetuada alguma alteração,  a transação de leitura ficará bloqueada até que a alteração seja concluída. Um recurso muito utilizados pelos desenvolvedores é a utilização da HINT NOLOCK nos statements menos significativos.

Exemplo: SELECT au_lname FROM authors WITH (NOLOCK)

Links Relacionados:

KB832524: SQL Server technical bulletin - How to resolve a deadlock
Tips for Reducing SQL Server Deadlocks

Para saber mais sobre Hints no SQL Server, consulte por "locking, hints" no Books Online do SQL Server, ou abra o link mk:@MSITStore:C:Program%20FilesMicrosoft%20SQL%20Server80ToolsBooksacdata.chm::/ac_8_con_7a_1hf7.htm em uma máquina que tenha o BOL instalado.