Fala galera, estou compartilhando com vocês uma conquista pessoal. Depois de praticamente 2 anos e meio sem fazer nenhuma prova de certificação Microsoft, resolvi que era hora de voltar à ativa. Isso já estava no meu planejamento 2010, mas finalmente eu tomei coragem para enfrentar essa prova.

A prova 70-442 – PRO: Design & Optimize Data Access by using MS SQL Server 2005 é uma prova tensa, criada para te forçar a utilizar a melhor prática para chegar ao resultado esperado. A maioria das questões são baseadas em estudos de casos, e isso complica pra quem não consegue fazer uma boa interpretação de texto. As perguntas são do tipo: “A query não está no padrão proposto, qual opção é a correta?” Só que das opções apresentadas, geralmente tem mais de uma que poderia ser correta. Porém, a resposta que eles esperam é a que se aplica melhor ao cenário que foi passado… Isso mata, deixa a prova cansativa e tensa! (de verdade). Não é uma prova que exige níveis jedis de conhecimento em SQL Server 2005, mas é bem importante conhecer muito bem os assuntos que são cobrados na prova. Com a experiência do dia-a-dia e algumas horas de dedicação focada nos assuntos que você não tem tanto contato, é o suficiente para conseguir ser aprovado neste exame.

A prova foi feita baseada em 7 casos de usos, com um total de 55 questões. Alguns assuntos que me lembro de terem caído na minha prova foram:

• Gerenciamento de transações e locks;
• Cursores
• Códigos T-SQL no padrão ANSI
• Tuning e performance

Bom, mas deu tudo certo e consegui a aprovação na prova, fiz um score de 900 pontos de 1000 possíveis. Agora juntando às outras duas (70-431 e 70-441) que eu já havia sido aprovado a alguns anos atrás,  possuo a titulação de MCITP Database Developer – SQL Server 2005.

Muito obrigado à todos que deixaram seus votos de “boa sorte” pra mim, e os que me apoiaram dando dicas da prova. Vocês me ajudaram muito! :)

Seguindo meu planejamento 2010, agora vou correr atrás do titulo de MCT (Microsoft Certified Trainner) e em seguida atualizar meu MCITP de SQL Server 2005 para SQL Server 2008. Ainda estou amadurecendo as possibilidades de fazer a prova de upgrade ou de fazer todas as provas pro 2008, ainda não sei!

Fala galera, é sexta-feira de madrugada minha esposa está tomando banho e eu estou escrevendo este post. É o sexto da série e provavelmente o útimo que escreverei com minhas idéias, a partir de agora vou esperar as duvidas de vocês para escrever mais posts sobre esses comparativos.

Neste post, vou falar sobre Alta Disponibilidade e Escalabilidade.

Quando se pensa em Alta Disponibilidade, estamos pensando em 24X7 (24horas 7 dias por semana). A Plataforma Azure é baseada em SQL e Windows Server, e é flexivel o bastante para para variar com relação à carga ou uso. O serviço replica os dados em diversos servidores diferentes para manter os dados redundantes e disponíveis para seu negócio, haja o que houver. No caso de um dos servidores cair, o Azure automaticamente faz o loadbalance e aponta para outro server.

Já com relação à escalabilidade, esse é um ponto bem positivo pra Plataforma Azure no ponto de vista da facilidade de se escalar (aumentar o desempenho) sua própria solução. No SQL Server, depois de particionar seus dados, a escalabilidade é automática e o banco vai crescendo de acordo com sua necessidade. Pela forma de licenciamento, você só pagará pelo que armazenar “economizando dinheiro”, e caso precise fazer um downgrade (diminuir o desempenho) de seu ambiente, é possivel fazer quando achar necessário.

Bom, foram 6 posts sobre diversas informações relacionadas à SQL Server e SQL Azure Database. Com certeza terão assuntos que vocês gostariam que fossem discutidos e não foram. Deixo o espaço dos comentários ou o meu twitter @DiegoNogare aberto para que possam enviar suas dúvidas e terei o maior prazer em responder.

Fala galera, estou voltando a postar depois do MVP Summit 2010…

Na comparação de hoje falarei sobre o modelo de dados relacional.

O SQL Azure será bem familiar à todos os DBAs e DEVs (de banco) no quesito de armazenamento, porque é bem parecido com o SQL Server on-premise, usando T-SQL. Por conceito, o SQL Azure é como uma instância do SQL Server, só que com algumas restrições (vocês se lembram, né?!).

Em cada servidor de SQL Azure, você pode criar diversos bancos de dados, e em cada banco pode criar várias tabelas, views, stored procedures, índices, e vários outros objetos. Este modelo de dados faz um bom uso do design e codificação dos bancos que já temos on-premises e simplifica o processo de migração para a nuvem por serem bem similares e suportarem quase tudo um do outro.

Só lembrando que o SQL Azure Database são servidores virtuais e não correspondem exatamente como um SQL Server local (que é físico)! Então não tentem ter o mesmo desempenho, é muito pouco provável que consiga chegar próximo!

Se alguém tiver duvida sobre alguma coisa entre o SQL Azure e o SQL Server, me mande que eu terei um prazer enorme em responder.

Fala galera, diretamente do MVP Summit 2010, vou postar mais algumas coisinhas sobre a comparação entre SQL Server e SQL Azure Database.

No post de hoje, vou falar sobre as Features permitidas e mais um pouquinho do código T-SQL não suportado.

Falando das Features, vale lembrar que a plataforma Azure é gerenciada através de serviços, logo não temos acesso direto “ao servidor”, somente ao que é liberado através dos serviços. Ótimo, todo mundo lembrou disso. Então já que lembramos desse detalhe, agora vamos lembrar de outro, o SQL Azure Database não suporta todas as Features e Datatypes que o SQL Server local suporta, por exemplo o Analysis Services, Replication, Reporting Services e Service Broker não são suportados pelo SAD ainda, mas pode ser que estas Features sejam implantadas. Como a própria plataforma Azure cuida da parte física (hardware), algumas configurações que manipulam diretamente a questão de hardware do servidor estão bloqueadas, por exemplo o Resource Governor ou algumas configurações de DDL (Data Definition Language). Hah, também não é permitido utilizar o SQL Profiler ou o DB Tuning Advisor.

Outros códigos T-SQL não suportados são aqueles que fazem referência à algum filegroup ou caminho físico. Dependendo do código, ele pode até ser considerado “parcialmente” suportado. Bizzaro! rss

Fala galera, estou escrevendo este post de dentro do avião, indo pro MVP Summit, quando chegar eu conecto em algum WiFi e publico (só pra constar! rss).

Bom, continuando com essa série de comparações entre SQL Server e SQL Azure Database, vou falar sobre o código T-SQL suportado na plataforma Azure. É claro, algumas coisas podem mudar, mas estes códigos eu já testei.

T-SQL suportados:

Constantes / Constraints / Cursores / Índices (gerenciamento e rebuild) / Tabelas temporárias locais (com 1 #) / Stored Procedures / Gerenciamento de Estatísticas / Transações (Begin e End) / Triggers / joins de tabelas e de variáveis do tipo table / Create ou Drop Database / Create, Alter ou Drop Table / Create, Alter ou Drop usuários e logins / Views.

Algumas coisas que testei, mas não tive sucesso, logo entendo como não suportado:

CLR / Database Mirroring / Gerenciamento de Filegroup / Tabela temporária global (com 2 ##) / Service Broker

Bom, esta é a terceira parte da série, vamos ver se posto mais alguma coisa diretamente do MVP Summit 2010!