sexta-feira, 5 de fevereiro de 2010

Nova série: Perguntas intrigantes do SQL Server

Bom dia pessoal.

Algumas coisas na vida são curiosas, quando você está aprendendo uma nova tecnologia as dúvidas te parecem complexas, mas usualmente são simples e com uma resposta direta, você entende e aceita.
Depois que você se aprofunda na tecnologia, as mesmas perguntas podem ter tantos desdobramentos interessantes e variáveis que afetam sua resposta, que eventualmente você se vê pego pensando em exceções e complexidades inerente ao problema, que podem nem interessar a quem perguntou.

Como consultor e instrutor sempre encaramos perguntas e várias vezes, depois que ouvi o questionamento, fico com o dilema na cabeça: será que o "aluno" está pensando nas variáveis X, Y e Z? Devo responder de forma direta "funciona assim e pronto" ou problematizar um pouco mais detalhando vários cenários? Na primeira abordagem eu corro o risco de ser superficial decepcionando o ouvinte, na segunda eu posso viajar tanto que farei o público dormir ou pensar que estou sob efeito de drogas. Um dilema usual, que acabo normalmente seguindo pelo segundo caminho… paciência.

Como eu já brinco com o SQL Server faz um tempinho, acho que sou capaz de sugerir situações obtusas para tantos cenários e funcionalidades que resolvi colocar um pouco para fora. Quem sabe um brainstorm com vocês não deixa a coisa mais divertida?


Modelo de alocação no SQL Server

Sempre que ensino sobre o modelo de alocação do SQL Server eu falo:

As primeiras oito páginas de um índice (também heap) são alocadas em extents mistos e a partir da nona página um extent uniforme é alocado para o índice. Tudo isso é controlado pela GAM/SGAM e
a IAM, que possui oito slots para essas páginas "soltas" em sua estrutura. Analisamos com DBCC PAGE e tudo fica claro.

Depois eu menciono sobre o trace flag 1118, dizendo que ele muda o modelo de alocação da instância, partindo direto para a alocação de um extent uniforme, sem utilizar as páginas dos extents mistos. A vantagem é uma menor contenção na SGAM, em contrapartida você pode estar perdendo um pouco de espaço alocado e sem dados.


Vamos aos questionamentos...

Q: Habilitar ou não o trace flag 1118?

