Post rápido.
Estou executando um pequeno benchmark para um cliente, avaliando se uma mudança na modelagem vai trazer benefícios para a aplicação, quando me deparo com um problema interessante. Conversando com o Fabiano ele citou non-foldable expressions, a causa raiz da questão.
Resumindo, quando o QO encontra non-foldable expressions ele não utiliza a densidade ou o histograma para estimar o número de registros, então ele chuta que um percentual dos registros será retornado (10% no meu caso).
Qual o problema disso? Mesmo com um índice em uma coluna com boa seletividade, acabo por ver cluster index scans e planos bem ruins.
Me parece que seria mais interessante o QO usar a densidade no caso de igualdade com non-foldable expression, mas com certeza devem haver cenários onde isso acaba por trazer resultados ruins.
Quer testar? Abaixo está o código que eu gerei para simular o problema utilizando o AdventureWorks2012.
Aproveite e teste o código no SQL Server 2014 e veja a diferença…
E não deixe de testar a última consulta do script e analisar a estimativa do QO. #fun
/****************************************************************************************
*****************************************************************************************
Autor: Luciano Caixeta Moreira
E-mail: luciano.moreira@srnimbus.com.br
LinkedIn: http://www.linkedin.com/in/luticm
Blog: http://luticm.blogspot.com
Twitter: @luticm
Título: non-foldable expression and bad plans
Descrição:
Histórico de atualização (yyyy-mm-dd):
- 2015-07-30: Criação do script
* Copyright (C) 2015 Sr. Nimbus Prestação de Serviços em Tecnologia LTDA
* http://www.srnimbus.com.br
*****************************************************************************************
****************************************************************************************/
USE tempdb
GO
SELECT *
INTO tempdb.dbo.TestePredicado
FROM AdventureWorks2012.Sales.SalesOrderDetail
CREATE UNIQUE CLUSTERED INDEX idx01
ON dbo.TestePredicado (SalesOrderDetailID)
go
CREATE NONCLUSTERED INDEX idx02
ON dbo.TestePredicado (SalesOrderID)
GO
EXEC sp_helpindex 'TestePredicado'
DBCC SHOW_STATISTICS('dbo.TestePredicado', idx02)
GO
-- Usa o histograma, conforme esperado, e estima 1 registro.
SELECT *
FROM dbo.TestePredicado
WHERE salesorderid = 46040
GO
-- Vetor de densidade
-- 3.178134435086604e-5 * 121317 = 3.855617352614016
DECLARE @X INT
SET @X = 46040
SELECT *
FROM dbo.TestePredicado
WHERE salesorderid = @X
GO
-- Utiliza a densidade
SELECT *
FROM dbo.TestePredicado
WHERE salesorderid = CAST(RAND() * 10000 AS INT)
GO
-- Estimated number of rows: 12131.7 => 10%
-- Plano ruim, scan (10% estimate) + filter
SELECT *
FROM dbo.TestePredicado
WHERE salesorderid = CAST(CAST(NEWID() AS binary(6)) % 20000000 AS INT)
GO
-- Ok, densidade
SELECT *
FROM dbo.TestePredicado
WHERE salesorderid = DATEPART(YEAR,GETDATE())
GO
-- Para resolver o problema...
DECLARE @X INT
SET @X = CAST(CAST(NEWID() AS binary(6)) % 20000000 AS INT)
SELECT *
FROM dbo.TestePredicado
WHERE salesorderid = @X
GO
/*
In a larger and more complex query on a larger data set, this type of error can result
in bad plan selection. If this is a problem for your application, consider using a
technique like the one illustrated above. Use sp_executesql or a stored procedure
containing the problem query, and pass in the precomputed result of the non-foldable
expression as a parameter.
This will allow you to work around the problem and get good cardinality estimates.
https://technet.microsoft.com/en-us/library/cc966419.aspx
*/
-- Estimativa OK
WITH C AS (
SELECT TOP 100
CAST(RAND() * 10000 AS INT) AS IDVenda
FROM sys.columns
)
SELECT *
FROM dbo.TestePredicado AS T
INNER JOIN C
ON T.SalesOrderID = C.IDVenda
-- Estimativa ficou ótima (!!!??!!!?!!), considerou um cross join...
WITH C AS (
SELECT TOP 100
CAST(CAST(NEWID() AS binary(6)) % 20000 AS INT) AS IDVenda
FROM sys.columns
)
SELECT *
FROM dbo.TestePredicado AS T
INNER JOIN C
ON T.SalesOrderID = C.IDVenda
Abraços
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
quinta-feira, 30 de julho de 2015
sexta-feira, 24 de julho de 2015
Cumulative update, aplicar ou não, eis a questão!
Post bem controverso, vamos ver no que vai dar…
Tudo começou com a seguinte pergunta: "Amigos, vocês recomendam um cliente a aplicar Cummulative Updates no SQL Server se não for por um erro encontrado?"
A resposta padrão para essa pergunta é NÃO, inclusive se você ler os textos dos cumulative updates (vulgo CUs) vai encontrar frases como essa: "This cumulative package is intended to correct only the problems that are described in this article. Apply it only to systems that are experiencing these specific problems". E nós, consultores, não podemos levianamente sugerir a aplicação de um fix sem analisar todo o cenário, então por segurança, muitos vão responder NÃO.
Dito isso, deixo minha opinião: eu sugiro que sua empresa crie a rotina de aplicar frequentemente CUs em produção, mesmo que você não tenha registro de problemas que são corrigidos por um CU específico.
Estou louco? Talvez, e se eu disser que acredito que o principal motivo para fazer isso é cultural?
Vamos as minhas justificativas…
CULTURA
Comparado a frequência de atualização de uma aplicação web, banco de dados é um componente bem mais estático, que sobre menos atualização. Se considerarmos que o tempo entre o service pack 1 (onde normalmente acontece a adoção do produto no Brasil) e o service pack 2, usualmente são quase 2 anos de espera, então sua equipe pode ficar aproximadamente 2 anos sem aplicar um fix em produção.
Por curiosidade, datas de lançamento de SPs do SQL Server 2012: SP1 (Novembro 2012) e SP2 (Junho de 2014).
Ótimo você pensa, isso é uma bela estabilidade! Sim, mas agora vamos a um índice que criamos na Nimbus e eu cito muito em minhas aulas: IPM ou Índice do Potencial Merdístico. Isto é, dependendo do que você está fazendo, o IPM indica quão grande é o potencial de dar alguma merda no que você está fazendo.
Vamos a uma situação hipotética…
E se o deploy de uma nova aplicação ou uma implementação de novo recurso faz com que um bug seja encontrado em produção, com resolução documentada em um CU ou SP?
Sua equipe vai ter que usar uma janela de noite no meio da semana para aplicar a correção. Ok, só um detalhe, coincidentemente nosso DBA sênior está de férias na Austrália (Murphy é um FDP mesmo!), então vamos com nosso DBA júnior… Mas o último fix que aplicamos faz 2 anos, como é mesmo o processo? E o backup? Foi feito no fim de semana, mas ainda não deu tempo de testar, então vamos torcer para ele estar íntegro (se esse Murphy aparecer aqui eu quebro ele na porrada)… E como uma grande fila de dominó, seu IPM vai aumentando, e junto com ele os riscos de sua organização. No fim pode dar tudo certo, mas e se não der????
O que acontece em uma organização que aplica regularmente os CUs…
Hoje a cadência de release dos CUs é em torno de 2 meses, então vamos supor que sua equipe espera 1 mês do lançamento do CU, aplica em desenvolvimento, semana seguinte em teste integrado, depois em homologação, chegando finalmente em produção na quarta semana, que quase coincide com o lançamento do próximo CU (1 mês + 4 semanas de aplicação da correção).
O que vai acontecer na organização:
• Seu DBA sênior vai trabalhar nas primeiras rotações da implementação, afinal é um profissional responsável, e vai cuidando das aplicações do fix. Só que isso não é viável para sua organização, que não quer ficar pagando hora extra para seus funcionários mais caros, e provavelmente seu sênior não quer ficar trabalhando todo fim de semana, mas sim investir seu tempo em algo mais útil e ter tempo com a família. Resultado:
- Seu DBA sênior vai começar a trabalhar na documentação e automatização da rotina (powershell ou algum shell script), criando algo mais profissional e sólido, diminuindo o risco humano das operações (que normalmente é o que aumenta bem o IPM).
- Com o tempo quem vai cuidar dessas aplicações é o DBA júnior, que está aprendendo e no início de carreira, que consegue fazer a rotina sem dificuldade e não vai estar em apuros quando o DBA sênior estiver viajando.
• Em algum momento uma aplicação de fix no fim de semana vai dar problema e sua equipe vai ter que trabalhar para contornar a situação.
- É melhor que isso aconteça em um período controlado onde você se organizou, está descansado e potencialmente tem uma janela de manutenção maior ou menor impacto em produção, caso do serviço ficar fora do ar por mais tempo que o planejado.
- Sua equipe vai investir mais tempo trabalhando em uma estratégia para contornar os potenciais problemas e ser mais eficiente em caso de desastre. Esse estímulo e aprendizado pode trazer um retorno imenso para a organização quando o problema atinge seu ambiente em horários críticos.
• Sua equipe também vai pensar em alternativas de alta disponibilidade, que podem ter sido relegadas para segundo plano (por N motivos), ou vai ficando cada vez mais confortável com as operações, conhecendo tempos de movimentação de recursos, detalhes da rotina, análise de logs, etc.
• Sua equipe cria a cultura de acompanhar os releases, revisar os fixes e, invariavelmente vai aprender alguma coisa só de ler as referências dos KBs.
- Curiosamente nos últimos anos tive a experiência de acompanhar mais o fixes do DB2 do que tinha com o SQL Server, e aprendi muito com essa prática, então também estou adotando para o SQL Server.
E falo isso de experiência própria… Recentemente passei por isso com o DB2, pude aplicar os primeiros fixes como se fosse um júnior, criamos uma documentação madura e um passo a passo excelente, a equipe já sabia como lidar com problemas comuns e tempo médio das operações, deixei de trabalhar de madrugada para aplicar fix e estávamos caminhando para no futuro automatizar nossos processos. De quebra já sugerimos deixar uma infraestrutura mínima e ajustada, para subir rapidamente novos bancos de dados se necessário.
E se um fix der problema na madrugada de sábado? Ai pode me acordar e no papel de consultor ou DBA Sênior, vou lá ajudar a resolver a bagaça…
SEM PROBLEMA NO AMBIENTE
O argumento do "se não tem problema" não aplique o CU tem fundamento pelo aspecto de estabilidade.
Mas vamos a outras situações hipotéticas, usando como referência o Cumulative Update package 7 for SQL Server 2012 Service Pack 2: https://support.microsoft.com/en-us/kb/3072100.
• FIX: Indexed view returns incorrect result after insert or delete operation on the base table in SQL Server 2012 (https://support.microsoft.com/en-us/kb/3068439)
- Ok, correção importante, mas se ninguém reclamou então não deve estar acontecendo no nosso ambiente… Mas e se estiver? Você executou selects em todas as views indexadas e foi validar o resultado para saber que não está com o problema? Se existem relatórios que usam sua view indexada e está distribuindo valores incorretos, os usuários podem somente notar daqui a alguns dias ou quem sabe no próximo mês.
- Ou então você implementa uma nova view indexada e o resultado começa a dar errado, o que fazer? Tirar a funcionalidade do ar até sua janela de manutenção ou aplicar o fix no meio da semana?
• FIX: Hash or merge join hints may be ignored when you execute a query in SQL Server 2012 (https://support.microsoft.com/en-us/kb/3064454)
- Você encontrou um plano ruim e o QO não está te ajudando. Usa um serviço de consultoria e o Fabiano diz: coloca essa hint que o plano vai brilhar. Você faz o ajuste e nada… bug no SQL Server. Resolução aplicar o fix… quando? Está preparado? Mesma ladainha.
- Só que esse camarada ainda tem uma coisa muito importante, trace flag 4199, que muita gente não sabe da existência mas deve ser entendido e tratado com carinho, ainda mais que o comportamento padrão da engine vai mudar no SQL Server 2016 (https://support.microsoft.com/en-us/kb/974006). Aí você resolve ir na cara e na coragem e habilita o TF 4199 sem teste e no meio da semana… Olha o IPM aumentando aí!!!!
- Esse trace flag é importante e merece um post dedicado! Estou escrevendo e em breve estará no blog.
• FIX: CMEMTHREAD waits occur when you execute many ad hoc queries in SQL Server 2012 (https://support.microsoft.com/en-us/kb/3074425)
- Sua empresa comprou uma nova aplicação, que passou por homologação e funcionou tudo bem, pois não tinha massa crítica para ressaltar o problem. Chegou em produção e lambou tudo logo na manhã de segunda-feira.
- Resolução é aplicar o fix… quando? Está preparado? (Isso está ficando repetitivo…).
A fragilidade do argumento de não aplicar o fix se não têm problema é que você não consegue efetivamente testar todas as condições (até porque alguns KBs podem ser bem superficiais), e lembrando que o CU é cumulativo, então se você vai aplicar o CU #5 tem que revisar todos os outros também.
Soma-se a evolução das aplicações e funcionalidades adotadas, pode ser que na próxima semana um novo recurso colida com um bug já documentado e corrigido 4 CUs atrás… Eu não gostaria de esbarrar com um bug de corrupção de dados que já foi corrigido em um CU anterior.
RISCOS
É claro que não sou um idiota para achar que não existem riscos, sim eles existem.
E pode ser que você vá enfrentá-lo hoje ou daqui a três meses quando precisar aplicar o CU por conta de outro problema, então você precisa estar preparado.
Em uma pesquisa rápida na internet encontrei um caso de um DBA onde um CU voltou um comportamento antigo do SQL Server, que havia sido corrigido por um SP antigo, e trouxe problemas para a equipe que acabou por reinstalar o SQL Server (só faltou ele dar mais detalhes do CU e SP, então comento aqui mesmo correndo o risco de ser uma análise errada do DBA). E é uma pena, talvez pudesse ter passado sem essa, ou quem sabe estar calejado e conseguido colocar o banco no ar com maior agilidade.
E isso leva ao próximo ponto que muitos argumentam: comparativo de "qualidade" do cumulative update e service pack.
CU vs. SP
Outro ponto contra os CUs é que a bateria de testes executadas contra eles são menores que os SP.
Mesmo existindo pequenas diferenças entre os testes de CU/SP, houve uma grande melhoria dos testes dos CUs e a infraestrutura atual suporta testes de regressão em CUs, da mesma forma que acontece com o SP, então no que toca os "grandes pontos" dos testes, CU e SP passam pela mesma bateria.
DESEJO
Meu desejo real é que a Microsoft passasse a indicar formalmente a aplicação dos CUs, incluindo além de correção de bugs novas funcionalidades para a engine (o que já aconteceu!), permitindo que eu não tenha que esperar alguns anos ou uma nova versão por uma melhoria que poderia estar disponível hoje.
Acredito que esse modelo esteja muito mais alinhado com a tendência de releases constantes que estamos vendo acontecendo ao redor do mundo e, uma hora ou outra, teremos que nos ajustar.
A cultura de constante atualização também vai forçar que isso se espalhe pela organização, inclusive para os desenvolvedores que vão ter que acabar por melhorar seus testes (tenho outro "causo" que lembrei, mas esse post já está gigante :-) ).
Isso também pode te ajudar a evitar manter pequenos fantasmas no futuro, afinal tem gente administrando SQL 7.0 e 2000 em pleno ano de 2015. E uma vez que sua empresa está nesse modo de operação, também vai cobrar de seus fornecedores para acompanhar: "Tem uma aplicação de terceiro que exige modo de compatibilidade 2000, então não consigo migrar….".
SENDO REALISTA
Não são todas as equipes que estão preparadas para esse modelo, afinal ainda temos centenas de DBAs acidentais de SQL Server administrando (como podem) o seu ambiente. Então simplesmente sumir com o Service Pack não é algo viável, pois é um marco para muitas empresas.
Service packs e CUs podem ter bugs e trazer problemas, já vimos isso acontecer, então NÃO estou recomendando aplicar o fix no dia seguinte a sua liberação (a MS já tem um histórico sobre isso), por isso recomendo esperar pelo menos um mês para começar seu processo de atualização.
Com a cadência de release de 2 em 2 meses fica muito difícil acompanhar os CUs, então que tal começar de quatro em quatro meses?
IMPORTANTE: Sou um profissional e bancos de dados não devem ser tratados levianamente, e você deve fazer o mesmo. Estude, acompanhe, leia as alterações, entenda o que está sendo aplicado e trate com muito zelo o seu ambiente, pois um DBA despreparado pode causar a falência de uma empresa. Então TESTE, TESTE e TESTE, melhorando sempre todo seu ciclo de deployment.
CONCLUSÃO
Mesmo remando contra a maré, eu acredito que os benefícios de constantemente aplicar os CUs ultrapassam de longe os riscos de se ter uma cultura reativa.
Processos melhores, documentação e automatização, equipe mais preparada, datas controladas para fazer as atualizações, melhor integração com outras áreas, tudo isso faz com que sua equipe e organização amadureçam se tornem mais profissionais.
Claro que não é simples, você vai comprar brigas, vai ter que aprender a se dar bem com o desenvolvedor FDP, que também acha você um DBA FDP e babaca (quem sabe vocês não viram best friends!!) e isso não vai acontecer da noite para o dia. Mas sair da zona de conforto pode te fazer um bem danado e no longo prazo vai favorecer para que fique cada vez menor o IPM da sua equipe de DBAs e dos bancos de dados.
Agora se você prefere esperar o problema acontecer no meio da segunda feira após recebimento dos salários, com movimentações críticas acontecendo, fazer um processo que você não está acostumado, notar que no FDS o backup falhou e aplicar o fix torcendo para que tudo dê certo… É sua escolha. E prometo que vou acender uma vela por você!
PS: descobri também que não estou sozinho, lendo um thread vi que Aaron Bertrand e Glenn Berry também são a favor, inclusive o Glenn já escreveu sobre isso (http://sqlperformance.com/2013/03/system-configuration/sql-server-servicing).
PPS: já estou ouvindo piadinhas com o acrônimo "CU", mas em um post desse tamanho não tinha como deixar de usar as duas letras juntas...
====================== UPDATE 2016-03-29 =====================
A Microsoft agora recomenda que você proativamente aplique os CUs e não somente os Service Packs. Detalhes aqui: https://blogs.msdn.microsoft.com/sqlreleaseservices/announcing-updates-to-the-sql-server-incremental-servicing-model-ism/
============================================================
Abraços
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
Tudo começou com a seguinte pergunta: "Amigos, vocês recomendam um cliente a aplicar Cummulative Updates no SQL Server se não for por um erro encontrado?"
A resposta padrão para essa pergunta é NÃO, inclusive se você ler os textos dos cumulative updates (vulgo CUs) vai encontrar frases como essa: "This cumulative package is intended to correct only the problems that are described in this article. Apply it only to systems that are experiencing these specific problems". E nós, consultores, não podemos levianamente sugerir a aplicação de um fix sem analisar todo o cenário, então por segurança, muitos vão responder NÃO.
Dito isso, deixo minha opinião: eu sugiro que sua empresa crie a rotina de aplicar frequentemente CUs em produção, mesmo que você não tenha registro de problemas que são corrigidos por um CU específico.
Estou louco? Talvez, e se eu disser que acredito que o principal motivo para fazer isso é cultural?
Vamos as minhas justificativas…
CULTURA
Comparado a frequência de atualização de uma aplicação web, banco de dados é um componente bem mais estático, que sobre menos atualização. Se considerarmos que o tempo entre o service pack 1 (onde normalmente acontece a adoção do produto no Brasil) e o service pack 2, usualmente são quase 2 anos de espera, então sua equipe pode ficar aproximadamente 2 anos sem aplicar um fix em produção.
Por curiosidade, datas de lançamento de SPs do SQL Server 2012: SP1 (Novembro 2012) e SP2 (Junho de 2014).
Ótimo você pensa, isso é uma bela estabilidade! Sim, mas agora vamos a um índice que criamos na Nimbus e eu cito muito em minhas aulas: IPM ou Índice do Potencial Merdístico. Isto é, dependendo do que você está fazendo, o IPM indica quão grande é o potencial de dar alguma merda no que você está fazendo.
Vamos a uma situação hipotética…
E se o deploy de uma nova aplicação ou uma implementação de novo recurso faz com que um bug seja encontrado em produção, com resolução documentada em um CU ou SP?
Sua equipe vai ter que usar uma janela de noite no meio da semana para aplicar a correção. Ok, só um detalhe, coincidentemente nosso DBA sênior está de férias na Austrália (Murphy é um FDP mesmo!), então vamos com nosso DBA júnior… Mas o último fix que aplicamos faz 2 anos, como é mesmo o processo? E o backup? Foi feito no fim de semana, mas ainda não deu tempo de testar, então vamos torcer para ele estar íntegro (se esse Murphy aparecer aqui eu quebro ele na porrada)… E como uma grande fila de dominó, seu IPM vai aumentando, e junto com ele os riscos de sua organização. No fim pode dar tudo certo, mas e se não der????
O que acontece em uma organização que aplica regularmente os CUs…
Hoje a cadência de release dos CUs é em torno de 2 meses, então vamos supor que sua equipe espera 1 mês do lançamento do CU, aplica em desenvolvimento, semana seguinte em teste integrado, depois em homologação, chegando finalmente em produção na quarta semana, que quase coincide com o lançamento do próximo CU (1 mês + 4 semanas de aplicação da correção).
O que vai acontecer na organização:
• Seu DBA sênior vai trabalhar nas primeiras rotações da implementação, afinal é um profissional responsável, e vai cuidando das aplicações do fix. Só que isso não é viável para sua organização, que não quer ficar pagando hora extra para seus funcionários mais caros, e provavelmente seu sênior não quer ficar trabalhando todo fim de semana, mas sim investir seu tempo em algo mais útil e ter tempo com a família. Resultado:
- Seu DBA sênior vai começar a trabalhar na documentação e automatização da rotina (powershell ou algum shell script), criando algo mais profissional e sólido, diminuindo o risco humano das operações (que normalmente é o que aumenta bem o IPM).
- Com o tempo quem vai cuidar dessas aplicações é o DBA júnior, que está aprendendo e no início de carreira, que consegue fazer a rotina sem dificuldade e não vai estar em apuros quando o DBA sênior estiver viajando.
• Em algum momento uma aplicação de fix no fim de semana vai dar problema e sua equipe vai ter que trabalhar para contornar a situação.
- É melhor que isso aconteça em um período controlado onde você se organizou, está descansado e potencialmente tem uma janela de manutenção maior ou menor impacto em produção, caso do serviço ficar fora do ar por mais tempo que o planejado.
- Sua equipe vai investir mais tempo trabalhando em uma estratégia para contornar os potenciais problemas e ser mais eficiente em caso de desastre. Esse estímulo e aprendizado pode trazer um retorno imenso para a organização quando o problema atinge seu ambiente em horários críticos.
• Sua equipe também vai pensar em alternativas de alta disponibilidade, que podem ter sido relegadas para segundo plano (por N motivos), ou vai ficando cada vez mais confortável com as operações, conhecendo tempos de movimentação de recursos, detalhes da rotina, análise de logs, etc.
• Sua equipe cria a cultura de acompanhar os releases, revisar os fixes e, invariavelmente vai aprender alguma coisa só de ler as referências dos KBs.
- Curiosamente nos últimos anos tive a experiência de acompanhar mais o fixes do DB2 do que tinha com o SQL Server, e aprendi muito com essa prática, então também estou adotando para o SQL Server.
E falo isso de experiência própria… Recentemente passei por isso com o DB2, pude aplicar os primeiros fixes como se fosse um júnior, criamos uma documentação madura e um passo a passo excelente, a equipe já sabia como lidar com problemas comuns e tempo médio das operações, deixei de trabalhar de madrugada para aplicar fix e estávamos caminhando para no futuro automatizar nossos processos. De quebra já sugerimos deixar uma infraestrutura mínima e ajustada, para subir rapidamente novos bancos de dados se necessário.
E se um fix der problema na madrugada de sábado? Ai pode me acordar e no papel de consultor ou DBA Sênior, vou lá ajudar a resolver a bagaça…
SEM PROBLEMA NO AMBIENTE
O argumento do "se não tem problema" não aplique o CU tem fundamento pelo aspecto de estabilidade.
Mas vamos a outras situações hipotéticas, usando como referência o Cumulative Update package 7 for SQL Server 2012 Service Pack 2: https://support.microsoft.com/en-us/kb/3072100.
• FIX: Indexed view returns incorrect result after insert or delete operation on the base table in SQL Server 2012 (https://support.microsoft.com/en-us/kb/3068439)
- Ok, correção importante, mas se ninguém reclamou então não deve estar acontecendo no nosso ambiente… Mas e se estiver? Você executou selects em todas as views indexadas e foi validar o resultado para saber que não está com o problema? Se existem relatórios que usam sua view indexada e está distribuindo valores incorretos, os usuários podem somente notar daqui a alguns dias ou quem sabe no próximo mês.
- Ou então você implementa uma nova view indexada e o resultado começa a dar errado, o que fazer? Tirar a funcionalidade do ar até sua janela de manutenção ou aplicar o fix no meio da semana?
• FIX: Hash or merge join hints may be ignored when you execute a query in SQL Server 2012 (https://support.microsoft.com/en-us/kb/3064454)
- Você encontrou um plano ruim e o QO não está te ajudando. Usa um serviço de consultoria e o Fabiano diz: coloca essa hint que o plano vai brilhar. Você faz o ajuste e nada… bug no SQL Server. Resolução aplicar o fix… quando? Está preparado? Mesma ladainha.
- Só que esse camarada ainda tem uma coisa muito importante, trace flag 4199, que muita gente não sabe da existência mas deve ser entendido e tratado com carinho, ainda mais que o comportamento padrão da engine vai mudar no SQL Server 2016 (https://support.microsoft.com/en-us/kb/974006). Aí você resolve ir na cara e na coragem e habilita o TF 4199 sem teste e no meio da semana… Olha o IPM aumentando aí!!!!
- Esse trace flag é importante e merece um post dedicado! Estou escrevendo e em breve estará no blog.
• FIX: CMEMTHREAD waits occur when you execute many ad hoc queries in SQL Server 2012 (https://support.microsoft.com/en-us/kb/3074425)
- Sua empresa comprou uma nova aplicação, que passou por homologação e funcionou tudo bem, pois não tinha massa crítica para ressaltar o problem. Chegou em produção e lambou tudo logo na manhã de segunda-feira.
- Resolução é aplicar o fix… quando? Está preparado? (Isso está ficando repetitivo…).
A fragilidade do argumento de não aplicar o fix se não têm problema é que você não consegue efetivamente testar todas as condições (até porque alguns KBs podem ser bem superficiais), e lembrando que o CU é cumulativo, então se você vai aplicar o CU #5 tem que revisar todos os outros também.
Soma-se a evolução das aplicações e funcionalidades adotadas, pode ser que na próxima semana um novo recurso colida com um bug já documentado e corrigido 4 CUs atrás… Eu não gostaria de esbarrar com um bug de corrupção de dados que já foi corrigido em um CU anterior.
RISCOS
É claro que não sou um idiota para achar que não existem riscos, sim eles existem.
E pode ser que você vá enfrentá-lo hoje ou daqui a três meses quando precisar aplicar o CU por conta de outro problema, então você precisa estar preparado.
Em uma pesquisa rápida na internet encontrei um caso de um DBA onde um CU voltou um comportamento antigo do SQL Server, que havia sido corrigido por um SP antigo, e trouxe problemas para a equipe que acabou por reinstalar o SQL Server (só faltou ele dar mais detalhes do CU e SP, então comento aqui mesmo correndo o risco de ser uma análise errada do DBA). E é uma pena, talvez pudesse ter passado sem essa, ou quem sabe estar calejado e conseguido colocar o banco no ar com maior agilidade.
E isso leva ao próximo ponto que muitos argumentam: comparativo de "qualidade" do cumulative update e service pack.
CU vs. SP
Outro ponto contra os CUs é que a bateria de testes executadas contra eles são menores que os SP.
Mesmo existindo pequenas diferenças entre os testes de CU/SP, houve uma grande melhoria dos testes dos CUs e a infraestrutura atual suporta testes de regressão em CUs, da mesma forma que acontece com o SP, então no que toca os "grandes pontos" dos testes, CU e SP passam pela mesma bateria.
DESEJO
Meu desejo real é que a Microsoft passasse a indicar formalmente a aplicação dos CUs, incluindo além de correção de bugs novas funcionalidades para a engine (o que já aconteceu!), permitindo que eu não tenha que esperar alguns anos ou uma nova versão por uma melhoria que poderia estar disponível hoje.
Acredito que esse modelo esteja muito mais alinhado com a tendência de releases constantes que estamos vendo acontecendo ao redor do mundo e, uma hora ou outra, teremos que nos ajustar.
A cultura de constante atualização também vai forçar que isso se espalhe pela organização, inclusive para os desenvolvedores que vão ter que acabar por melhorar seus testes (tenho outro "causo" que lembrei, mas esse post já está gigante :-) ).
Isso também pode te ajudar a evitar manter pequenos fantasmas no futuro, afinal tem gente administrando SQL 7.0 e 2000 em pleno ano de 2015. E uma vez que sua empresa está nesse modo de operação, também vai cobrar de seus fornecedores para acompanhar: "Tem uma aplicação de terceiro que exige modo de compatibilidade 2000, então não consigo migrar….".
SENDO REALISTA
Não são todas as equipes que estão preparadas para esse modelo, afinal ainda temos centenas de DBAs acidentais de SQL Server administrando (como podem) o seu ambiente. Então simplesmente sumir com o Service Pack não é algo viável, pois é um marco para muitas empresas.
Service packs e CUs podem ter bugs e trazer problemas, já vimos isso acontecer, então NÃO estou recomendando aplicar o fix no dia seguinte a sua liberação (a MS já tem um histórico sobre isso), por isso recomendo esperar pelo menos um mês para começar seu processo de atualização.
Com a cadência de release de 2 em 2 meses fica muito difícil acompanhar os CUs, então que tal começar de quatro em quatro meses?
IMPORTANTE: Sou um profissional e bancos de dados não devem ser tratados levianamente, e você deve fazer o mesmo. Estude, acompanhe, leia as alterações, entenda o que está sendo aplicado e trate com muito zelo o seu ambiente, pois um DBA despreparado pode causar a falência de uma empresa. Então TESTE, TESTE e TESTE, melhorando sempre todo seu ciclo de deployment.
CONCLUSÃO
Mesmo remando contra a maré, eu acredito que os benefícios de constantemente aplicar os CUs ultrapassam de longe os riscos de se ter uma cultura reativa.
Processos melhores, documentação e automatização, equipe mais preparada, datas controladas para fazer as atualizações, melhor integração com outras áreas, tudo isso faz com que sua equipe e organização amadureçam se tornem mais profissionais.
Claro que não é simples, você vai comprar brigas, vai ter que aprender a se dar bem com o desenvolvedor FDP, que também acha você um DBA FDP e babaca (quem sabe vocês não viram best friends!!) e isso não vai acontecer da noite para o dia. Mas sair da zona de conforto pode te fazer um bem danado e no longo prazo vai favorecer para que fique cada vez menor o IPM da sua equipe de DBAs e dos bancos de dados.
Agora se você prefere esperar o problema acontecer no meio da segunda feira após recebimento dos salários, com movimentações críticas acontecendo, fazer um processo que você não está acostumado, notar que no FDS o backup falhou e aplicar o fix torcendo para que tudo dê certo… É sua escolha. E prometo que vou acender uma vela por você!
PS: descobri também que não estou sozinho, lendo um thread vi que Aaron Bertrand e Glenn Berry também são a favor, inclusive o Glenn já escreveu sobre isso (http://sqlperformance.com/2013/03/system-configuration/sql-server-servicing).
PPS: já estou ouvindo piadinhas com o acrônimo "CU", mas em um post desse tamanho não tinha como deixar de usar as duas letras juntas...
====================== UPDATE 2016-03-29 =====================
A Microsoft agora recomenda que você proativamente aplique os CUs e não somente os Service Packs. Detalhes aqui: https://blogs.msdn.microsoft.com/sqlreleaseservices/announcing-updates-to-the-sql-server-incremental-servicing-model-ism/
============================================================
Abraços
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
SQL Saturday #469 Brasília
É com prazer que anuncio que o SQL Saturday #469 Brasília foi publicamente confirmado pelo PASS!!!
Novamente eu estou organizando o evento em Brasília, com o grande apoio da Faculdade Projeção, do MVP Luan Moreno e também de grandes amigos da comunidade técnica de Brasília e do Brasil (afinal já temos cadastro de voluntários de outras cidades!).
Muitos de vocês já conhecem o evento, que esteve na cidade em 2013 (http://luticm.blogspot.com.br/2013/10/como-foi-o-sqlsat-253.html), e foi muito bem recebido pelo público.
É claro que queremos melhorar a "versão 2" do evento, então estou trazendo as lições aprendidas em 2013 e tenho certeza que vamos superar a expectativa do público.
Não perca tempo, vá até o site do evento e garanta sua vaga!
E claro, não deixe de submeter sua palestra caso tenha interesse em palestrar no SQLSat Brasília.
http://www.sqlsaturday.com/469/EventHome.aspx
Abraços
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
quinta-feira, 16 de julho de 2015
[SQLServerDF] Encontro XXVI - Apresentando o DocumentDB
Coloco no blog o mesmo anúncio que foi para o grupo SQLServerDF...
Mais um encontro do grupo SQLServerDF, dessa vez vou falar um pouco sobre DocumentDB e passar para vocês um pouco do que estudei sobre ele. Mesmo não sendo um especialista no produto, acho que podemos bater um papo divertido.
De resto vocês já sabem o que fazer, por favor confirmar presença com nome e e-mail no google groups. Para aqueles que não estão no grupo, basta ir até http://groups.google.com/group/sqlserverdf, fazer sua inscrição e aguardar minha moderação
Data e horário: 29/07/2015, entre 18:00h e 20:00h
Local: Xperts Trainning Center
Palestrante: Luciano [Luti] Moreira
Título: Apresentando o DocumentDB
Descrição: Nesta sessão será apresentado o DocumentDB, que é um banco de dados NoSQL, classificado como "document-store". O serviço oferece capacidades ricas de pesquisa e processamento transacional, trabalhando com JSON em um modelo livre, permitindo escalabilidade da solução através dos serviços oferecidos. Ao fim da sessão você conhecerá os elementos fundamentais deste novo banco de dados da Microsoft.
Mini-cv do palestrante:
Luciano Moreira é sócio fundador da Sr. Nimbus. Especialista e MVP em SQL Server, vem buscando nos últimos anos explorar os detalhes de outros bancos de dados, relacionais ou não, além de estudar assuntos relacionados à arquitetura de soluções e ciência de dados. Divide seu tempo como profissional entre consultorias, treinamentos e comunidade técnica, ajudando empresas a projetar soluções, utilizar de forma eficiente os produtos e, claro, resolver problemas que envolvem banco de dados.
Xperts Trainning Center
SHIS QI 15 Conjunto 8/9 Área especial Bloco D, Subsolo - Lago Sul (ao final da rua)
CEP 71635-565 - Brasília - DF
Telefone: (61) 4063-8177 | 9545-9241
Ponto de referência: Próximo ao Hospital Brasília; Ao lado da escola Red Balloon;
Abraços
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
Mais um encontro do grupo SQLServerDF, dessa vez vou falar um pouco sobre DocumentDB e passar para vocês um pouco do que estudei sobre ele. Mesmo não sendo um especialista no produto, acho que podemos bater um papo divertido.
De resto vocês já sabem o que fazer, por favor confirmar presença com nome e e-mail no google groups. Para aqueles que não estão no grupo, basta ir até http://groups.google.com/group/sqlserverdf, fazer sua inscrição e aguardar minha moderação
Data e horário: 29/07/2015, entre 18:00h e 20:00h
Local: Xperts Trainning Center
Palestrante: Luciano [Luti] Moreira
Título: Apresentando o DocumentDB
Descrição: Nesta sessão será apresentado o DocumentDB, que é um banco de dados NoSQL, classificado como "document-store". O serviço oferece capacidades ricas de pesquisa e processamento transacional, trabalhando com JSON em um modelo livre, permitindo escalabilidade da solução através dos serviços oferecidos. Ao fim da sessão você conhecerá os elementos fundamentais deste novo banco de dados da Microsoft.
Mini-cv do palestrante:
Luciano Moreira é sócio fundador da Sr. Nimbus. Especialista e MVP em SQL Server, vem buscando nos últimos anos explorar os detalhes de outros bancos de dados, relacionais ou não, além de estudar assuntos relacionados à arquitetura de soluções e ciência de dados. Divide seu tempo como profissional entre consultorias, treinamentos e comunidade técnica, ajudando empresas a projetar soluções, utilizar de forma eficiente os produtos e, claro, resolver problemas que envolvem banco de dados.
Xperts Trainning Center
SHIS QI 15 Conjunto 8/9 Área especial Bloco D, Subsolo - Lago Sul (ao final da rua)
CEP 71635-565 - Brasília - DF
Telefone: (61) 4063-8177 | 9545-9241
Ponto de referência: Próximo ao Hospital Brasília; Ao lado da escola Red Balloon;
Abraços
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
Treinamento O(racle)PDT na Nerv
Como prometido, segue um breve relato do treinamento de Oracle que eu participei.
Entre os dias 17 e 19 de Junho eu estive em São Paulo para meu primeiro treinamento de Oracle. Como eu já tenho uma boa bagagem com banco de dados relacionais optei por um treinamento mais puxado, pois não sei se consigo mais encarar uma turma iniciante em qualquer tecnologia de banco de dados. Detalhe: nunca trabalhei com Oracle ou tinha visto a interface do SQLPLUS, já tinha lido algumas coisas do produto, então podia contar com imensos 0,000000092732% de conhecimento prévio do Oracle. O treinamento é o OPDT.
Escolhi fazer o treinamento com o Ricardo Portilho, responsável pela Nerv informática. O motivo? Por acreditar que ele é o tipo de profissional que tem um perfil técnico interessante, que não se limita ao básico e tem experiência, muita experiência com o Oracle. E enquanto escrevo este post eu notei um fato curioso, foi o primeiro treinamento que eu paguei do meu bolso (*** mais sobre isso abaixo).
O treinamento (óbvio) foi bem puxado, direto e prático. Diferente do modelo tradicional ou da forma como eu conduzo o treinamento Mastering do SQL Server, o instrutor fala de métricas e problemas enfrentados, sempre explicando em seguida detalhes da arquitetura e conceitos. Dentro do meu universo SQL Server e DB2 eu ficava o tempo inteiro traçando paralelos entre os SGBDRs, e confesso, quando a cabeça parecia que ia explodir eu saia um pouco da sala para tomar um ar. O treinamento também permite que os alunos possam colocar a mão na massa, explorar um pouco o Oracle e ainda conta com uma prova prática no fim do curso, o que deixa as últimas horas bbbbbeeeemmm animadas (e tenso!!).
Outro ponto positivo foi a estrutura da Nerv informática, mesmo com uma localização afastada do "coração" de São Paulo, a sala da casa, a cozinha para coffee-break e a sala de aula atendem perfeitamente a necessidade de treinamento e oferecem um ambiente convidativo, onde você literalmente se sente em casa. Um comentário, o treinamento não tem horário de coffee-break definido, isto é, sabe aqueles momentos em que você se desliga um pouco dentro de sala (sim, acontece com todos), você aproveita, desce, toma um café e logo em seguida volta para a sala pronto para se concentrar novamente… achei muito bom, pena que não vejo uma forma de fazer algo similar com o atual modelo de treinamento da Nimbus.
Conclusão: o treinamento foi excelente e valeu cada centavo investido. Felizmente minha aposta na Nerv estava certa e espero poder participar de outros treinamentos, além de dedicar um pouco de tempo para estudar mais o Oracle.
Abaixo algumas fotos que tirei e de quebra uma foto memorável: SQL Server & Oracle. :-)
*** Curiosamente este foi o primeiro treinamento formal que eu paguei do bolso (não me lembro de desembolsar um centavo me matriculando em qualquer outro curso). Enquanto estive na Hepta eu podia assistir os treinamentos como ouvinte, depois disso por todo lugar que eu passei a empresa investiu em minha capacitação (MRE, Microsoft, Sicoob). No caso da Nimbus, eu paguei as viagens para PASS e MVP Summits, mas formalmente não fiz investimento em nenhum treinamento (já que tenho acesso aos eventos).
E isso só confirma algo que digo sempre: se sua empresa não investe em você, tem algo errado. Ou a empresa tem uma péssima política para seus funcionários ou você não está conduzindo seu trabalho de forma que a empresa queira investir em sua capacitação. Então se qualquer dia você se pegar falando a frase "A empresa não investe em minha capacitação", você tem duas escolhas: mude seu comportamento ou mude de empresa. Afinal, o mercado é uma mãe e vaga, caro leitor, não falta….
Abraços
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
Entre os dias 17 e 19 de Junho eu estive em São Paulo para meu primeiro treinamento de Oracle. Como eu já tenho uma boa bagagem com banco de dados relacionais optei por um treinamento mais puxado, pois não sei se consigo mais encarar uma turma iniciante em qualquer tecnologia de banco de dados. Detalhe: nunca trabalhei com Oracle ou tinha visto a interface do SQLPLUS, já tinha lido algumas coisas do produto, então podia contar com imensos 0,000000092732% de conhecimento prévio do Oracle. O treinamento é o OPDT.
Escolhi fazer o treinamento com o Ricardo Portilho, responsável pela Nerv informática. O motivo? Por acreditar que ele é o tipo de profissional que tem um perfil técnico interessante, que não se limita ao básico e tem experiência, muita experiência com o Oracle. E enquanto escrevo este post eu notei um fato curioso, foi o primeiro treinamento que eu paguei do meu bolso (*** mais sobre isso abaixo).
O treinamento (óbvio) foi bem puxado, direto e prático. Diferente do modelo tradicional ou da forma como eu conduzo o treinamento Mastering do SQL Server, o instrutor fala de métricas e problemas enfrentados, sempre explicando em seguida detalhes da arquitetura e conceitos. Dentro do meu universo SQL Server e DB2 eu ficava o tempo inteiro traçando paralelos entre os SGBDRs, e confesso, quando a cabeça parecia que ia explodir eu saia um pouco da sala para tomar um ar. O treinamento também permite que os alunos possam colocar a mão na massa, explorar um pouco o Oracle e ainda conta com uma prova prática no fim do curso, o que deixa as últimas horas bbbbbeeeemmm animadas (e tenso!!).
Outro ponto positivo foi a estrutura da Nerv informática, mesmo com uma localização afastada do "coração" de São Paulo, a sala da casa, a cozinha para coffee-break e a sala de aula atendem perfeitamente a necessidade de treinamento e oferecem um ambiente convidativo, onde você literalmente se sente em casa. Um comentário, o treinamento não tem horário de coffee-break definido, isto é, sabe aqueles momentos em que você se desliga um pouco dentro de sala (sim, acontece com todos), você aproveita, desce, toma um café e logo em seguida volta para a sala pronto para se concentrar novamente… achei muito bom, pena que não vejo uma forma de fazer algo similar com o atual modelo de treinamento da Nimbus.
Conclusão: o treinamento foi excelente e valeu cada centavo investido. Felizmente minha aposta na Nerv estava certa e espero poder participar de outros treinamentos, além de dedicar um pouco de tempo para estudar mais o Oracle.
Abaixo algumas fotos que tirei e de quebra uma foto memorável: SQL Server & Oracle. :-)
*** Curiosamente este foi o primeiro treinamento formal que eu paguei do bolso (não me lembro de desembolsar um centavo me matriculando em qualquer outro curso). Enquanto estive na Hepta eu podia assistir os treinamentos como ouvinte, depois disso por todo lugar que eu passei a empresa investiu em minha capacitação (MRE, Microsoft, Sicoob). No caso da Nimbus, eu paguei as viagens para PASS e MVP Summits, mas formalmente não fiz investimento em nenhum treinamento (já que tenho acesso aos eventos).
E isso só confirma algo que digo sempre: se sua empresa não investe em você, tem algo errado. Ou a empresa tem uma péssima política para seus funcionários ou você não está conduzindo seu trabalho de forma que a empresa queira investir em sua capacitação. Então se qualquer dia você se pegar falando a frase "A empresa não investe em minha capacitação", você tem duas escolhas: mude seu comportamento ou mude de empresa. Afinal, o mercado é uma mãe e vaga, caro leitor, não falta….
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
quinta-feira, 2 de julho de 2015
Treinamentos Nimbus - 2o semestre 2015
Preparando agenda de treinamentos da Nimbus e… está complicadíssimo.
Estou com uma dificuldade tremenda em montar uma grade com os cursos para o segundo semestre. Já tenho algumas turmas fechadas diretamente com empresas, projetos em outros clientes e alguns eventos, como Insight Brasil (ex-Teched), PASS Summit e MVP Summit.
Além disso, como já comentei com muitos, vou investir mais tempo em modelos de treinamento que saem do formato presencial. Então lá vai…
Serão dois treinamentos presenciais com turmas abertas para o segundo semestre de 2015:
Será que tem público? Esse seria bbbeeemmm divertido…
Um treinamento não-presencial que segue o novo modelo de treinamento que estou propondo para a Sr. Nimbus:
Para os outros treinamentos, fiquem atentos aos on-demand…
Abraços
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
Estou com uma dificuldade tremenda em montar uma grade com os cursos para o segundo semestre. Já tenho algumas turmas fechadas diretamente com empresas, projetos em outros clientes e alguns eventos, como Insight Brasil (ex-Teched), PASS Summit e MVP Summit.
Além disso, como já comentei com muitos, vou investir mais tempo em modelos de treinamento que saem do formato presencial. Então lá vai…
Serão dois treinamentos presenciais com turmas abertas para o segundo semestre de 2015:
- SQL Server 2014: Mastering the databsase engine (http://www.srnimbus.com.br/calendario/sql23_spdez2015/)
- Tenho 3 dias antes do TechEd em Setembro, e estou na dúvida do que devo publicar:
- 3 dias de indexação no SQL Server (http://www.srnimbus.com.br/sql16/)
- 3 dias de "SQL Server - Tópicos avançados"
Será que tem público? Esse seria bbbeeemmm divertido…
Um treinamento não-presencial que segue o novo modelo de treinamento que estou propondo para a Sr. Nimbus:
- Integration Services 2012: On-demand (6 meses) - CONFIRMADO (http://www.srnimbus.com.br/calendario/integration-services-2012-on-demand-6-meses/)
Para os outros treinamentos, fiquem atentos aos on-demand…
Abraços
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
quarta-feira, 1 de julho de 2015
SQL Server MVP 6.0
01 de Julho de 2015, mais um ano renovado como Microsoft Most Valuable Professional (MVP) na especialidade SQL Server. Curiosamente ontem foi meu último dia no Sicoob, uma coincidência legal, pois junto com o ânimo das mudanças e meu retorno full-time para a Nimbus, aproveito também para comemorar o MVP 6.0!
Espero contribuir ainda mais com a comunidade técnica de SQL Server e poder ajudar profissionais do mundo todo. E obrigado a todos que leem este blog e as tranqueiras que eu escrevo.
De quebra, junto com a mudança eu aproveitei e dei uma repaginada no escritório, inclusive sei que vou aproveitar para ler alguns livros atrasados e revisitar outros. Abaixo porque evito comprar muitos mais livros impressos… Isso que ainda estão alguns outros e essa é só a estante técnica. :-)
Abraços
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
Espero contribuir ainda mais com a comunidade técnica de SQL Server e poder ajudar profissionais do mundo todo. E obrigado a todos que leem este blog e as tranqueiras que eu escrevo.
De quebra, junto com a mudança eu aproveitei e dei uma repaginada no escritório, inclusive sei que vou aproveitar para ler alguns livros atrasados e revisitar outros. Abaixo porque evito comprar muitos mais livros impressos… Isso que ainda estão alguns outros e essa é só a estante técnica. :-)
Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br
Assinar:
Postagens (Atom)