Os Powers no Excel 2016

Hoje, após finalizar o upgrade do Windows 10 e testar todos os aplicativos para ver as perdas, finalmente resolvi instalar o Office 2016 Professional Retail no meu notebook.

Office instalado e ativado, fui conferir as funcionalidades da família Power, uma vez que a versão que eu tinha acesso não ativava esses recursos (Office 365 Home Premium).

Primeira verificação, ativar Power Pivot e Power View no Excel, nas opções de Com Add-Ins:


Opções do Excel
.


Gerenciador de Add-ins

Seleção de Add-ins

Com os Add-Ins selecionados, vamos ver as abas e ribbons do Excel, de cara a aba do Power Pivot já aparece no local esperado:



Agora, vamos ver como esta o Power Query, não instalei nenhum suplemento. O Power Query já foi incorporado na ribbon New Query, na aba Data, conforme imagem abaixo:


O Power Maps apareceu como ribbon após ativado, não foi preciso instalar nenhum plugin, mas e o Power View? O mesmo não está presente na aba Insert, local onde era disponível na versão 2013.


Durante a instalação, o Marcos, meu colega de trabalho, que escreve para o blog Dataficação, comentou comigo que agora era necessário incluir a ribbon manualmente. Comecei a procurar nas propriedades e customizações do Excel, apesar do Power View estar marcado como ativo, não consegui adicionar a ribbon do Power View. Ai, o Marcos me passou o link deste blog, onde fala como adicionar a mesma.

Nas opções do Excel, acesse a opção customize ribbon, e na coluna direita, expanda a opção Insert.
Depois de selecionar a opção Insert, clique em New Group:

Seguindo o exemplo do post,  troquei o nome do grupo para Insert Report:



Agora na coluna da esquerda, em Choose commands from, selecione a opção Commands Not in the Ribbon.



Com o grupo Insert Report selecionado do lado direito adicione o comando Insert a Power View Report.


Pronto, a ribbon já está disponível na aba Insert:



Lembrando que a versão do Office 2016 ainda está no Preview, então, até o lançamento oficial, isso pode mudar. Vamos acompanhar as novidades de perto, a seguir, estarei escrevendo sobre o Datazen, nova forma de disponibilizar dashboards e KPIs para dispositivos mobile.

Até a próxima!!!

Cursos Microsoft na plataforma edX

A Microsoft anunciou a criação de alguns cursos online, na plataforma edX. Para quem não conhece, o edX é uma plataforma de cursos online, mantida pelas universidades de Harvard e MIT (Massachusetts Institute Technology), o qual tem o objetivo de oferecer cursos abertos voltados para as massas (MOOCS na sigla em inglês). Os treinamentos nessa…

Non-foldable expressions e o QO

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

Microsoft SQL Server 2016 – Lista de Novidades – Final

Bom dia, bom dia, bom dia!!!!! Meu deus que friooooo, neste momento 4.5º graus de temperatura em São Roque e região, para começar o dia esquentando nada como tentar escrever mais um post no meu blog, posso dizer que não é uma missão fácil, pois a chuva de conteúdo que esta na internet sobre o […]

Inserindo registros usando INSERT/SELECT

Recentemente precisei realizar testes de desempenho de disco, simulando diversas operações como SELECT e INSERT, porém para tal eu necessitava de tabela(s) com registros para os testes, e um problema que encontrei foi: como inserir os registros ? Inicialmente a primeira opção que me veio á cabeça foi usar um loop WHILE, inserindo 100 mil…

Pre-Con SQL Saturday 424 – São Paulo

Pessoal, Não sei se todos ja sabem, mas teremos em São Paulo uma Pré-Conference no dia 25 de Setembro na UNIP Tatuapé. Para quem ainda não conhece, a Pré-Conference é um workshop de 8 horas realizado sempre um dia antes do SQL Saturday. O valor cobrado na Pré-Conference é apenas para cobrir os custos de […]

PROBLEMA: The PowerShell subsystem failed to load \ SUSPENDED JOB \ MSDB – SYSSUBSYSTEMS


Olá pessoal tudo certo? Espero que sim!

Estes dias passei por um problema bem curioso envolvendo o SQL Server Agent de uma instância do SQL Server 2008, vou descrever abaixo o ocorrido e como cheguei a uma solução.

Havia um job no SQL Server Agent com um único step do tipo PowerShell. O job estava desabilitado já tinha um tempo, mas após uma solicitação para execução manual, falhou com o seguinte erro:

Unable to start execution of step 1 (reason: The PowerShell subsystem failed to load [see the SQLAGENT.OUT file for details]; The job has been suspended).  The step failed.

Apesar do job ter falhado, em vez de ficar com o status de “IDLE”, ele ficou marcado como “SUSPENDED”. No Job Activity Monitor a opção de Stop Job ainda continuava disponível, mas ao ser acionada gerava uma mensagem de erro, indicando que o job não estava rodando:



No SQLAGENT.OUT, arquivo com o log de erros do SQL Server Agent, a seguinte mensagem estava registrada:

 [LOG] Step 1 of job ‘JOB_NAME’ (0xEE18D4FFB66BE246A781DACB9C1D0FB0) cannot be run because the PowerShell subsystem failed to load.  The job has been suspended

No início do SQLAGENT.OUT havia uma mensagem mais específica relacionada ao PowerShell:

 [432] There are 12 subsystems in the subsystems cache
 [125] Subsystem 'PowerShell' could not be loaded (reason: 3)