R: O SQL Server 2005 trouxe otimizações para a TempDB (http://technet.microsoft.com/en-us/library/cc966545.aspx), então a princípio você não precisaria mais da trace flag, mas ela continua funcional e ainda é usada pelo time de suporte em casos extremos (http://blogs.msdn.com/psssql/archive/2008/12/17/sql-server-2005-and-2008-trace-flag-1118-t1118-usage.aspx).
Vemos resposta similar também a essa pergunta enviada para o Bob Dorr de um conhecido ninja aqui do Brasil (http://blogs.msdn.com/psssql/archive/2009/06/04/sql-server-tempdb-number-of-files-the-raw-truth.aspx).


Q: Por que o SQL Server não acaba o modelo de alocação misto?

Eu me faço essa pergunta com frequência. Qual o ganho desse modelo para bancos de dados de usuário? Potencialmente você vai jogar fora 56K com tabelas muito pequenas (de uma página). Tá legal, se eu tiver 5000 tabelas com essa característica, então vou desperdiçar 273 MB. Valeria a pena? Me parece que sim.

Será que existe outro motivo, além do ganho de espaço, para manter esse modelo? Não me vem nada de imediato a mente...

Já na TempDB o impacto dessa alteração pode ser bem maior, minimizando uma possível contenção que ainda pode acontecer, mas potencialmente fazendo com que seu banco temporário cresça muito mais, pois a probabilidade de existirem muitos objetos pequenos simultaneamente é maior. O problema de espaço versus o problema de contenção me parece a chave aqui, qual ganha?

O que você acha desse assunto?
O modelo ainda é útil?

Correndo um enorme risco de cometer alguma injustiça e falar besteira, deixo alguns palpites.

- O modelo de alocação original fazia mais sentido no passado, hoje o ganho de espaço parece irrisório. - Porém os ganhos em mudar o modelo de alocação também não serão grandes, então porque sair tocando em uma peça tão fundamental e sensível da engine? Acho que a chance de trazer mais problemas é maior do que os ganhos.
- Pensando nisso, o time de produto prefere manter o modelo de alocação atual e otimizar onde costuma doer mais, a TempDB. Então vemos novos e inteligentes artifícios para minimizar o impacto de workloads que utilizam muito nosso banco temporário.

Pensando nisso, por mais que o modelo não me pareca tão útil, pensando como o dono do produto eu provavelmente não gastaria tempo da minha equipe para tocar nesse código, e sim para introduzir outras novidades.

Faz sentido o que eu disse para vocês? Seria gostoso conversar com o time de produto e entender algumas motivações, como essa.

Como referência deixo aqui dois artigos muito bons: http://www.sqlskills.com/BLOGS/PAUL/post/Misconceptions-around-TF-1118.aspx. Detalhe: adorei a parte em que o Paul fala da quantidade de arquivos da TempDB, sempre falo isso nos meus treinamentos e agora tenho uma fonte mais confiável. :-)
http://sqlblog.com/blogs/linchi_shea/archive/2007/08/07/reduce-the-contention-on-tempdb-with-trace-flag-1118-to-enable-or-not-to-enable.aspx

Os KBs conhecidos:
http://support.microsoft.com/kb/328551/en-us
http://support.microsoft.com/kb/936185/en-us

Esse foi o primeiro da série "Perguntas intrigantes do SQL Server". Espero que tenha gostado.

PS: era para ter sido um post rápido. Acho que estou precisando de colocar essas idéias para fora com mais frequência.

[]s
Luciano Caixeta Moreira - {Luti}
Chief Innovation Officer
Sr. Nimbus Serviços em Tecnologia Ltda
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm

quinta-feira, 4 de fevereiro de 2010

Compressão de registro no SQL Server 2008

(Para melhor visualização, baixe AQUI o pdf.)

Compressão de dados não é lá novidade, então vamos brincar de internals...

Uma das novas funcionalidades do SQL Server 2008 é a possibilidade de compactar os registros dentro de uma página, sendo possíveis duas abordagens: registro e página. A compressão de registro transforma as colunas de tamanho fixo (INT, CHAR, ROWVERSION, etc.) em tamanho variável, e a compressão de página, além de aplicar a compressão de registro, irá fazer a compressão de prefixo e dicionário.

A compressão de dados é importante para diminuir a utilização do espaço em disco (você ganha os benefícios colaterais disso), e por outro aspecto muito importante, que às vezes fica relegado a segundo plano. Potencialmente a compressão de dados vai melhorar a eficiência da cache de dados, pois se caberão mais registros em uma página de 8K, então mais registros serão colocados no mesmo espaço em memória e a probabilidade do acerto em cache acontecer também aumenta. Lindo, não?

Pensando um pouco no assunto, seria extremamente ineficiente se o SQL Server 2008 utilizasse o mesmo mecanismo do tipo VARCHAR, pois ele já gasta de largada mais dois bytes em cada registro (valor exato por simplificação). Se fosse um inteiro (4 bytes) acabaríamos somente tendo ganho quando armazenássemos um valor menor que 127 (1 byte), pois depois disso o overhead deixaria o campo variável com o mesmo tamanho da coluna fixa (2 + 2 = 4) e a partir de 3 bytes a compressão iria perder espaço.

Como claramente o mecanismo tem que outro (VARDECIMAL é assim), vamos analisar um pouco a compressão de registro nesse artigo, mais especificamente CD (column descriptor) e a short data region. Primeiramente execute o script abaixo para criar uma tabelinha boba que servirá de exemplo.

Nota: número das páginas, local, distribuição, entre outros, podem variar de exemplo para exemplo, então siga o raciocínio.

Script 01: Tabela para teste

USE Inside
go

IF OBJECT_ID('CompressaoDados') IS NOT NULL
DROP TABLE CompressaoDados
go

CREATE TABLE CompressaoDados
(Codigo BIGINT IDENTITY PRIMARY KEY NOT NULL,
Nome VARCHAR(100) NOT NULL,
Idade BIGINT NOT NULL,
SeloTempo ROWVERSION NOT NULL)
GO

DECLARE @I INT
SET @I = 1
WHILE (@I <>
BEGIN
INSERT INTO CompressaoDados (Nome, Idade) VALUES (CAST(NEWID() AS VARCHAR(40)) + CAST(NEWID() AS VARCHAR(40)), @I % 100)
SET @I = @I + 1
END
go

Com a tabela criada, aproveitamos para olhar os dados e também algumas informações das unidades de alocação (script 02). Aqui podemos notar uma tabela com 473 páginas de dados, sendo a primeira na posição 22 (0x00000016).

Script 02: unidades de alocação

SELECT TOP 100 * FROM CompressaoDados
go

SELECT AU.*
FROM sys.system_internals_allocation_units AS AU
INNER JOIN SYS.Partitions AS P
ON AU.Container_id = P.Partition_id
WHERE Object_ID = object_id('CompressaoDados')
go

A página atual mantém os registros no formato que você já conhece desde o SQL Server 7.0, o FixedVar, conforme podemos notar através do DBCC PAGE (figura 01). Aqui podemos ver algumas coisas importantes, no cabeçalho temos a quantidade de registros por página (m_SlotCnt = 74), o tamanho do registro em 107 bytes e o espaço sendo desperdiçado com o tamanho fixo dos campos bigint e rowversion.



(Figura 01)

Com base no que nós discutimos até agora, pergunto: Essa página irá se beneficiar com compressão de registro? E de página?

R: registro sim, pois temos espaço sendo desperdiçado em colunas de tamanho variável. Já de página, muito provavelmente não. Consegue ver o motivo? Espero que sim, em outro post ou comentário eu volto a esse assunto.

Vamos habilitar compressão de registro e ver o resultado da compressão através da consulta 02, aproveitando para executar um DBCC PAGE na página 648 (0x00000288). Vemos que a tabela ocupa agora 381 páginas ao invés das 473 originais, o número de registros por página aumentou para 93 (figura 02 - que beleza!), o tamanho do primeiro registro é de 85 bytes (contra os antigos 107) e os registros na página estão ocupando pouco espaço (nada de muitos zeros no meio). Viu?


Script 03: compressão e análise

ALTER TABLE CompressaoDados
REBUILD WITH (DATA_COMPRESSION = ROW);
GO

SELECT AU.*
FROM sys.system_internals_allocation_units AS AU
INNER JOIN SYS.Partitions AS P
ON AU.Container_id = P.Partition_id
WHERE Object_ID = object_id('CompressaoDados')
go

DBCC PAGE (8, 1, 648, 3)


(Figura 02)

É interessante notar que agora o formato do registro mudou e cada registro possui um cabeçalho, column descriptor, que fala o tamanho de cada campo (4 bits por campo), uma short data region (para colunas de até 8 bytes) e um long data region (maiores de 8 bytes). No nosso caso não precisamos de ponteiros de 1byte para os clusters de short data, que são compostos por 30 colunas, pois somente temos quatro colunas (o que cabe em um cluster).
No início do registro temos a informação 2104a232, quebrando-a em bytes temos...
21 (0010 e 0001) = header - Significa registro no formato CD, primário e coluna long.
04 = Número de colunas nesse registro.
A2 = Primeira coluna têm um byte, segunda coluna é longa (mais de 8 bytes)
32 = Terceira coluna têm um byte, quarta coluna têm dois bytes.

Então esse registro pode compactar bem as colunas, pois somente estamos com valores pequenos, mas o mesmo se manteria em todos os registros? Claro que não, vamos navegar na cadeia de páginas para a próxima de nosso índice e achar os registros de código 127 e 128. O DBCC Page da página 649 (m_nextPage) mostra claramente quando 1 byte não é mais suficiente para armazenar o código, pulando para 2 bytes a partir desse momento.



(Figura 03)

Aqui vemos o registro passando de 85 para 86 bytes de tamanho e o espaço necessário para a primeira coluna salta de um para dois bytes. Nos quatro bits de descrição vemos a mudança de 2 para 3 (nota: o slotcnt saiu de 93 para 92, como esperado). Interessante, não? Isso vai acontecer novamente para a coluna Código? Sim, quando chegarmos ao 32768 veremos outra alteração no tamanho necessário para o campo código.

Quer ver essa mudança? Então aproveite uma nova função no SQL Server para ver o local físico de cada um dos seus registros. Sys.fn_PhysLocFormatter(%%PHYSLOC%%), encontre o 32768 e DBCC PAGE nele! Exemplo: (1:1060:14) 32768 => arquivo 1, página 1060, slot 14.

SELECT SYS.fn_PhysLocFormatter(%%PHYSLOC%%) AS RID, Codigo
FROM CompressaoDados
WHERE Codigo between 32700 and 32800

Espero que você possa ter entendido um pouco da compressão de registros e consiga fazer melhores análises críticas sobre o uso do recurso no SQL Server 2008. Ainda existem mais detalhes sobre a formação do CD, short data com mais colunas e long data, além da compressão de página que pretendo abordar em um outro artigo.
O SQL Server 2008 R2 trás novidades na compressão UNICODE, o jeito é brincar com ele também para ver as diferenças.

O script está disponível no endereço:
http://cid-e145f7753042d628.skydrive.live.com/self.aspx/Public/BlogPosts/20100204^_RowCompressionInternals.zip

[]s
Luciano Caixeta Moreira - {Luti}
Chief Innovation Officer
Sr. Nimbus Serviços em Tecnologia Ltda
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm

PASS Summit 2010. Quem vai?

Bom dia pessoal.
Esse ano eu também estou planejando ir para o PASS Summit 2010 que vai acontecer em Seattle, durante os dias 8 e 11 de novembro. Depois que voltei do evento no ano passado e durante as minhas palestras no SQLServerDF, muitas pessoas me disseram que querem ir nesse ano. Será?
Então vou plantar uma sementinha aqui...

Quem estiver interessado em participar do evento nesse ano, mande um e-mail o quanto antes para luciano.moreira@srnimbus.com.br. Vou catalogar os interessados e poderemos tentar desconto para grupos, na passagem e hospedagem. Além de ser divertido viajar com mais SQL geeks.

É barato? Não.
Vale a pena? Cada centavo!


Quer ter uma noção do que é o PASS Summit? Eu preparei uma pequena apresentação que fiz no SQLServerDF no ano passado e disponibilizei-o aqui.



Que algumas dicas para fazer o dinheiro valer mais?

- Aproveite a viagem para atualizar o guarda-roupas. Sempre passamos no outlet e gastamos mais, apesar da contradição, no fim das contas vale muito a pena, pois no Brasil o preço seria duas ou três vezes maior.
- Engate umas férias. Porque não aproveitar que já está lá fora e conhecer outro lugar? O caro mesmo é a viagem para o exterior, pegue um avião e conheça outro local, fique mais em Seattle ou então dê uma passadinha no Canadá já que estamos quase lá (Vancouver é linda!).
- Será que você não consegue justificar e sua empresa a pagar parte do investimento? Afinal é um excelente treinamento.

Bom, eu tenho mais dicas para os interessados, mas o botton line é: se você trabalha com SQL Server, o melhor lugar do mundo para estar em novembro é no PASS Summit. Só quem já viveu pode falar o quanto é fantástico.

Acho que é importante você ir para o PASS atrás das sessões casca-grossa, pois pagar todos os custos para ver sessões nível 100/200 não vale a pena! E esteja com o inglês em dia.

E uma coisa que estou esperando para esse evento... Vamos ouvir sobre o SQL11? Tomara que sim. Ai que vontade...

Vamos? ;-)
Mais info: http://www.sqlpass.org/summit/na2010/

[]s
Luciano Caixeta Moreira - {Luti}
Chief Innovation Officer
Sr. Nimbus Serviços em Tecnologia Ltda
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm

quarta-feira, 3 de fevereiro de 2010

Calendário de treinamento para o SQL Server 2008 Internals

Bom dia pessoal.

Na semana passada eu entreguei o treinamento "SQL Server 2008: arquitetura, estruturas de armazenamento e funcionamento interno" em São Paulo. Foi aprimeira experiência fora de Brasília e com uma turma aberta, onde o profissional têm que realmente mostrar o interesse em participar, e o resultado... foi excelente!

Conforme descrevi em meu blog quando fiz o primeiro anúncio desse curso (http://luticm.blogspot.com/2009/11/treinamento-de-sql-server-2008.html), minha expectativa estava muito alta e foi atendida. Recebi uma turma com muitos profissionais certificados, alguns se preparando para tal, com boa experiência no SQL Server e até gente que é instrutor oficial da Microsoft (MCT). Nada mal, hein? Sem contar que tinha gente de Brasília (fora eu), Salvador, São Paulo e de cidades próximas.

Tivemos discussões boas e quentes, comentários preciosos, e muitos, muitos detalhes do SQL Server 2008, sempre abordando as diferenças entre versões anteriores e melhores práticas. No fim recebi feedbacks bem positivos, como:

• "Agora eu entendo quando você disse que era importante conhecer o funcionamento do SQL Server para fazermos tunning."
• "Foi muito bom, realmente me deu uma outra visão do SQL Server que não tinha, tudo ficou mais claro, e mostrou sim que temos que sempre estudar mais e mais. " (Adorei essa! Quem disse que seria fácil :-))
• "O treinamento foi muito bom, tirou muitas dúvidas que eu tinha e é claro que eu ganhei outras, mas acredito que isso é normal, mas o objetivo foi alcançado."

Na empolgação eu alterei um pouco a ementa do curso e tirei o query optimizer do módulo 02, dedicando um módulo inteiro a ele (módulo 09), com mais informações. No fim do curso alguém me perguntou se eu conseguiria falar dos mesmos assuntos só que em 60 horas, claro que a resposta foi SIM, sempre fica coisa de fora…

No fim tive uma semana bem corrida, aprendi mais sobre o SQL Server, fiz novos amigos e acho que consegui mostrar muita coisa que as pessoas vão usar no seu dia-a-dia, se tornando melhores profissionais que trabalham com o SQL Server. Voltei para Brasília com um sorriso de satisfação estampado na cara.


Agora, o calendário

Atendendo aos pedidos que tenho recebido por e-mail e empolgado com a possibilidade de mostrar o SQL Server 2008 para outras pessoas, montei um cronograma de treinamento para Maio/Junho de 2010 com o curso SQL Server 2008 Internals (codinome).

O conteúdo programático pode ser encontrado aqui.



Algumas lições ficaram do último curso: a matéria é muito densa e exige bem do aluno/instrutor e nem sempre é simples justificar ao chefe ficar uma semana fora da empresa.

Pensando nisso resolvi tentar algo diferente e vou quebrar o treinamento em 2/3 dias, intercalando-o entre algumas cidades. Ainda não sei se dará certo, vamos é tentando que conseguimos melhorar…

A agenda proposta é:

Curitiba: 03/05/2010 a 07/05/2010 (semana inteira)
São Paulo (capital): 10 e 11/05/2010 + 19 a 21/05/2010 (semana intercalada)
Rio de Janeiro: 12 a 14/05/2010 + 17 e 18/05/2010 (fim de semana para descansar)
Recife: 31/05 e 01/06/2010 + 09 a 11/06/2010 (semana intercalada)
Fortaleza: 02 a 04/06/2010 + 07 e 08/06/2010 (fim de semana para descansar)

Entendeu? Eu demorei, então nada melhor que algumas imagens…

(Maio/2010)


(Junho/2010)


Nesse momento estamos listando os interessados e para fechar uma turma preciso de no mínimo 8 alunos. Então interessados favor enviar e-mail para luciano.moreira@srnimbus.com.br com informações de contato. Aproveitando, o valor do treinamento será o mesmo que usamos em São Paulo, R$ 1.600,00 por 40 horas. Vou fechar alguns detalhes do treinamento e em breve mando mais informações.

O nosso site está no forno, então daqui a pouco teremos um processo mais fino para publicação de calendário e registro de interessados. Aguardem!

Nada como a expectativa de um treinamento desse para empolgar um geek de SQL Server...
Abraços

[]s
Luciano Caixeta Moreira - {Luti}
Chief Innovation Officer
Sr. Nimbus Serviços em Tecnologia Ltda
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm

terça-feira, 2 de fevereiro de 2010

Reflexões para 2010

No início dos dois últimos anos eu escrevi artigos intitulados "200X… O ano para alavancar a sua carreira" (http://blogs.msdn.com/luti/archive/2009/01/15/2009-o-ano-para-alavancar-a-sua-carreira.aspx e http://blogs.msdn.com/luti/archive/2008/01/02/2008-o-ano-para-alavancar-sua-carreira.aspx). Eles ainda continuam relevantes, mas escolhi mudar o título para esse ano, então vamos de reflexões...

Primeiro aspecto a ser notado: Acredito que todo ano é ano para alavancarmos nossas carreiras! No mundo da tecnologia onde somos abordados com novidades diariamente, manter-se atualizado e na crista da onda é quase uma tarefa Herculeana. Então se você não alavanca sua carreira a todo momento, "para trás ficando está" (frase estilo yoda para descontrair).

Completei 30 anos bem no fim do ano passado e isso me remeteu ao ano 2000, quando eu ingressei no mercado de trabalho como estagiário… Uau, 10 anos nessa jornada! E o que mudou? Aprendi bastante, fiquei mais maduro, a tecnologia evoluiu como nunca e a maneira de encararmos o mundo também. Mas foi para melhor?

-- Pausa para reflexão --


R: Eu acredito que sim!

Normalmente sou muito crítico e acho que estamos fazendo muitas coisas erradas (sim, estamos), mas tenho o privilégio de constantemente trabalhar perto da comunidade técnica e vejo as pessoas tentando melhorar e serem bons profissionais. Infelizmente nem sempre é fácil (acho que nunca!) nos qualificarmos e acabamos diversas vezes consumidos por um sentimento de que não estamos fazendo o suficiente, o que pode nos levar a exaustão e estressar.

Então, apesar dos escândalos e atrocidades que vemos diariamente pelo mundo, das pessoas reclamando e prejudicando outras, somente notando o que existe de ruim, vou apostar na bondade e boa intenção que existe em cada um. Podemos errar, mas ninguém deve se sentir bem com isso.


Mudanças com a Internet

No ano passado eu li o artigo "Is Google Making Us Stupid" (http://www.theatlantic.com/doc/200807/google) do Nicholas Carr, antigo mas excelente e relevante, que caiu com uma luva na análise dos meus métodos de aprendizado e evolução profissional. A questão não é o Google per se, mas a maneira que nos aproveitamos da Internet e consolidamos o que temos em mãos, remetendo-me a um artigo do Otavio (http://blogs.msdn.com/otavio/archive/2009/03/28/a-nova-gera-o-y.aspx).

Nos últimos dois anos eu tenho notado uma mudança no meu comportamento, onde eu começo a ler três ou quatro livros ao mesmo tempo, procurando por partes que me interessam e, dificilmente, chego ao fim destes. Durante o dia vejo mais de uma centena de feeds que chegam ao Outlook, links publicados no twitter, diggests recebidos por e-mail e fóruns da comunidade, tudo isso misturado com o nosso dia de trabalho. Como digerir toda essa informação? Como manter o foco no que estamos fazendo?

Já reparou como você consegue trabalhar por 12 horas seguidas, chegar exausto ao fim do dia e ter a impressão de que fez pouca coisa? Não foi pouco, mas talvez muitas coisas pequenas que ficaram diluídas e não saltam aos olhos, deixando essa sensação ruim de falta de capacidade ou de improdutividade.


Encontrando o seu caminho

Diversas vezes sou questionado sobre como eu estudo, trabalho e me mantenho atualizado. A resposta que sempre dou é "Você têm que encontrar o seu ritmo". Não existe fórmula mágica, o jeito é suar a camisa e trabalhar arduamente, que com um pouco de inspiração vai te trazer benefícios.

No meu caso, estou trabalhando em um mix do que está ao meu redor. Ando focando na leitura de alguns livros (até o fim!), complemento meus estudos com artigos para me manter atualizado, procuro leituras mais exigentes (como artigos acadêmicos) e faço um MBA que me permite extrapolar o mundo técnico e pensar em outros aspectos dos negócios de hoje.

Certa vez eu li a frase "Um livro vale mais do que mil posts" (não me lembro quem escreveu). Bom, eu não largaria meus blogs preferidos por nada, mas hoje para mim o melhor caminho seria ganhar um embasamento forte na tecnologia lendo um livro e depois partir para os blogs com conteúdo profundo e detalhado.

Encontre seu caminho! Descubra os momentos em que é mais produtivo, o que te faz sentir bem no trabalho e em casa, enfim, se você não estiver confortável com o ambiente ao seu redor e o que está fazendo, não existe livro ou horas de estudo que irá alavancar sua carreira.


Redes sociais e comunidades técnicas

Sou blogueiro, uso o twitter, estou inscrito em muitas redes sociais/comunidades técnicas e depois de experimentar um pouco de tudo, terei que ser sincero com vocês, o que estou vendo está me cansando. Deixe-me explicar melhor...

Adoro trabalhar com a comunidade, vou continuar blogando e twiitando, o SQLServerDF vai continuar firme e forte, e eu estarei empenhado em gerar novos conteúdos focados em uma excelente qualidade. Mas acho que estamos sendo diariamente assediados por uma avalanche de novas comunidades e autores que andam trazendo pouca relevância e diferenciação.
Se compararmos duas ou três comunidades do mesmo tema, vamos perceber artigos e discussões semelhantes, normalmente com um nível mais introdutório. Tudo isso nos faz perder um pouco de tempo e acho que nos impele a sermos mais superficiais, perdendo o entendimento profundo (e necessário) do que estamos discutindo e trabalhando.

Então para 2010 eu tenho o firme propósito de diminuir o ruído dessas redes que surgem diariamente, escolhendo aquelas que sejam relevantes, deixando de ser na maioria do tempo um consumidor para produzir conteúdo, espero eu, diferenciado. É claro que vocês verão artigos introdutórios nesse blog, processo natural do aprendizado, mas se eu parar por aí fugirei ao meu objetivo.

O planejamento do Luti em 2010

Nada mais natural do que meus planos estarem alinhados com a da Sr. Nimbus, empresa que sou sócio. Então o que esperar do Luti em 2010?

Maior foco no SQL Server! Sim, em 2010 diferente dos últimos anos, o SQL Server vai receber uma maior atenção minha. Vou ir ainda mais a fundo no produto e continuar explorando o mundo de BI, coisa que já venho fazendo através de consultorias que tenho prestado. Estamos chegando com novas ofertas de treinamentos e serviços, que (espero eu) vocês vão gostar.

Somente vamos trabalhar com o SQL Server? Nada disso, também estamos de olho em cloud computing (Azure e outros) e prontos para ajudar os outros a entenderem como podem tirar o máximo dessa (r)evolução que já chegou.


Tudo isso sem esquecer do lado pessoal, da família, futebol, dos momentos de descontração e dos amigos, onde muitos aparecem pelo mundo virtual e não saem mais. Sempre com a humildade de que temos muito para aprender...


[]s
Luciano Caixeta Moreira - {Luti}
Chief Innovation Officer
Sr. Nimbus Serviços em Tecnologia Ltda
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm