Treinamento Indexação I - FREE

Olá visitante!
Publiquei o treinamento on-demand Indexação I, disponível gratuitamente no meu canal no YouTube.

A playlist você acessa aqui:
https://www.youtube.com/playlist?list=PLGaWZx_3bztdIJscZJjkS39KW0TbaNpLF

Bom estudo!
Abraços

Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br

Transaction Log Internals - FREE

Olá leitor.
Publiquei o treinamento on-demand Transaction Log Internals, disponível gratuitamente no meu canal no YouTube.

A playlist você acessa aqui:
https://www.youtube.com/playlist?list=PLGaWZx_3bztdZNnrFSluDpaPjaB6IAx6-

Não deixe também de aproveitar os treinamentos que o Fabiano publicou.
https://blogfabiano.com/2017/01/31/on-demand-virou-dominio-publico/

Bom estudo!Abraços

Luciano Caixeta Moreira - {Luti}
luticm79@hotmail.com
www.twitter.com/luticm

SEGUNDO PRIMEIRO dia na Microsoft

Sim, isso mesmo que você leu, dia 01 de agosto é o meu SEGUNDO PRIMEIRO dia na Microsoft. :-)

Em 2006 eu ingressei na Microsoft como Premier Field Engineer de SQL Server e fiquei por lá até Março/2009. Agora volto a trabalhar na MS com o cargo de Support Engineer, suportando a plataforma de dados da Microsoft.

**************** ATUALIZAÇÃO *****************

Gostaria de agradecer todos os comentários neste post e no LinkedIn.
Infelizmente não conseguirei responder individualmente, então registro agui meu agradecimento.

A todos, meu muito obrigado!

************************************************

Nesse post vou relatar um pouco de como tudo aconteceu e falar um pouco de futuro do Luti e da Nimbus.

Versão (muito) resumida

    - Após contato da Microsoft, participei do processo de seleção e aceitei meu retorno à MS;
    - É uma nova aposta de carreira que espero seguir por muitos anos;
    - Por configurar um conflito de interesse, a Nimbus não irá mais executar nenhuma atividade de treinamento e consultoria;
    - Eu não vou deixar de participar da comunidade técnica, escrevendo artigos em seu blog, gravando vídeos e/ou participando de eventos técnicos;

Versão longa

A oportunidade

Em abril eu recebo uma mensagem no LinkedIn… “Oi Luciano, estamos com uma vaga na Microsoft e acho que você tem o perfil para ela, estaria interessado?”

A minha resposta para essas perguntas é sempre SIM. No fim tudo depende da oportunidade e do que cada empresa tem para oferecer, então eu ouço o que cada uma tem a dizer, pois quem sabe em um desses contatos não está uma grande oportunidade para sua carreira…

Reunião agendada, fui apresentado para a vaga de Support Engineer. Depois de entender mais sobre a vaga, e claro, fazer minhas pesquisas sobre a posição, resolvi continuar no processo de seleção.

O próximo passo foi passar por entrevistas, que são sempre interessantes e instrutivas, pois fazem você lembrar que não sabe de nada e, mesmo se tratando de assuntos que tem um bom conhecimento, um pouco de pressão sempre atrapalha. Muitos dias depois é marcada mais uma reunião, quando acerto meu retorno à empresa.

A decisão

Obviamente não foi uma decisão fácil aceitar a nova proposta e saber que vou deixar de lado a Sr. Nimbus, afinal já são sete longos anos com a empresa que ajudei a fundar e esteve ao meu lado por todo esse tempo. E sabendo que essa movimentação será uma surpresa para muitos, escrevo um pouco sobre a decisão.

Durante meus anos com a Nimbus eu tive a oportunidade de ministrar muitos treinamentos, atuar como consultor para diversas empresas e, mais recentemente, apoiar remotamente na administração do ambiente SQL Server de alguns clientes. Aliado com a flexibilidade de administrar meu tempo, me deu oportunidade de viajar bastante, curtir muito a família e escolher quais trabalhos eu gostaria de executar. Nada mal.

Porém cheguei a um ponto crítico, onde eu NÃO queria fazer a empresa crescer, pois me forçaria a paulatinamente abandonar o lado técnico da minha carreira para negociar/gerenciar clientes, contratar/treinar outros consultores, etc. Só me restando dizer NÃO para oportunidades que batiam à porta da Nimbus, para garantir a qualidade da entrega, e manter o ritmo de trabalho. Mesmo estando feliz com minha situação, não existia um próximo passo, o que me incomodava um pouco.

