T-SQL Tuesday #19 – Disasters & Recovery


E ai? Blz? Neste mês para o T-SQL Tuesday o tema escolhido pelo Sr. (blog | twitter) foi Desastre & Recover…. Que tema chato,,, hehehe,,,

Muitas pessoas – administradores de rede, gerentes, desenvolvedores, dba´s acidentais, etc. – acham que banco de dados é a coisa mais simples do mundo, só serve pra guardar alguma informação e que aquilo vai fica sempre por lá. Esse pessoal não entende que se tem gente que é especialista em administrar banco de dados é porque por algum motivo obscuro isso é importante.

Muitos não dão valor ao trabalho do Administrador de banco até perder alguma coisa, uma boa galera acha que para manter um banco qualquer pessoa consegue, afinal, não tem muito trabalho pra fazer,,,

Ainda bem que existe esse tipo de gente,,, é ainda mais legal quando alguém me liga no meio da madrugada com aquela voz desesperada pedindo ajuda porque o servidor do banco (que era o mesmo do AD, Exchange, FileServer, DHCP) foi pro espaço e eles não estão conseguindo mais recuperar as coisas…

Muitas vezes vejo o pessoal falando sobre seus planos de backup, que contemplam X ou Y e blá blá blá,,, Mas quando pergunto qual o seu plano de recovery o pessoal olha torto e me mostra o plano de backup…

Pessoal,,,, entendam uma coisa,,,, plano de backup é bonito pra não passar feio na frente da diretoria,,, mas ter plano de recovery é o que realmente importa…

Uma coisa que pergunto pro pessoal é: “O quanto de dados você está disposto a perder?”, claro que quase sempre tenho a mesma resposta, ninguém quer perder nada,,,

Hoje em dia existem várias formas de se prevenir quando a perda de informação:

  • Backup
  • Cluster
  • Mirror
  • Log shipping
  • Replicação
  • Etc.

Claro que cada uma delas tem seus custos,,,

Manter os dados acessíveis é importante isso é disponibilidade,,, mas,,, e quando a casa caiu? Alguém aplicou alguma mudança no ambiente e apagou um monte de registro que não deveria? O storage deu rebuild da LUN e apagou todos os seus discos,,, o Windows deu tela azul…

Iai? É nessa hora que você vai descobrir que seu robô de backup não consegue ler as fitas,,, ou que o software de backup não fazia backup justamente daquela unidade ou base que você precisa… ou mais legal, quase todo o dia você cancelava a rotina de backup porque ela entrava no horário de produção, ai não fazia backup das principais bases…

Neste caso,,, parabéns !!! troca de cidade, apaga essa empresa do currículo, sai correndo,,,

Plano de desastre & recovery é igual a seguro de carro,,, você faz pra não usar,,, mas quando precisa e ele falha o que faz? Chora? Troca?

A pior coisa que pode acontecer em um momento de crise é o pânico. Mantenha a calma, com certeza vão ter pessoas desesperadas correndo que nem baratas tontas tentando qualquer coisa que lembrar ou encontrar na internet.

Lembre-se: você tem que ser assertivo, se você fez a lição de casa não existe situação que não pode ser contornada.

Seu supervisor/gerente/diretor tem que ter maturidade de segurar todas as buchas enquanto você se foca em colocar em ação o plano de desastre.

Uma dica, noticia ruim se dá na hora. Perdeu? Perdeu,,, não da pra recuperar? Já era? Avisa logo…

T-SQL Tuesday #18 – CTEs


Bom,,, para este mês o Sr. Bob Pusateri (twitter | Blog) escolheu o tópico Common Table Expressions (CTE).

Você não sabe o que é? Não faz ideia? Isso é mais comum do que você imagina,,, vejo muitos códigos por ai onde o pessoal de dev poderia utilizar este recurso, mas como ainda estão presos em conceitos antigos do SQL 2000 ou as vezes até mais velhos não fazem ideia de alguns novos recursos interessantes…

Para uma leitura interessante sobre este assunto acesse:

Você vai achar muita coisa voltada pra dev… mas,,, como sou mais um cada de infra,,, achei interessante este código no Site do Sr. Paul Randal (twitter | Blog) sobre wait statistics usando a sys.dm_os_wait_stats, nada muito complexo.

 1: WITH Waits AS
 2:     (SELECT
 3:         wait_type,
 4:         wait_time_ms / 1000.0 AS WaitS,
 5:         (wait_time_ms - signal_wait_time_ms) / 1000.0 AS ResourceS,
 6:         signal_wait_time_ms / 1000.0 AS SignalS,
 7:         waiting_tasks_count AS WaitCount,
 8:         100.0 * wait_time_ms / SUM (wait_time_ms) OVER() AS Percentage,
 9:         ROW_NUMBER() OVER(ORDER BY wait_time_ms DESC) AS RowNum
 10:     FROM sys.dm_os_wait_stats
 11:     WHERE wait_type NOT IN (
 12:         'CLR_SEMAPHORE', 'LAZYWRITER_SLEEP', 'RESOURCE_QUEUE', 'SLEEP_TASK',
 13:         'SLEEP_SYSTEMTASK', 'SQLTRACE_BUFFER_FLUSH', 'WAITFOR', 'LOGMGR_QUEUE',
 14:         'CHECKPOINT_QUEUE', 'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BROKER_TO_FLUSH',
 15:         'BROKER_TASK_STOP', 'CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT', 'DISPATCHER_QUEUE_SEMAPHORE',
 16:         'FT_IFTS_SCHEDULER_IDLE_WAIT', 'XE_DISPATCHER_WAIT', 'XE_DISPATCHER_JOIN', 'BROKER_EVENTHANDLER',
 17:         'TRACEWRITE', 'FT_IFTSHC_MUTEX', 'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
 18:         'BROKER_RECEIVE_WAITFOR', 'ONDEMAND_TASK_QUEUE', 'DBMIRROR_EVENTS_QUEUE',
 19:         'DBMIRRORING_CMD', 'BROKER_TRANSMITTER', 'SQLTRACE_WAIT_ENTRIES',
 20:         'SLEEP_BPOOL_FLUSH', 'SQLTRACE_LOCK')
 21:     )
 22: SELECT
 23:     W1.wait_type AS WaitType,
 24:     CAST (W1.WaitS AS DECIMAL(14, 2)) AS Wait_S,
 25:     CAST (W1.ResourceS AS DECIMAL(14, 2)) AS Resource_S,
 26:     CAST (W1.SignalS AS DECIMAL(14, 2)) AS Signal_S,
 27:     W1.WaitCount AS WaitCount,
 28:     CAST (W1.Percentage AS DECIMAL(4, 2)) AS Percentage,
 29:     CAST ((W1.WaitS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgWait_S,
 30:     CAST ((W1.ResourceS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgRes_S,
 31:     CAST ((W1.SignalS / W1.WaitCount) AS DECIMAL (14, 4)) AS AvgSig_S
 32: FROM Waits AS W1
 33:     INNER JOIN Waits AS W2 ON W2.RowNum <= W1.RowNum
 34: GROUP BY W1.RowNum, W1.wait_type, W1.WaitS, W1.ResourceS, W1.SignalS, W1.WaitCount, W1.Percentage
 35: HAVING SUM (W2.Percentage) - W1.Percentage < 95;
 36: GO

T-SQL Tuesday #17–Apply


O tópico deste mês para o T-SQL Tuesday é o operador apply,,,

Caso você não faça ideia de pra que serve o apply leia aqui.

Para este post vou coloca um script simples usando o apply.

Ele não faz nada muito importante, apenas mostra as 20 querys que mais gerão stress de disco:

SELECT TOP 20 SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,
((CASE qs.statement_end_offset
WHEN -1 THEN DATALENGTH(qt.text)
ELSE qs.statement_end_offset
END – qs.statement_start_offset)/2)+1),
qs.execution_count,
qs.total_logical_reads, qs.last_logical_reads,
qs.min_logical_reads, qs.max_logical_reads,
qs.total_elapsed_time, qs.last_elapsed_time,
qs.min_elapsed_time, qs.max_elapsed_time,
qs.last_execution_time,
qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
WHERE qt.encrypted=0
ORDER BY qs.total_logical_reads DESC