E agora DBA?

T-SQL Fast Tips - Qual foi o último boot do servidor SQL?

2012-01-16T13:32:00.000-08:00

Senhores, Senhoras e Senhoritas DBAs!!!

Essa é dica rápida e descaradamente copiada de Adeilson Brito (blog) !

Como identificar qual foi o ultimo Boot do seu servidor??

Na SQL 2008 em diante sua vida foi simplificada com a dm sys.dm_os_sys_info

SELECT

sqlserver_start_time Iniciou_Em

FROM

sys.dm_os_sys_info

No post do sr. Brito, você pode checar o método para fazer o mesmo na versão 2000, veja o link!

Abraços!!!

T-SQL Tips - Grandes UPDATES em Blocos, seu arquivo de log agradece!

2012-01-04T14:13:00.000-08:00

/*

Olá Senhores, Senhoras e Senhoritas DBAS!!!

Um Feliz 2012 (e um Feliz SQL Server 2012) para todos nós!!!

Para começar o ano, quero explicar uma interessante técnica de como fazer para executar grandes updates em blocos menores.

Mas porque eu devo me preocupar com isso?

(PARTE TEÓRICA, se não interessar, pule para a prática!)

A questão está no nosso esquecido LDF!

Todo DB do SQL Server é composto, no mínimo, por dois arquivos. Um MDF, onde estão armazenadas os objetos, tabelas e indices do banco e um arquivo LDF que é o nosso arquivo de Log.

Quando você inicia um Update ou Insert em uma tabela, todos os dados que serão alterados são armazenados no arquivo de Log. Se você cancelar uma transação no meio do caminho, esse “backup” garante que o banco volte ao status anterior ao seu comando.

Talvez você já tenha notado que quando você reinicia o serviço do SQL, as bases de dados entram em estado “In Recovery”, que basicamente, é a operação de rollback de todas as transações que não foram concluídas no momento do crash (UNDO) e a garantia de que as transações comitadas que estavam na memória estejam devidamente escritas no arquivo de dados(REDO).

O arquivo de log também é um arquivo circular, ou seja, conforme as transações vão sendo comitadas e transferidas para o MDF o espaço que elas ocupavam no LDF é truncado e pode ser reutilizado para novas operações.

Então, quando você faz um update grande e o espaço livre atual do arquivo de log não é suficiente, você obriga que arquivo de log a crescer para comportar a mudança. Isso acarreta em lentidão na transação (pois é uma operação a mais) e também a fragmentação do seu arquivo de log que pode causar uma depreciação na performance de todo o banco.

Portanto, quebrar um grande update em pequenos blocos, garante que o arquivo de log libere espaço para ser reutilizado e evita seu crescimento.

No final do artigo coloquei um artigo do Paul Randal que é a referencia forte desse post e é bem aprofundada no assunto.

Tá legal, e como eu faço isso?

(PARTE PRATICA!)

-- Primeiro vamos criar nosso banco de teste, mudando o Recovery Mode para Simple, o que evita a necessidade de -- um backup de log para truncar o log.
*/

CREATE Database Teste
GO
ALTER DATABASE Teste SET RECOVERY SIMPLE
GO

use Teste

-- Dando uma olhada nos arquivos criados.

sp_helpfile
GO

name fileid size

--------- ------ ------------------
Teste 1 2304 KB
Teste_log 2 576 KB

-- Agora vamos criar e popular nossa tabela de teste.
CREATE TABLE Tabela (Campo char(1003) NOT NULL)
GO

INSERT INTO Tabela VALUES (REPLICATE('X',1003))

GO 576

/*

Uma nova checagem no tamanho mostra que não houve um crescimento no log. Em meu lab algumas vezes o log cresceu para pouco mais de 800 Kb. Como era um comportamento intermitente foi dificil acha a razão. Só achei no fim desse artigo!

sp_helpfile

name fileid size

--------- ------ ------------------
Teste 1 2304 KB
Teste_log 2 576 KB

Vamos dar uma olhada também na quantidade de VLFs (virtual log files) existentes dentro do arquivo de log. Isso nos da uma noção da fragmentação desse arquivo (mais informações sobre VLFs, leia o artigo no final do post).
*/

DBCC LOGINFO

FileId FileSize StartOffset FSeqNo Status

----------- -------------------- -------------------- ----------- -----------
2 253952 8192 86 2
2 327680 262144 0 0

(2 row(s) affected)

-- OK. Cenário pronto vamos ao grande update.

UPDATE Tabela

SET Campo = REPLICATE('Y',1003)

-- Seguem resultados

sp_helpfile

name fileid size

--------- ------ ------------------
Teste 1 2304 KB
Teste_log 2 2624 KB

DBCC LOGINFO

FileId FileSize StartOffset FSeqNo Status

----------- -------------------- -------------------- ----------- -----------
2           253952               8192                 88          0
2           327680               262144               89          2
2           262144               589824               90          2
2           262144               851968               91          2
2           262144               1114112              92          2
2           262144               1376256              93          2
2           262144               1638400              94          2
2           262144               1900544              0           0
2           262144               2162688              0          0
2           262144               2424832              0           0

(10 row(s) affected)

Explodiu! O tamanho do log passou até mesmo o tamanho do arquivo de dados.

Como eu disse acima, isso se deu porque foi necessário que toda a tabela Teste estivesse armazenada no arquivo de log como garantia que no caso de um rollback, as informações pudessem voltar ao estado original.

Vamos agora refazer o banco, a tabela e a população e fazer o update de forma diferente.

DECLARE @Contador int = 1

WHILE @Contador <= 576

BEGIN

UPDATE top (1) Tabela

            SET Campo = REPLICATE('Y',1003)
      WHERE
                  Campo = REPLICATE('X',1003)

SET @Contador = @Contador + 1

END

O contador soma um para cada iteração e o update (por conta do Top (1)) só afeta uma linha por vez. Assim sendo, são 576 iterações e apenas uma linha por update. Isso deve resolver o assunto, certo?

sp_helpfile

name fileid size

--------- ------ ------------------
Teste 1 2304 KB
Teste_log 2 1088 KB

DBCC LOGINFO

FileId FileSize StartOffset FSeqNo Status

----------- -------------------- -------------------- ----------- -----------
2           253952               8192                 94          0
2           327680               262144               93          0
2           262144               589824               95          2
2           262144               851968               92          0

(4 row(s) affected)