Eis que aparece essa nova oportunidade na Microsoft, uma posição onde poderei trabalhar com diversos chamados de suporte por dia, atuando com um extenso leque de produtos da plataforma de dados da Microsoft (SQL Server, SQL Azure, Power BI, etc.), explorando ainda mais o lado técnico que eu tanto gosto. E tudo isto dentro da MS, que sempre me tratou muito bem, é uma excelente empresa para se trabalhar, e recentemente sob a direção do Satya Nadella tem se mostrado ainda mais interessante.

Felizmente fui escolhido para a vaga, dentro os candidatos entrevistados, e espero desempenhar um excelente trabalho, ficando muito tempo na empresa, aprendendo, ensinando, e quem sabe, trilhando novos caminhos dentro da Microsoft.

A Nimbus

O lado negativo da novidade… A minha querida Nimbus fica órfã e impedida de continuar suas atividades. Sendo uma empresa focada em consultoria e treinamento SQL Server, e seu sócio/fundador passando a ser funcionário da Microsoft, é inviável que a empresa continue com seu funcionamento, por caracterizar um claro conflito de interesse.

Então espero que aqueles que tiveram treinamento com a Nimbus possam ter aproveitado o que considero ser os melhores e mais avançados treinamentos de SQL Server do país. Nunca se sabe o que futuro nos reserva, porém agora meu foco e dedicação estão 100% voltados para Microsoft…

Aproveitando que mencionei os treinamentos da Nimbus, gosto de acreditar que ajudamos a mudar o cenário de treinamento SQL Server no país, com o papel muito importante de difundir a importância dos profissionais conhecerem à fundo o produto com que trabalham, o famoso "internals".

Hoje na comunidade técnica já vemos muitas palestras que tentam difundir o funcionamento interno do SQL Server e espero que novas empresas/treinamentos possam suprir um pouco desse espaço que a Nimbus vai deixar, já sabendo da existência de um público avançado, que se interessa em esmiuçar cada detalhe do SQL Server e quer ir mais longe com o produto, resolvendo problemas complexos que o envolvem.

O futuro do Luti

Eu continuarei como eu sou, cada vez mais geek, apaixonado por banco de dados, estudando diariamente, e tentando arranjar um tempo para escrever sobre minhas aventuras técnicas. Então o conteúdo técnico vai continuar firme e forte, afinal de contas tenho certeza que vou aprender muito com meus novos companheiros de equipe e espero ter muitos “causos” para contar, seja aqui ou em outro espaço…

Como não poderei mais ministrar os treinamentos que tanto gosto, principalmente o Mastering, espero poder matar a saudade da sala de aula com palestras em eventos técnicos.

É isso que queria dizer, agora vou trabalhar! #sqlgeek


OBS.1:
Para quem quiser mais informações sobre o cargo, depois pesquise por "a week in the life of a support engineer Microsoft", que vai encontrar alguns PDFs antigos, mas bem ilustrativos, do que seria o dia a dia da posição. Outra opção é ir em https://careers.microsoft.com e pesquisar por Support Engineer, onde vai poder ver o job description, caso exista alguma vaga em aberto.

OBS.2:
Também estão suspensas as vendas dos treinamentos on-demand da Nimbus, mas não se preocupe, tenho planos interessantes para os módulos que eu gravei…

OBS.3:
O Fabiano Amorim provavelmente vai continuar ministrando os treinamentos que ele construiu, como o T-SQL Expert e o SQL Server Performance with no wait, e pode até continuar comercializando os treinamentos on-demand de planos de execução. Interessado? Corra atrás dele: http://blogfabiano.com/.