No SQL Server Agent, um subsistema é um componente de execução para o qual pode ser definido um Proxy (https://msdn.microsoft.com/en-us/library/ms174368(v=sql.110).aspx). No msdb existe uma tabela chamada syssubsystems, com todos os sub-sistemas que o SQL Server Agent suporta e informações sobre a sua execução. O PowerShell é um destes sub-sistemas, como pode ser visto na saída da query abaixo:

SELECT * FROM MSDB.DBO.SYSSUBSYSTEMS WHERE SUBSYSTEM = 'POWERSHELL'


A coluna agent_exe aponta para o sqlps.exe, utilitário que implementa o SQL Server PowerShell provider e suas cmdlets. No SQL Server Agent com o job em “SUSPENDED” o caminho informado para o sqlps.exe era inválido, o que explica a mensagem de erro indicando que o PowerShell não pôde ser carregado.

Pesquisando na Internet encontrei alguns sites mencionando a deleção de todas as linhas da tabela syssubsystems, e a execução da procedure sp_verify_subsystems para que ela populasse novamente esta tabela com as informações corretas dos componentes. Contudo, pelo fato de ser uma alteração em uma base de sistema, queria mexer o mínimo possível, portanto resolvi fazer o seguinte:

1. Backup full do msdb.

2. Alteração manual apenas da linha do Powershell na tabela syssubsystems, informando o caminho correto para o sqlps.exe:

USEMSDB
GO

UPDATESYSSUBSYSTEMS SET AGENT_EXE = 'C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\SQLPS.exe' WHERE SUBSYSTEM = 'POWERSHELL'
GO

3. Restart no SQL Server Agent.

4. Conferir se o caminho do sqlps.exe ficou correto na tabela syssubsystems.

Depois deste procedimento, rodei o job novamente e obtive SUCESSO!

Testes e descobertas...

Simulando o cenário no SQL Server 2008

Vamos simular o cenário numa instância do SQL Server 2008, lembrando que a simulação vale também para um SQL Server 2008 R2.

1. Abra o Management Studio.

2. Crie um novo job no SQL Server Agent com um único step do tipo PowerShell, usando algum script simples que você possua No meu caso vou usar um script simples que lista todos os serviços do Windows. O meu step ficou da seguinte forma:




Salve o job sem criar nenhum schedule.

3. Rode o comando abaixo e salve o resultado:

SELECT agent_exe FROMMSDB.DBO.SYSSUBSYSTEMS WHERE SUBSYSTEM ='POWERSHELL'

4. Faça um backup full do msdb, e rode o comando abaixo para mudar propositalmente o caminho do sqlps.exe.

UPDATE MSDB.DBO.SYSSUBSYSTEMS SETagent_exe = '***SQL MAGU***' WHERE SUBSYSTEM = 'POWERSHELL'

5. Reinicie o SQL Server Agent.

6. Confirme que o caminho para o sqlps.exe continua com a sua alteração.

SELECT agent_exe FROM MSDB.DBO.SYSSUBSYSTEMS WHERE SUBSYSTEM = 'POWERSHELL'


7. Agora tente executar o job. Note que o status é ajustado para “SUSPENDED”:



8. Clique em Close e consulte o histórico de execução. Note que o job falhou com um erro do sub-sistema do PowerShell:




9. Abra o Job Activity Monitor e confirme que o status do job é “SUSPENDED” e não “IDLE”. Apesar da falha, a opção de Stop Job continua ativa.




10. Vamos agora corrigir o problema. Rode o seguinte comando, trocando a parte em destaque pelo diretório correto do sqlps.exe na sua instalação:

UPDATE MSDB.DBO.SYSSUBSYSTEMS SETagent_exe = 'C:\Program Files\Microsoft SQL Server\100\Tools\Binn\SQLPS.exe'WHERE SUBSYSTEM ='POWERSHELL'

11. Reinicie o SQL Server Agent.

12. Verifique se o caminho para o sqlps.exe está realmente correto:

SELECT agent_exe FROMMSDB.DBO.SYSSUBSYSTEMS WHERE SUBSYSTEM ='POWERSHELL'

13. Tente rodar o job novamente:




Sucesso desta vez! Problema corrigido!

Simulando o cenário no SQL Server 2012

A partir do SQL Server 2012 a coisa muda um pouco, no sentido dele ter diminuído a probabilidade destas inconsistências acontecerem. Para confirmar isto, execute o procedimento anterior até o passo 5. Note que apesar de você ter trocado o diretório propositalmente, após o restart do SQL Server Agent ele se acertou automaticamente! Mas por que isso aconteceu? Para tentar entender, vamos fazer o seguinte:

1. Crie um trace contra a sua instância do SQL Server 2012. Inclua apenas o evento de SP:Completed, com o nome da aplicação filtrado para “%SQLAgent%”.

2. Se o SQL Server Agent estiver rodando, reinicie-o e fique atento ao trace.

3. Note que ao iniciar o SQL Server Agent executa duas procedures:

sp_verify_subsystems
sp_enum_sqlagent_subsystems_internal

Ambas as procedures manipulam a tabela syssubsystems. Se você obtiver o mesmo com o SQL Server Agent do SQL Server 2008 também verá as mesmas procedures executando. Então o que mudou? No SQL Server 2012, obtenha o texto da procedure sp_verify_subsystems e repare no seguinte trecho:

-- Fix for #525111 - when MSDB is restored from any other sqlserver, it is possible that physical path to agent_exe, subsystem_dll may not be valid on current server
--  It is better to delete all records in this table and reinsert them again
-- perform delete and re-insert operations within a transaction
TRUNCATE TABLE syssubsystems

Pois é pessoal! Este truncate no código foi implementado do SQL Server 2012 em diante, notem que o comentário fala de um restore da MSDB, mas alerto que podem existir outros cenários onde isso pode acontecer, vejam abaixo alguns links que discutem problemas similares:

 


Era isso pessoal! A dica é sempre ficar atento quando estiver realizando reinstalações e manobras com instâncias de versões anteriores ao SQL Server 2012, com ou sem o restore do msdb.
http://www.virtualpass.com.br/

Database Mirroring

Surgido no SQL Server 2005 esta tecnologia consegue realizar a “cópia” da database do servidor primá

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...

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
Go to Top