/* ERRADO!!! Teoricamente não deveria, mas ocorreu um aumento, menor que no caso do update seco, mas tivemos!

Porque será? O mesmo ocorreu algumas vezes no processo de Insert apesar de serem inserções em bloquinhos de uma linha.

Bem, a única razão aparente é que o processo de truncar o log é assíncrono e decidido pelo SQL Server. De forma que, como o update da tabela Teste é bem rápido, não está dando tempo para o SQL truncar o espaço já comitado antes de ele ser requisitado pelo novo update do loop.

Para provar a teoria, coloquei um CHECKPOINT após cada update para garantir que todas as paginas em memória fossem escritas no disco e permitissem o SQL truncar o arquivo de log. E bingo! O tamanho se manteve em 576 Kb, apesar da operação ter demorado muuuuuuito mais.

ATENÇÂO: O uso do CHECKPOINT não deve estar no seu código, ele é administrativo e não uma função que deve ser executada a todo momento. Ele só serviu para provar a teoria.

Enfim, espero que isso tenha ajudado você. Se tiver dúvidas, criticas ou sugestões de tema, me mande um email fjantunes@gmail.com ou me twitta no @felipe_store.

Abraços e Obrigado!!!

Fonte:

Understanding Logging and Recovery in SQL Server – Paul Randal
http://technet.microsoft.com/en-us/magazine/2009.02.logging.aspx

TroubleShooting - DEADLOCK, como acontecem!

2011-12-23T10:33:00.000-08:00

/* Olá Senhores, Senhoras e Senhoritas DBAS!!!

Existe um erro muito comum no SQL , mas que poucas pessoas entendem o que significa. Ele se chama DEADLOCK.

Geralmente é assim que ele se apresenta

Msg 1205, Level 13, State 45, Line 2

Transaction (Process ID 194) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

Msg 1205, Level 13, State 45, Line 2

A transação (ID do processo 194) entrou em deadlock em bloquear recursos com outro processo e foi escolhida como a vítima do deadlock. Execute a transação novamente.

-- O que é o DEADLOCK?

Basicamente significa que a transação A requisitou um recurso que está sendo utilizado pela Transação B e que a transação B está requisitando um recurso trancado pela transação A. Ou seja, entramos em um Loop, onde A está esperando B concluir e B só conclui quando A terminar.

Quando o SQL Server detecta essa situação ele mata o processo com rollback menos custoso ou pela transação mais velha.
Mas nada melhor para entender do que um exemplinho.

-- Abra uma query no seu Managment Studio e rode o seguinte código

use TabelasTemporarias

CREATE TABLE Tabela1 (Valor int)

CREATE TABLE Tabela2 (Valor int)

-- Agora vamos fazer a transação A. Iniciando uma transação e inserindo um valor -- na tabela 1. Não commite

BEGIN TRAN

INSERT INTO Tabela1 VALUES (0)

-- Abra uma nova query e crie a transação B, inserindo um valor na tabela 2.

-- Não comite.

BEGIN TRAN

INSERT INTO Tabela2 VALUES (0)

-- Volte para a primeira query e execute um SELECT na tabela 2

SELECT * FROM Tabela2

-- Você vai notar que a query vai ficar executando sem concluir, pois ela está

-- esperando pelo primeiro processo. (vide query abaixo)

SELECT

      r.session_id [SessionID da Tran A],
      r.blocking_session_id [SessionID da Tran B],
      r.wait_type
FROM
      sys.dm_tran_locks l
inner join sys.dm_exec_requests r on l.request_session_id = r.session_id
WHERE
      request_status = 'WAIT'

/*
SessionID da Tran A SessionID da Tran B wait_type
------------------- ------------------- -----------------------------------------

194 391 LCK_M_S

-- Ou seja, ja estamos no ponto onde A depende de B.

-- Por fim, vamos fazer B depender de A.

-- Na query da transação B, execute um select na Tabela 1.

SELECT * FROM Tabela1

-- E Voilá! Em poucos segundos você terá um erro matando a transação A.

/* O intuito aqui é só mostrar o que acontece, pois acredito que entender o problema é a melhor forma de resolve-la, para formas de reduzir o Deadlock e entende-lo profundamente seguem dois links oficiais

http://msdn.microsoft.com/en-us/library/ms178104.aspx

http://msdn.microsoft.com/en-us/library/ms191242.aspx

Se tiver duvidas, sugestões e reclamações me mande um email!

fjantunes@gmail.com

Abraços e Feliz Natal!!!

T-SQL Tips - Checar existência de Tabela Temporária!

2011-12-13T13:46:00.000-08:00

Senhores,

Como faz meses que não coloco algo novo no blog, vou oferecer para vocês uma dica bem rápida.

Como checar a existencia de uma tabela temporária!!!

Achava que era impossivel ou extremamente complexo. Mas na verdade é bem simples!!

CREATE TABLE #MeuTesteTemporario (Coluna1 int, Coluna2 varchar(100))

-- E aqui está o pulo do gato!!

-- Ao invés de um EXISTS na sys.objects, use a função OBJECT_ID

IF OBJECT_ID('TempDb.dbo.#MeuTesteTemporario') IS NOT NULL

DROP TABLE #MeuTesteTemporario

Simples, fácil, descomplicado!

Obrigado Simon Sabin!

Crônica Corporativa - O Militar e o telefone.

2011-09-19T16:16:00.000-07:00

Há muito tempo atrás estava jogando conversa fora com um amigo cujo pai era militar. Ele me contava que achava muito estranho o jeito que o pai dele atendia ao telefone quando estava em serviço. A conversa era seca e sem rodeios, ele já atendia falando o próprio nome, pulava todos os “bons dias” e “como vais” tão comuns em nosso dia-a-dia e após responder perguntas desligava às vezes sem nem dizer um tchau.

A princípio quando você se depara com uma situação assim, a primeira impressão é de que você está falando com uma pessoa bem mal–educada, mas se analisarmos com quem estamos falando, não daria para esperar outra coisa.

Vendo um exército como uma corporação, é logico esperar que a cultura organizacional seja baseada em um espirito de combate. Em um combate, o telefone não é um canal para conversar e fazer amizades, ele é um meio de comunicação e na guerra comunicação é recurso. E recurso, principalmente em situações extremas, deve ser usado com economia e eficiência. Identifique-se, passe a mensagem, libere o canal. Sem desperdício, sem perda de tempo.

Da mesma maneira funciona o combate real, o caso extremo, os soldados estão atirando uns nos outros e se você é um cabo com meia dúzia de soldados ao seu comando e vê o inimigo sorrateiramente se aproximando, você não vai virar para um deles e dizer:

- Com licença soldado?

- Pois não senhor. - responderia o soldado solícito.

- Como está tudo bem? – você perguntará com um sorriso.

- Tudo ótimo, senhor, obrigado por perguntar. Em que posso ser útil?

- Soldado, você poderia, por favor, atirar naquele soldado inimigo que está chegando para nos matar.

E o soldado não responderia, pois ele já estaria morto. E provavelmente você também.

Muito disso acontece no nosso mundo corporativo. Não estamos em guerra, mas estamos o tempo todo competindo com outras organizações. E isso é levado muito a sério, pois se a organização perde a competição, nós perdemos nosso emprego e com ele nosso sustento, ou seja, não é a morte, mas é bem ruim.

E quando pensa especificamente no universo da TI, com seus servidores de missão crítica, alta disponibilidade, milhares de usuários e milhões de transações e isso tudo parado dependendo da sua habilidade para corrigir um bug inesperado já dá pra sentir um calafrio na espinha e o corpo se preparando para uma briga do tipo “faca nos dentes”.

E é nessas horas, quando o circo pega fogo, que vejo algumas pessoas se melindrando porque o chefe falou mais alto, porque o e-mail veio sem assinatura ou bom dia, porque o colega pediu sem falar “por favor”.

Vamos lá né amigo! Agora estamos na guerra cara! Graças a deus não é assim todo dia e logo que a coisa esfriar, o servidor subir e o ultimo soldado inimigo estiver morto e enterrado, eu volto a sorrir e te darei todos os “por favor”, “meu caro” e “se não for muito incomodo” que você quiser, mas enquanto isso não chega:

- ATIRA CARA!!! ATIRA NELE!!! ATIIIIRAAAAAAA!!!!

Atenciosamente,

Felipe Antunes

T-SQL Tips - Agendando um Trace com SQL Profiler

2011-09-16T15:22:00.000-07:00

/*
Olá amigos!

Esse post é bem simples. Uma receita de bolo para voce agendar a execução do seu SQL Server Profiler e retornar isso depois em uma consulta T-SQL. Ótimo para relatórios de Performance e analise de problemas.

Então mãos a obra!

-- ## PASSO 1 - Criar o Script Tracer Definition.

O Script Tracer Definition é um arquivo .SQL que contém todas as regras sobre o que será capturado, quanto tempo e quais critérios de filtro. Como ele é bem extenso e pouco intuitivo para ser feito na mão, o primeiro passo é utilizar o SQL Profiler para fazer o trabalho para você.

1 - Abra o SQL Profiler, crie um novo Trace.

2 - Selecione a checkbox SaveToFile e escolha um diretório na sua máquina para armazenarmos o resultado.

Obs: Esse diretório na verdade deve ser um diretório do servidor onde voce executará o Job. Mas é possivel alterarmos essa configuração depois.

Obs2: A opção SaveToTable não é possivel no job agendado (Checar)

3 - Selecione a checkbox "Enable Trace Stop Time". Isso dirá ao Profiler que hora ele deve parar de processar o trace.

No meu exemplo, quero que o profiler rode das 09:00 até as 11:00.

Obs: A configuração de Start fica por conta do schedule do job como veremos adiante.

4 - Configure os eventos que voce deseja. Em geral eu capturo as StoreProcedures e Batchs T-SQL que finalizaram.

5 - Clique em Run e na sequencia para a captura. Vá File/Export/Script Trace Definition/ For SQL Server 2005-2008

6 - Abra o Script no SQL Management Studio. Abaixo o script que foi gerado. Fiz comentários grifados em cada ponto importante.

/****************************************************/

/* Created by: SQL Server 2008 Profiler */

/* Date: 16/09/2011 17:52:36 */

/****************************************************/

-- Create a Queue

declare @rc int

declare @TraceID int

declare @maxfilesize bigint

declare @DateTime datetime

set @DateTime = '2011-09-19 11:00:00.000' --<< Aqui é o Stop Time que definimos.

set @maxfilesize = 5 --<<---- Aqui é o tamanho maximo do arquivo TRC em Mb.

-- Please replace the text InsertFileNameHere, with an appropriate

-- filename prefixed by a path, e.g., c:\MyFolder\MyTrace. The .trc extension

-- will be appended to the filename automatically. If you are writing from

-- remote server to local drive, please use UNC path and make sure server has

-- write access to your network share

exec @rc = sp_trace_create @TraceID output, 0, N'F:\Traces\Trace_Agendado', @maxfilesize, @Datetime

/*<<-- Onde está em amarelo voce coloca o diretório do servidor e nome do arquivo desejado (sem o .trc) .>> */

if (@rc != 0) goto error

-- Client side File and Table cannot be scripted

-- Set the events
declare @on bit

set @on = 1

exec sp_trace_setevent @TraceID, 10, 15, @on

exec sp_trace_setevent @TraceID, 10, 16, @on

exec sp_trace_setevent @TraceID, 10, 1, @on

exec sp_trace_setevent @TraceID, 10, 9, @on

exec sp_trace_setevent @TraceID, 10, 17, @on

exec sp_trace_setevent @TraceID, 10, 10, @on

exec sp_trace_setevent @TraceID, 10, 18, @on

exec sp_trace_setevent @TraceID, 10, 11, @on

exec sp_trace_setevent @TraceID, 10, 12, @on

exec sp_trace_setevent @TraceID, 10, 13, @on

exec sp_trace_setevent @TraceID, 10, 6, @on

exec sp_trace_setevent @TraceID, 10, 14, @on

exec sp_trace_setevent @TraceID, 12, 15, @on

exec sp_trace_setevent @TraceID, 12, 16, @on

exec sp_trace_setevent @TraceID, 12, 1, @on

exec sp_trace_setevent @TraceID, 12, 9, @on

exec sp_trace_setevent @TraceID, 12, 17, @on

exec sp_trace_setevent @TraceID, 12, 6, @on

exec sp_trace_setevent @TraceID, 12, 10, @on

exec sp_trace_setevent @TraceID, 12, 14, @on

exec sp_trace_setevent @TraceID, 12, 18, @on

exec sp_trace_setevent @TraceID, 12, 11, @on

exec sp_trace_setevent @TraceID, 12, 12, @on

exec sp_trace_setevent @TraceID, 12, 13, @on

-- Set the Filters

declare @intfilter int

declare @bigintfilter bigint

exec sp_trace_setfilter @TraceID, 10, 0, 7, N'SQL Server Profiler - c16c42f1-c66c-4152-8fc1-d92a44fef880'

exec sp_trace_setfilter @TraceID, 10, 0, 7, N'SQL Server Profiler - fd8af8d3-5b18-49b2-93d4-048a74902059'

-- Set the trace status to start

exec sp_trace_setstatus @TraceID, 1

-- display trace id for future references

select TraceID=@TraceID

-- Loop para aguardar a conclusão do job

DECLARE @Running int = 1

WHILE @Running = 1
     BEGIN
            WAITFOR DELAY '00:01:00'

            IF EXISTS(SELECT * FROM sys.traces WHERE ID = @TraceID)

SET @Running = 1

            else
                  SET @Running = 0
      END

goto finish

error:

select ErrorCode=@rc