OBS.4:
O Edvaldo Castro também está com alguns treinamentos de SQL Server, voltados para administração e alta disponibilidade, recomendo! (http://edvaldocastro.com/)

Abraços

Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br

SQL Saturday #573 - Brasília

Esse é um anúncio muito importante!
Brasília vai receber mais um SQL Saturday (o terceiro por aqui), novamente com o apoio da faculdade Projeção.

Porém dessa vez não sou eu quem está puxando a organização do evento, como foi anteriormente, quem está responsável por fazer o evento acontecer é o Edvaldo Castro (http://edvaldocastro.com/). Junto com ele estão outros nomes conhecidos do SQLServerDF, como Gustavo e Rodrigo, e claro, contando também com meu apoio, colaborando com um pouco de experiência na organização de eventos.

Os links mais importantes são:

Site para registro: http://www.sqlsaturday.com/573/eventhome.aspx
Submissão de palestras: http://www.sqlsaturday.com/573/Speakers/Submission.aspx
Seja um patrocinador: http://www.sqlsaturday.com/573/Sponsors/SponsorPlan.aspx

O EVENTO É GRATÚITO, ENTÃO PARTICIPE E CHAME OS AMIGOS!

Uma oportunidade única para aprender mais sobre o SQL Server e fazer networking.  Seu currículo e futuro profissional irão agradecer…

Abraços

Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br

Entity Framework e lazy loading

A cada dia que passa fica mais comum encontramos soluções com camadas de mapeamento objeto-relacional (ORM), simplificando o acesso a dados para os desenvolvedores.
Ressalto que não sou contra o Entity Framework, hibernate ou outros frameworks de mapeamento objeto relacional, só quero que as pessoas que o utilizam tomem cuidados básicos no acesso a dados, pois não existe mágica…

Banco de dados

Utilize o script abaixo para criar um banco de dados de exemplo com três tabelas, Pessoa, Endereço e Telefone, inserindo também alguns registros.
Ok, eu sei que você modelaria diferente, pois uma pessoa pode ter mais de um endereço ou telefone, mas para este exemplo a regra de negócio da Lutilândia não permite.

CREATE DATABASE EF
GO
USE EF
GO
IF (OBJECT_ID('dbo.Pessoa') IS NOT NULL)
DROP TABLE dbo.Pessoa
go
IF (OBJECT_ID('dbo.Endereco') IS NOT NULL)
DROP TABLE dbo.Endereco
GO
IF (OBJECT_ID('dbo.Telefone') IS NOT NULL)
DROP TABLE dbo.Telefone
go

CREATE TABLE dbo.Endereco
(ID INT IDENTITY NOT NULL PRIMARY KEY,
 Descricao VARCHAR(500) NOT NULL)
GO

CREATE TABLE dbo.Telefone
(ID INT IDENTITY NOT NULL PRIMARY KEY,
 Descricao VARCHAR(500) NOT NULL)
GO

CREATE TABLE dbo.Pessoa
(Codigo INT IDENTITY NOT NULL PRIMARY KEY,
 Nome VARCHAR(100) NOT NULL,
 IdEndereco INT NULL,
 IdTelefone INT NULL
 )
GO

ALTER TABLE dbo.Pessoa
ADD CONSTRAINT fk_Pessoa_Endereco_ID 
FOREIGN KEY (IdEndereco)
REFERENCES dbo.Endereco (ID)
GO

ALTER TABLE dbo.Pessoa
ADD CONSTRAINT fk_Pessoa_Telefone_ID 
FOREIGN KEY (IdTelefone)
REFERENCES dbo.Telefone (ID)
GO

INSERT INTO dbo.Endereco (Descricao)
SELECT TOP 100000 O.description
FROM sys.dm_xe_map_values AS M
CROSS JOIN sys.dm_xe_objects AS O
GO

INSERT INTO dbo.Telefone (Descricao)
SELECT TOP 100000 O.description
FROM sys.dm_xe_map_values AS M
CROSS JOIN sys.dm_xe_objects AS O
GO

INSERT INTO dbo.Pessoa (Nome)
SELECT TOP 1000000 M.name
FROM sys.dm_xe_map_values AS M
CROSS JOIN sys.dm_xe_objects AS O
GO

UPDATE dbo.Pessoa
SET IdEndereco = (Codigo % 100000) + 1
, IdTelefone = (Codigo % 100000) + 1
GO

Lazy loading

Utilizando o Entity Framework 6.0, o comportamento padrão do EF é que o contexto trabalhe com lazy loading. O que isso significa?

Para quem está seguindo o script, crie um projeto C# Console no Visual Studio e…

    1. Adicione um ADO.NET Entity Data Model (chame do que quiser)
    2. Escolha EF Designer from database
    3. Aponte para seu banco de dados EF (pode manter o nome EFEntities)
    4. Selecione as tabelas Pessoa, Endereco e Telefone
    5. Clique em Finish

Depois da geração do modelo você vai ver algo similar a imagem abaixo:

Edite seu método Main e coloque o código abaixo. O objetivo do código é buscar quase 10000 pessoas e depois fazer algo simples, acessando o endereço e telefone do indivíduo (note que não me interessa gerar saída alguma, só o acesso ao banco de dados).

String s = "";
DateTime dt = DateTime.Now;

EFEntities contexto = new EFEntities();
var r = contexto.Pessoas.Where(x => x.Codigo < 10000);

foreach (var p in r.ToList())
{
    s = "Nome: " + p.Nome + " - Endereço: " + p.Endereco.Descricao + " - Telefone: " + p.Telefone.Descricao;
}
Console.WriteLine(DateTime.Now.Subtract(dt).Seconds.ToString());

A execução dessa aplicação na minha máquina levou algo em torno de 12 segundos, nada demais para o desenvolvedor que está executando este código, então poucos fazem uma análise mais detalhada, como faremos a seguir.

Utilizando o profiler para monitorar os eventos SQL:BatchCompleted e RPC:Completed, toda vez que o Entity Framework acessa a coluna Descrição da entidade Endereco ou Telefone, uma chamada é feita para o SQL Server (note o @EntityKeyValue1 variando), o que neste exemplo gerou 39998 entradas no profiler.

Essas chamadas são feitas porque o EF vai "preguiçosamente" (lazy) pedindo para o SQL Server os elementos de outras entidades, varrendo o resultado retornado após o acesso ao elemento Pessoa (primeira consulta exibida na imagem abaixo).

Eager loading

Caso você queira que o Entity Framework não trabalhe com esse comportamento de lazy loading, você pode alterar no seu código a utilização do contexto, adicionando o método "Include", que por debaixo dos planos já busca todos os elementos.

var r = contexto.Pessoas.Include("Endereco").Include("Telefone").Where(x => x.Codigo < 10000);

Analisando a execução deste novo código, temos APENAS DUAS linhas na saída do profiler, onde notamos que o EF enviou para o SQL Server uma única consulta fazendo o join entre as três tabelas, já retornando o endereço e telefone. Dessa forma evitamos N round-trips entre o cliente e o servidor, fazendo com que em minha máquina o tempo total de execução ficasse em torno de 3 segundos.

Desempenho da aplicação

A diferença entre 3 e 12 segundos é onde mora o perigo... Talvez testando a solução em sua máquina, os 9 segundos não sejam significativos para os desenvolvedores, e um build sem a análise de desempenho ou do número de chamadas acabe chegando em produção.

Se a solução é para controlar o nome dos envolvidos no próximo bolão do campeonato lá na sua empresa, tudo tranquilo, porém caso a solução tenha milhares de requisições pesquisando por pessoas específicas, o número de chamadas ao banco de dados será muito grande. E dependendo da forma como a aplicação está gerenciando e utilizando os seus recursos (ou consumindo os registros), ela mesmo pode ser tornar o gargalo, que não respondendo adequadamente vai deixar o SQL Server cheio de requisições com espera do tipo ASYNC_NETWORK_IO (e NÃO É PROBLEMA DE REDE, ok?!!).

É meio óbvio que para escrever este artigo eu já encontrei diversos problemas de desempenho em aplicações por conta do Lazy Loading. O que em um primeiro momento sempre foi apontado como problema no banco de dados, conseguimos rastrear até apontar o comportamento indevido da aplicação. Então peço para que façam uma análise mais criteriosa de como o seu framework de mapeamento OR acessa o banco de dados, sempre entendendo o perfil das requisições e como pode utilizar da melhor forma o framework adotado.

Então estou falando para nunca usar lazy loading ou até configurar o contexto (this.Configuration.LazyLoadingEnabled = false) para impedir que um desenvolvedor desavisado faça uso do lazy load?
Claro que não, quero que você entenda que o maior custo de IO e CPU visto em uma única consulta com eager loading pode ser muito inferior quando comparado ao tempo total de execução do round-trip de milhares de chamadas para o SQL Server.

No fim tudo depende, só precisamos fazer as perguntas certas e achar as respostas adequadas, então espero que você guarde mais essa informação no seu repertório de soluções.

Abraços

Luciano Caixeta Moreira - {Luti}
luciano.moreira@srnimbus.com.br
www.twitter.com/luticm
www.srnimbus.com.br