finish:

--################ FIM DO SCRIPT ##############################

-- OBSERVAÇAO: Voce pode fazer um teste do script no próprio SSMS. É só executar -- o script, se ele foi bem sucessido ele retorna um TraceID que pode ser

-- consultado na tabela sys.trace

-- ## PASSO 2 - Criação de Job.

Vamos criar um Job com dois passos

1 - No primeiro será o da execução do trace.

2 - Vamos acrescentar um pequeno loop T-SQL que checa se o Trace conclui logo depois do "select TraceID=@TraceID". Veja abaixo.

(…)

select TraceID=@TraceID

DECLARE @Running int = 1

WHILE @Running = 1

BEGIN

WAITFOR DELAY '00:01:00'

IF EXISTS(SELECT * FROM sys.traces WHERE ID = @TraceID)

SET @Running = 1

else

SET @Running = 0

END

(…)

3 - O segundo passo é colocar o conteudo do trace em uma tabela usando a function fn_trace_gettable

SELECT TextData, CPU,Reads,Writes,Duration

into SuaBaseDeDados.dbo.SuaTabela

-- Coloque acima a base e tabela de sua referencia

FROM fn_trace_gettable ( N'F:\Traces\Trace_Agendado.trc' , DEFAULT )

-- 4 - E pronto só agendar o Job e brincar com sua tabelinha.

## BEGIN BONUS ##

Se voce chegou até aqui é porque o assunto realmente te interessou. Existe um pequeno truque para você tornar o Stop Time dinamico.

É bem simples e torna o job ainda mais versátil. Se quiser saber como faz, ou se voce descobriu como fazer me mande um email.

## END BONUS ##

Gostou da dica? Achou algum bug? Tem alguma pergunta?? Fique a vontade para me contactar e comentar abaixo!

email: fjantunes@gmail.com

E Muito Obrigado pela visita!

Modelagem - Função para calcular dias úteis em T-SQL

2011-08-18T17:19:00.000-07:00

/*#######################################################################
ATENÇÃO: ESTE POST TODO É UM SCRIPT! SE VOCE NÃO TIVER PACIENCIA PARA LER, BASTA COPIA-LO EM SEU
MANAGEMENT STUDIO E EXECUTA-LO NA SUA BASE DE PREFERENCIAS
VOCE TERÁ UMA TABELA DATAS E A FUNÇÃO FN_DIASUTEIS PRONTA PRA USO!
#######################################################################*/

/* Olá caro leitor!

Esses dias no fórum da MSDN um colega perguntou se era possivel criar uma função que calcula-se quantos dias uteis tivemos entre uma data e outra. Não existe nenhuma função nativa no SQL que faça esse calculo, no entanto com alguns calculos e uma tabela do tamanho de um MP3 (3Mb) conseguimos montar essa função cobrindo um período de dois séculos !

Esse tipo de tabela também é bem comum entre o pessoal que trabalha com Data Warehouse.

Então mãos a obra!

/* ## Passo 1 - CONSTRUINDO E POPULANDO A TABELA ------------------------

Nesse passo, montamos uma estrutura bem simples, que armazenará todas os dias de 1900 a 2099, incluindo alguns atributos que podem ser interessantes.

Na sequencia com um WHILE para popularmos os dados.

Obs: Antes que voce questione. Existe uma razão para o campo DiaUtil ser Default 1 e tipo tinyint (explicações adiante)

-- Tabela

CREATE TABLE Datas (

      Data datetime NOT NULL CONSTRAINT PK_Datas PRIMARY KEY,
      DiaSemana varchar(13) NOT NULL,
      DiaSemanaNum tinyint NOT NULL,
      Dia tinyint NOT NULL,
      Mes tinyint NOT NULL,
      NomeMes varchar(9) NOT NULL,
      Ano smallint NOT NULL,
      DiaUtil tinyint NOT NULL DEFAULT (1)
      )

--- Preenchimento da tabela

DECLARE @DataInicial DATETIME = '01/01/1900'

DECLARE @DataFinal DATETIME = '31/12/2099'

WHILE @DataInicial <= @DataFinal
      BEGIN
            INSERT INTO Datas
            SELECT
                  @DataInicial,
                  DATENAME(WEEKDAY,@DataInicial),
                  DATEPART(WEEKDAY,@DataInicial),
                  DATEPART(DAY,@DataInicial),
                  MONTH(@DataInicial),
                  DATENAME(MONTH,@DataInicial),
                  YEAR(@DataInicial),
                  1

SET @DataInicial = DATEADD(DAY,1,@DataInicial)

END
GO

      Notou como a tabela ficou pequena???

      Execute um space used e você ficará impressionado.

--- Espaço ocupado

sp_spaceused 'Datas'
GO

rows reserved data index_size unused
----------- --------------- ------------------ ------------------ -------
73049 3344 KB 3312 KB 24 KB 8 KB
*/

/* ## Passo 2 - Marcando os dias inuteis (na visão de seu chefe)

OK. Dados prontos, só precisamos marcar os tres tipos de dias não úteis que possuimos

1 - Finais de Semana

2 - Feriados Nacionais Fixos (dependendo do seu cenário, fique a vontade para incluir os feriados estaduais e municipais)

3 - Feriados Nacionais variáveis (basicamente o Carnaval (EBA!) e o Corpus Christi (???). Pois ambos seguem o Calculo Eclesiástico quem em 325 o Concilio de Nicea assim os definiu (SQL Server também é cultura!!!)

/* Fins de Semana: Basta zerar a coluna DiaUtil onde o dia da semana numerico for igual a 7 - Sabádo e 1 – Domingo */

UPDATE Datas SET DiaUtil = 0 WHERE DiaSemanaNum IN (7,1)

/* Feriados Nacionais Fixos: Para cada combinação de dia e mês (o ano não importa) um update nos feriados.

Inclua aqui dias 24/12 ou 31/12 conforme seu cenário exigir */

UPDATE Datas

      SET DiaUtil = 0
      WHERE
            (Dia = 1 AND Mes = 1) -- Dia da Confraternização Mundial
      OR
            (Dia = 21 AND Mes = 4) -- Dia de Tiradentes
      OR
            (Dia = 1 AND Mes = 5)   -- Dia do Trabalho
      OR
            (Dia = 7 AND Mes = 9)   -- Independencia do Brasil
      OR
            (Dia = 12 AND Mes = 10)   -- Dia de Nossa Senhora Aparecida
      OR
            (Dia = 2 AND Mes = 11)   -- Finados
      OR
            (Dia = 15 AND Mes = 11)   -- Proclamação da Republica
      OR
            (Dia = 25 AND Mes = 12)   -- Natal

/* ## Passo 3 - Feriados Nacionais variaveis (Carnaval e Corpus Christi).

Aqui a coisa complica um pouco, pois temos que converter em T-SQL as fórmulas que o Concilio de Nicea decidiu a uns 1700 anos atrás (será que o

Papa da época imaginou isso um dia?)

Minha referência veio do site http://inf.ufrgs.br/~cabral/Pascoa.html. Do professor da UFRGS - Profº Roberto Cabral de Mello Borges.

Lá ele explica o calculo mais detalhadamente e dá exemplos. Além de uma tabela completa com datas ja calculadas.

Basicamente aqui, farei um outro Loop com WHILE passeando por cada ano e usando a formula para identificar o Domingo de Pascoa. Através dele chegaremos na Terça de Carnaval (Domingo de Pascoa menos 47 dias) e no Corpus Christi (Domingo de Pascoa + 60 dias)

-- Constantes X e Y e variaveis de calculo

DECLARE @X int = 24
DECLARE @Y int = 5
DECLARE @a int ,@b int, @c int,@d int,@e int

-- Variaveis de data

DECLARE @Ano smallint = 1900
DECLARE @Dia tinyint
DECLARE @Mes tinyint
DECLARE @DomingoPascoa datetime

WHILE @Ano <= 2099

      BEGIN
      --- Calculo de Dia e Mes
            SET @a = @Ano % 19
            SET @b = @Ano % 4
            SET @c = @Ano % 7
            SET @d = (19 * @a + @X) % 30
            SET @e = (2 * @b + 4 * @c + 6 * @d + @Y) % 7

            IF (@d + @e) > 9
                  BEGIN
                        SET @Dia = @d + @e - 9
                        SET @Mes = 4
                  END
            else
                  BEGIN
                        SET @Dia = @d + @e + 22
                        SET @Mes = 3
                  END

/* Correção dos casos particulares que ocorrem duas vezes por século (2049 e 2076 no século 21) */

IF @Ano IN (2049,2076)

                  BEGIN
                        IF @Dia = 26
                             SET @Dia = 19
                        else
                             SET @Dia = 18
                  END

            -- Obtém o domingo de pascoa
            SET @DomingoPascoa = CAST(CAST(@Dia as varchar) + '/' + CAST(@Mes as varchar) + '/' + CAST(@Ano as varchar) as datetime)

-- Marca a terça feira de carnaval (pascoa - 47 dias)

            UPDATE Datas
            SET DiaUtil = 0
            WHERE Data = DATEADD(day,-47,@DomingoPascoa)

-- Marca a quinta feira Corpus Christi (pascoa + 60 dias)

            UPDATE Datas
            SET DiaUtil = 0
            WHERE Data = DATEADD(day,60,@DomingoPascoa)

SET @Ano = @Ano + 1

END

/* ## Passo 4 - Enfim a função!!!

Eis a razão de ter escolhido TinyInt no campo DiaUtil. Se tivesse escolhido o campo Bit, não conseguiria aplicar o SUM.

O campo data como PK também garante uma performance excepcional no calculo.

CREATE FUNCTION dbo.fn_DiasUteis (@DataInicial datetime,

@DataFinal datetime)

RETURNS int
AS

BEGIN

DECLARE @DiasUteis int

SELECT

                             @DiasUteis = SUM(DiaUtil)
                  FROM
                        Datas
                  WHERE
                        Data BETWEEN      @DataInicial AND @DataFinal

RETURN @DiasUteis

END
GO

/* ## E Pronto!

Essa funçãozinha ficará eternamente ativa, não exigirá manutenção nos próximos 88 anos. O que é tempo suficiente para voce relaxar e descobrir e refletir sobre quantos dias uteis ocorreram desde o dia que nasceu!

SELECT dbo.fn_DiasUteis ('21/04/1982','18/08/2011')

Gostou da dica? Achou algum bug? Tem alguma pergunta?? Fique a vontade para me contactar e comentar abaixo!

email: fjantunes@gmail.com

http://www.agoradba.blogspot.com/

T-SQL Tips - Convertendo linhas em colunas com o operador PIVOT

2011-07-27T15:13:00.000-07:00

/* Olá Caros Amigos dos Dados!

Mais um operador interessante que deveria estar na ToolBox de todo DBA/Desenvolvedor SQL Server. O Operador PIVOT.

Disponivel a partir da versão 2005/2008 para converter linhas em colunas (e vice versa), o Pivot é um só um pouco dificil de entender, mas depois que voce

pega o jeito percebe que é bem facil e eficiente nas suas consultas.

Então mãos a obra!

Em uma base de dados de um sistema de e-commerce, temos a tabela Fluxo_Pedido que armazena as datas em que cada processo de um pedido foi realizado conforme Figura 1

/*
Nosso cliente deseja a seguinte visualização dessa informação
*/

/* Agora dê uma olhada na syntax padrão do operador PIVOT */

SELECT <Coluna non-pivoted >,

[Primeira coluna pivoted] AS <alias da coluna>,

    [Segunda coluna pivoted] AS <alias da coluna>,
    ...
    [Ultima coluna pivoted] AS <alias da coluna>
FROM
    (<Consulta fonte>) AS <alias da consulta fonte>

PIVOT --<< AQUI ESTÁ O OPERADOR!

(

    <Valor agregado>
FOR
    [Coluna do cabeçalho]
    IN (
        [Primeira coluna pivoted],
        [Segunda coluna pivoted]...
        [Ultima coluna pivoted]
       )
) AS <alias da tabela pivot>

Agora dando nomes ao bois!

A coluna non pivoted é a coluna que agrupa as linhas. No nosso caso é o Numero do Pedido, pois teremos uma linha para cada pedido

As colunas pivoted são os valores que passarão a ser colunas da tabela.Aqui colocamos a coluna Etapa e criaremos uma coluna para cada etapa (Solicitacao, Pagamento, Transportadora,Finalizacao)

Veja como ficou:

SELECT

     NumeroPedido,
    [Solicitação],
    [Pagamento],
    [Transportadora],
    [Finalizacao]
FROM
    (<Consulta fonte>) AS <alias da consulta fonte>
PIVOT
(
    <Valor agregado>
FOR
    [Coluna do cabeçalho]
    IN (
         [Primeira coluna pivoted],
         [Segunda coluna pivoted]
         ...
         [Ultima coluna pivoted])
) AS <alias da tabela pivot>

Nossa consulta fonte é um SELECT dos dados da tabela Fluxo_Pedido.

Devemos incluir no select a coluna non-pivoted, a coluna que possui os valores pivoted e o campo que será exibido nas células (DataEtapa)

ou seja:

SELECT NumeroPedido,Etapa ,DataEtapa FROM Fluxo_Pedido

SELECT

      NumeroPedido,
    [Solicitação],
    [Pagamento],
    [Transportadora],
    [Finalizacao]
FROM
    (SELECT NumeroPedido,Etapa ,DataEtapa FROM Fluxo_Pedido) AS Consulta_Fonte

PIVOT

(
    <Valor agregado>
FOR
    [Coluna do cabeçalho]
    IN (
        [Primeira coluna pivoted],
        [Segunda coluna pivoted]
        ...
        [Ultima coluna pivoted]
       )
) AS <alias da tabela pivot>

E por fim vamos dar os parametros do operador PIVOT.

O valor agregado deve ser uma função de agrupamento (MAX(), MIN(),COUNT(),etc...) e a coluna que vamos no nosso "miolo".

Como vamos exibir a data em que foi executada cada etapa vamos usar MIN(DataEtapa)

Após o FOR indicamos a coluna cabeçalho (Etapa) e repetimos as colunas pivoted.

SELECT

    NumeroPedido,
    [Solicitação],
    [Pagamento],
    [Transportadora],
    [Finalizacao]
FROM
    (SELECT NumeroPedido,Etapa ,DataEtapa FROM Fluxo_Pedido) AS Consulta_Fonte
PIVOT
(
   MAX(DataEtapa)
FOR
      Etapa
    IN (
        [Solicitação],
        [Pagamento],
        [Transportadora],
        [Finalizacao]
       )
) AS TabelaPivot

/* E pronto!! Temos uma PIVOT novinha em folha!

Obrigado pela leitura e espero ter ajudado você em seu dia a dia

Comente abaixo, sugira na nossa caixinha de sugestõe e se tiver duvidas me mande um email: fjantunes@gmail.com.br

Abraços!

TroubleShooting - Msg 952, Level 16, State 1 Database 'MinhaBase' is in transition. Try the statement later

2011-07-16T14:35:00.000-07:00

Olá amigos!

Ja falei que a vida de DBAs é cheia de aventura? Essa semana o caso abaixo elevou o nível da minha adrenalina. Sem aviso e no meio do dia uma base de produção critica ficou inacessível sem razão aparente.

Ao tentar acessa-la com o Use Database recebia a seguinte mensagem

Msg 952, Level 16, State 1, Line 1

Database 'MinhaBase' is in transition. Try the statement later.

-- ou na tradução do SQL

Msg 952, Level 16, State 1, Line 1

Banco de dados 'MinhaBase' em transição. Tente a instrução mais tarde.

E nunca mais voltava!

Após alguns minutos de desespero, descobrimos que o erro foi causado por um comando ALTER DATABASE MinhaBase SET OFFLINE. ( meu colega DBA que originou o comando jura de pé junto que só tinha acabado de fazer um backup e eu acredito nele)

Como o banco estava cheio de usuários o SQL estava aguardando que todos se desconectassem da base para concluir o comando e ao mesmo tempo bloqueou todos os novos usuários de se conectarem naquela base.

Para solucionar tivemos que encontrar o session id do comando com a sys.dm_exec_requests

select session_id, command, wait_resource

from sys.dm_exec_requests

WHERE

command = 'ALTER DATABASE'

-- No wait_ressource está a indicação do banco de dados que está sendo alvo do comando

-- E matar o session id que obtemos

kill 59

-- E tudo volta ao normal como mágica.... ufa...

A primeira a gente nunca esquece!

2011-06-30T18:36:00.000-07:00

Leitores amigos,

A pouco mais de um ano iniciei o E Agora DBA? com esse post. Um dos objetivos desse blog era um desafio pessoal - "Conseguir uma certificação oficial da Microsoft sem a necessidade de cursar os caros cursos oficiais".
Eu sempre tive muito receio em investir dois ou tres mil reais em formação e cair em uma turma onde o orientador apenas lê o material oficial e repete os exercicios em um data show. Ler eu ja sei e faço bem mais barato. Mas como sempre acontece, o corre corre nos faz deixar alguns planos de lado. Um bom tempo se passou e o assunto na verdade tinha ficado até esquecido.
Foi mais ou menos na mesma época que retomei esse blog que a idéia voltou ao meu radar.

Então eu arrisquei. Tirei o escorpião do bolso e paguei os US$ 80,00 e comecei uma revisão com esse livro aqui. Eram tres semanas para preencher as lacunas que faltavam para chegar na MCTS: Database Development.

Então, em uma segunda feira chuvosa estava eu na Avenida Paulista aguardando o horário do exame, tomando um suco de laranja e nervoso como um vestibulando. Subi ao centro de exames. E cai dentro do teste. E passei!!

A alegria de conseguir passar em um teste como esse não é puro exibicionismo. O profissional de TI é por natureza um entusiasta que gosta de desafios, a aprovação é colocar a prova tudo o que voce sabe sobre o assunto e converter isso em uma métrica. A meta são os 700 pontos. Passa-los é uma vitória.

Estou feliz meus amigos. Mas nao existe felicidade eterna. Portanto.. MCITPRO aqui vou eu!

Nossos primeiros erros

2011-06-15T15:45:00.000-07:00

O objetivo deste post é bem simples. Quando iniciamos nossa vida de DBA/Desenvolvedor nos deparamos com erros simples que nos roubam um tempo precioso na procura pela resposta. Acredito que esse tempo se perde pela mensagem de erro dificil ou pela tradução para o portugues que é terrivel no SQL. (eu prefiro usar tudo no inglês mesmo)

-- Crie essa simples tabela.

CREATE TABLE PrimeirosErros (ErroID int identity(1,1) PRIMARY KEY,Erro varchar(5))

-- Primeiro erro

INSERT INTO PrimeirosErros (Erro) VALUES ('123456')

-- Erro --------------

Msg 8152, Level 16, State 14, Line 1

String or binary data would be truncated.

Msg 8152, Level 16, State 14, Line 1

Dados de cadeia ou binários seriam truncados.

----------------------

Explicação: Voce está inserindo um valor que estoura o tamanho maximo da coluna (Valor com 6 caracteres, campo definido para 5 caracteres)

Basta reduzir o tamanho que voce está inserindo ou aumentar a capacidade da coluna que voce está Parece besta, mas ja vi muito cara bom ficar um pouco perdido com essa mensagem esquisita.

-- Segundo erro:

INSERT INTO PrimeirosErros VALUES (1,'Teste' )

-- Erro --------------

Msg 8101, Level 16, State 1, Line 1

Um valor explícito para a coluna de identidade na tabela 'PrimeirosErros' só pode ser especificado quando uma lista de colunas é usada e o valor de IDENTITY_INSERT é ON.

Msg 8101, Level 16, State 1, Line 1

An explicit value for the identity column in table 'PrimeirosErros' can only be specified when a column list is used and IDENTITY_INSERT is ON.

Explicação: A coluna é identity (no popular auto-numérica). Como voce está forçando um valor para a coluna identity, voce deve ligar o INDENTY_INSERT da tabela para permitir a inclusão

SET IDENTITY_INSERT PrimeirosErros ON

INSERT INTO PrimeirosErros VALUES (1,'Teste' )

Ué...o erro continuou! E agora DBA?

A resposta continua simples, além de habilitar a inserção de valores explicitos na coluna voce deve especificar o insert da maneira mais explicita possivel, isto é,

incluindo a lista de colunas que receberão os dados

INSERT INTO PrimeirosErros (ErroID,Erro) VALUES (1,'Teste' )

Mas, por favor, não pare por ai. Nunca se esqueça de desligar o identity_insert. Senão ao executar o de baixo....

INSERT INTO PrimeirosErros (Erro) VALUES ('Teste2' )

-- Erro --------------

Msg 545, Level 16, State 1, Line 1

Explicit value must be specified for identity column in table 'PrimeirosErros' either when IDENTITY_INSERT is set to ON or when a replication user is inserting into a NOT FOR REPLICATION identity column.

Msg 545, Level 16, State 1, Line 1

Deve ser especificado um valor explícito para a coluna de identidade na tabela 'PrimeirosErros' quando IDENTITY_INSERT está definido como ON ou quando um usuário de replicação insere em uma coluna de identidade NOT FOR REPLICATION.

----------------------

Voce deve desligar o IDENTITY_INSERT da tabela para voltar tudo ao normal.

SET IDENTITY_INSERT PrimeirosErros OFF

Espero que essa pequena explicação tenha poupado seu tempo, os erros fazem parte de nossas vidas.
Se eles não existissem, talvez metade de nós estivesse desempregada :D

Abraços!

Felipe Antunes

AVISO:ESSE POST É UM SCRIPT! SE VOCE DESEJAR, VOCE PODE COPIA-LO E COLA-LO DIRETAMENTE NO SEU MANAGEMENT STUDIO

CTE Recursiva - Uma consulta elegante

2011-06-07T14:41:00.000-07:00

    Pessoal, muito obrigado pelo retorno do post anterior, no total foram duas centenas de pageviews,cinco emails, três comentarios, um telefonema e um visitante croata(sim é verdade!).
    Motivado por esse retorno sigo com a continuação:
  CTE com Recursividade!!!

   Veja o caso “CTE no Busão”:

       Imagine uma determinada linha de onibus que realiza 10 paradas entre seu trajeto de Guarulhos a Campinas. O onibus possui um sistema que registra a data/hora de cada parada e qual foi a distancia percorrida entre uma parada e outra. Scrip Exemplo

-- Estrutura

CREATE TABLE Paradas (

             ParadaID int identity (1,1) PRIMARY KEY, -- PK
             DataParada datetime, -- Data/hora da parada
             Distancia int, -- distancia percorrida da ultima parada até agora
             ParadaAnteriorID int -- id da parada anterior
             )
-- Populando
INSERT INTO Paradas (DataParada,Distancia)
VALUES (GETDATE(),0)
GO

INSERT INTO Paradas (DataParada,Distancia,ParadaAnteriorID)
SELECT TOP 1
       DATEADD(MINUTE ,(RAND() * 100)+ 5,DataParada) ,
       CAST(RAND() * 33 as Int )+ 5 ,
       @@IDENTITY
FROM
       Paradas
ORDER BY DataParada DESC
GO 10

Dando um SELECT simples temos o seguinte resultado

ParadaID DataParada Distancia ParadaAnteriorID

----------- ----------------------- ----------- ----------------
1           2011-06-07 17:23:59.543 0           NULL
2           2011-06-07 18:10:59.543 36          1
3           2011-06-07 19:31:59.543 30          2
4           2011-06-07 20:17:59.543 5           3
5           2011-06-07 21:37:59.543 27          4
6           2011-06-07 23:04:59.543 21          5
7           2011-06-07 23:19:59.543 37          6
8           2011-06-08 00:31:59.543 21          7
9           2011-06-08 01:13:59.543 6           8
10          2011-06-08 02:18:59.543 23          9
11          2011-06-08 02:37:59.543 28          10

--------------------------------------------------------------------

Eis então que chega o Gerente da companhia de Viação e te pede um relatório que exiba cada parada e quantos KMs foram percorridos do inicio da viagem até aquele momento. Ai que entra o CTE.

Uma CTE recursiva começa com a chamada Ancora. O registro Ancora é o fio por onde voce puxa a recursão. No nosso caso começamos com o registro inicial da viagem.

-- Ancora
SELECT
       DataParada,
       Distancia,
       ParadaID
FROM
       Paradas
WHERE
       ParadaAnteriorID IS NULL

    Na sequência via UNION ALL montamos uma query semelhante fazendo um Join com a própria CTE , veja abaixo

WITH CTE_Viagem (DataParada,KMRodados,ParadaID)

AS (
-- Ancora
SELECT
       DataParada,
       Distancia,
       ParadaID
FROM
       Paradas
WHERE
       ParadaAnteriorID IS NULL
UNION ALL
-- Recursão
SELECT
       P.DataParada,
       P.Distancia + C.KMRodados,
/* Pulo do Gato! Acima é que se soma a distancia atual com a distancia da anterior */
       P.ParadaID
FROM
       Paradas P
INNER JOIN CTE_Viagem C -- NOTE AQUI A CTE!!!
             ON P.ParadaAnteriorID = C.ParadaID
       )

SELECT
       DataParada,KMRodados,ParadaID
FROM
       CTE_Viagem

E olha que maravilha de resultado!!! E como é elegante.

DataParada              KMRodados   ParadaID
----------------------- ----------- -----------
2011-06-07 17:23:59.543 0           1
2011-06-07 18:10:59.543 36          2
2011-06-07 19:31:59.543 66          3
2011-06-07 20:17:59.543 71          4
2011-06-07 21:37:59.543 98          5
2011-06-07 23:04:59.543 119         6
2011-06-07 23:19:59.543 156         7
2011-06-08 00:31:59.543 177         8
2011-06-08 01:13:59.543 183         9
2011-06-08 02:18:59.543 206         10
2011-06-08 02:37:59.543 234         11

     Não contente (e preguiçoso em fazer contas) o mesmo gerente te pede para colocar no relatório a quantidade em minutos que a viagem demorou até aquele momento. E voce simplesmente adiciona o seguinte:

WITH CTE_Viagem (DataParada,KMRodados,TempoViagem,ParadaID)

AS
(
-- Ancora
SELECT
       DataParada,
       Distancia,
       0 AS TempoViagem,
       ParadaID
FROM
       Paradas
WHERE
       ParadaAnteriorID IS NULL
UNION ALL
-- Recursão
SELECT
       P.DataParada,
       P.Distancia + C.KMRodados,
       C.TempoViagem + DATEDIFF(minute,C.DataParada,P.DataParada),--Pulo do Gato!
       P.ParadaID
FROM
       Paradas P
INNER JOIN CTE_Viagem C ON P.ParadaAnteriorID = C.ParadaID
       )
SELECT
       DataParada,KMRodados,TempoViagem,ParadaID
FROM
           CTE_Viagem

E resultado:

DataParada KMRodados TempoViagem ParadaID

----------------------- ----------- ----------- -----------
2011-06-07 17:23:59.543 0           0           1
2011-06-07 18:10:59.543 36          47          2
2011-06-07 19:31:59.543 66          128         3
2011-06-07 20:17:59.543 71          174         4
2011-06-07 21:37:59.543 98          254         5
2011-06-07 23:04:59.543 119         341         6
2011-06-07 23:19:59.543 156         356         7
2011-06-08 00:31:59.543 177         428         8
2011-06-08 01:13:59.543 183         470         9
2011-06-08 02:18:59.543 206         535         10
2011-06-08 02:37:59.543 234         554         11

Demais!

Explicações técnicas, detalhadas e sem emoção a seguir no nosso amigo books online

http://msdn.microsoft.com/en-us/library/ms186243.aspx

Abraços!!!

Voce já usou uma CTE?

2011-06-01T14:57:00.000-07:00

CTE é um recurso adicionado no SQL 2005 e pouquissimo utilizado por nossas bandas. Elas são parecidas com subqueries,você cria e nomeia um SELECT qualquer e ela passa a se comportar como uma tabela dentro do seu batch.
Diferentemente da subquery, a CTE pode se autoreferenciar e ser reaproveitado diversas vezes em um mesmo comando. Além de fornecer recursividade de um jeito bem bacana

Em um exemplo pratico.

Imagine que temos uma tabela padrão de clientes e uma tabela que armazena todas as compras que o cliente armazenou. Segue os scripts

-- Criando as tabelas

CREATE TABLE Cliente

      (
       ClienteID int identity(1,1) PRIMARY KEY,
       Cliente varchar(100) NOT NULL
       )
GO
CREATE TABLE Compras
      (
       CompraID int identity(1,1) PRIMARY KEY,
       ClienteID int NOT NULL FOREIGN KEY REFERENCES Cliente(ClienteID),
       DataCompra datetime
        )

-- Populando as tabelas (opcional, voce pode inventar seu proprio metodo de população)

INSERT INTO Cliente (Cliente)

SELECT UPPER(name) FROM master.sys.objects

INSERT INTO Compras (ClienteID,DataCompra)

SELECT
      Cliente.ClienteID,
      CAST(dateadd(MINUTE,(RAND(clienteid) * 100000),creation_time) as DATE)
FROM sys.dm_os_threads
CROSS JOIN Cliente
GROUP BY
     CAST(dateadd(MINUTE,(RAND(clienteid) * 100000),creation_time) as DATE),Cliente.ClienteID

------------------------------------------------------------

Imagine a necessidade de um campo DataUltimaCompra na tabela Cliente.

Um UPDATE entre as tabelas mais um Group By não é possivel. Com uma CTE a coisa fica mais simples. Veja abaixo:

-- Adiciona o campo

ALTER TABLE Cliente ADD DataUltimaCompra datetime

-- Declaração da CTE

;WITH CTE_UltimaCompra (ClienteID,UltimaCompra)
AS
(     SELECT
            ClienteID,
            MAX(DataCompra) UltimaCompra
      FROM Compras
      GROUP BY

ClienteID

)

-- Comando utilizando a CTE como se fosse uma tabela

UPDATE C
SET C.DataUltimaCompra = CTE.UltimaCompra
FROM Cliente C
INNER JOIN CTE_UltimaCompra CTE ON C.ClienteID = CTE.ClienteID

-- Com uma pequena modificação voce pode até colocar esse script em uma trigger

-- e manter esse campo atualizado na inserção de uma nova compra

CREATE TRIGGER tr_AtualizaUltimaCompra

ON Compras
FOR Insert,Update
AS
      WITH CTE_UltimaCompra (ClienteID,UltimaCompra)
      AS
      (     SELECT
                  C.ClienteID,
                  MAX(C.DataCompra) UltimaCompra
            FROM Compras C
            inner join inserted I ON C.ClienteID = I.ClienteID
            -- Atenção ao pulo do gato acima
            GROUP BY
                 C.ClienteID
      )

UPDATE C

      SET C.DataUltimaCompra = CTE.UltimaCompra
      FROM Cliente C
      INNER JOIN CTE_UltimaCompra CTE ON C.ClienteID = CTE.ClienteID

     No próximo post coloco um exemplo de recursividade com CTE.

     Abaixo o link do nosso querido Books Online com uma descrição completa

http://msdn.microsoft.com/en-us/library/ms175972.aspx

Abraços!

Eu eu eu , Julian Assange se deu mal!

2010-12-08T07:14:00.000-08:00

Leitores amigos, cuidado com o que você sabe.

Nos ultimos dias o site WikiLeaks , uma pagina dedicada a publicar documentos governamentais secretos, colocou a diplomacia americana em uma saia justa. A revelação de 250.000 documentos confidenciais que entre outras afirmações classificava o governo russo como mafioso e o presidente argentino Nestor Kirchner como doidão e marido de uma doida causou polemica internacional.

Mas quem se lascou mesmo foi o fundador do site Julian Assange, que depois da revelação dos documentos foi acusado de "crimes sexuais" na Suécia, recebeu ordem de prisão e teve sua fiança negada. Além de empresas como Visa e Paypal decidirem se desligar do WikiLeaks cortando assim as fontes de doações ao sitio. Será que é retaliação?

Observando as agruras de Julian da pra refletir um pouco sobre nosso pequeno mas valioso latifundio. Os dados. E o quão confidenciais eles são.

Recomendo que todo e qualquer DBA em primeiro lugar seja sigiloso. Na maioria das empresas o DBA é o "cara com acesso full", geralmente accessando informações financeiras da companhia, dados de clientes e outras coisitas mais. Por isso o melhor que fazemos é fechar o bico!

Caro colega de dados, as vezes não conseguimos ligar nossa conversa no cafezinho com crimes federais mas é ai que mora o perigo. Fale pouco sobre ou nada sobre o resultado das suas queries. Conheça bem a politica da sua companhia para dados sobre clientes, salarios e faturamentos. Um vazamento pode causar um belo estrago em sua carreira , para não dizer na sua vida. Por isso quando o dado confidencial aparecer lembre-se de Julian Assange e sua condenação por cometer crimes sexuais com suecas!