Diário de um DBA

A cada nova versão do SQL Server a Microsoft vem tornando suas edições gratuitas ainda mais atrativas. Já abordei anteriormente por aqui sobre a instalação do SQL Server 2008 Express; então se você está procurando informações sobre SQL Server 2008 Express, aproveite esse texto para se atualizar sobre o segundo release (R2) do SQL Server 2008 Express Edition.

De cara, a principal novidade é que SQL 2008 R2 Express permite gerenciar bases de dados com até 10 GB. Na última versão o limite eram 4 GB por base de dados. Uma melhoria interessante não é?

As limitações de CPU e memória continuam as mesmas, sendo 1 CPU e 1GB RAM. No caso da CPU lembre-se que a limitação é por chip; logo, se você tiver um chip Six-Core seu SQL irá utilizar os 6 núcleos deste chip.

Para este release são ofertados três opções de instalação: a instalação SQL Server 2008 R2 Express instala somente a engine do SQL, ou seja, o serviço principal do SQL Server onde é possível rodar bancos de dados, criar ou alterar objetos e etc, porém sem nenhuma ferramenta gráfica. A instalação SQL Server 2008 R2 Express with Tools Edition oferece a engine e adiciona também o Management Studio que é uma ferramenta gráfica para gerenciamento das instâncias; na SQL Server 2008 R2 Express with Advanced Services além da engine e do Management Studio é oferecido também o Reporting Services para o desenvolvimento de relatórios no SQL Server. Ambas instalações estão disponíveis para as plataformas de 32 e 64 bits.

Os pré-requisitos continuam os mesmos: se você for instalar somente a Engine desta versão (sem nenhuma ferramenta gráfica), será necessário somente o Framework 2.0; se for utilizar as ferramentas gráficas o Framework 3.5 SP1 é um pré-requisito. Assim como na última versão o Windows Installer 4.5 e Windows Power Shell 1.0 são necessários para a instalação.

O processo de instalação continua bem similiar ao que publiquei aqui no ano passado, portanto se desejar um passo-a-passo da instalação básica acesse este link.

E pra finalizar segue o link de download do R2 Express: http://www.microsoft.com/express/Database/InstallOptions.aspx

Até +

Já está rolando a Copa Microsoft, uma ótima oportunidade para atualizar seu conhecimento nas novas ferramentas da Microsoft. Além da atualização o participante concorre a prêmios bem interessantes como uma LED 42’’, XBOXs, BluRay, Technet Plus e etc.

Inicialmente é possível ganhar pontos indicando amigos e baixando os softwares; depois vem as provas online para as quais você poderá se preparar assistindo aos webcasts… isso é só o começo, depois vem treinamentos e provas na Microsoft e a preparação de um vídeo onde o participante deverá demonstrar em 3 minutos a utilização de uma das novas tecnologias. A final é uma prova surpresa :D

Já rolaram duas provas online: Windows Server 2008 R2 e Exchange 2010; mas pra quem tá interessado, ainda dá tempo de se inscrever e correr atrás!

http://www.talentosmicrosoft.com.br/

To lutando pra garantir meu 12º lugar… mas tá difícil, risos, a concorrência é pesada :)

Bom jogo!

UPDATE em 22/07/2010:

Infelizmente não consegui ir muito longe no jogo, justamente durante a última prova (que por sinal era a de SQL Server) meu Internet Explorer travou… a decepção foi grande, mas tudo bem.  Parabéns aos ganhadores! No ano que vem tem mais :)

Primeiro tenho que registrar que boa parte das pessoas pra quem enviei o desafio responderam corretamente. Achei interessante a interação e o clima da brincadeira; agora tá na hora de oficializar a resposta. Vamos lá:

Normalmente, quando questionam a diferença entre CHAR e VARCHAR a primeira resposta é: um tem tamanho fixo, o outro tem tamanho variável. Mas já que o CHAR tem tamanho fixo, o que acontece quando inserimos um dado que não ocupa todo o espaço reservado? E além disso, quando inserimos um dado num campo CHAR em qual direção o dado é inserido?

Então, ninguém melhor que o Books Online para responder:

Se um valor mais curto que o comprimento da coluna for inserido em uma coluna char NOT NULL, o valor será preenchido à direita, com espaços em branco, até atingir o tamanho da coluna. Por exemplo, se uma coluna estiver definida como char(10) e os dados a serem armazenados forem “music”, o SQL Server armazenará os dados como “music_____”, onde “_” indica um espaço em branco.

Fonte: http://msdn.microsoft.com/pt-br/library/ms175055.aspx

Com as considerações acima, podemos resumir a consulta do desafio a isto:

SELECT

RIGHT(’05 ‘,2) as ‘CHAR’,

RIGHT(’05′ ,2) as ‘VARCHAR’

Como a função RIGHT está extraindo duas posições à direita (contando com o espaço em branco), o Zero (0) do CHAR é ignorado no resultado.

Valeu pela participação dos amigos, em especial a do amigo Léo Lopes que contribuiu na elaboração da resposta utilizando referências do BOL :)

Hoje a tarde meu amigo Adilson Pereira me mandou um desafio bem interessante, vou postar aqui exatamente do modo como ele propôs:

Observem a diferença que dá no resultado de um comando usando o CHAR e o VARCHAR:

 

declare @data datetime

set @data = ’20100310 05:05:05′

SELECT

RIGHT(’0′ + CONVERT(   CHAR(2), DATEPART(mi, @data)), 2) as ‘CHAR’,

RIGHT(’0′ + CONVERT(VARCHAR(2), DATEPART(mi, @data)), 2) as ‘VARCHAR’

 

A solução é interessante :)

E você? Tem um palpite do porque?

Na época em que o MSDE estava em alta, muitos amigos vinham pedir dicas de como criar uma rotina automática de backups e etc, o maior impasse era sempre a falta de uma interface gráfica.

Ao contrário das novas versões do SQL Server Express, o MSDE possuía o serviço SQL Agent que permite agendar rotinas, backups, etc, e isso era ótimo, mas a barreira era saber como utilizar essa funcionalidade sem uma ferramenta.

Mas enfim, o foco desse texto não é o MSDE, até porque, com o tempo foram disponibilizadas algumas ferramentas para suprir algumas necessidades. A idéia principal é verificarmos como criar uma nova tarefa (job) e automatiza-la utilizando scripts no SQL Server.

Analisando um pouco veremos que precisamos apenas de 4 procedures para criação de um job: sp_add_job, sp_add_jobstep, sp_add_jobserver e sp_add_jobschedule. No nosso texto vamos utilizar como exemplo um cenário onde precisamos automatizar o backup da base de dados Master. Vamos analisar agora cada uma das procedures:

sp_add_job

Esta procedure adiciona um novo registro à tabela sysjobs, em linhas gerais, este registro é o nosso job, porém um job sem qualquer funcionalidade e sem agendamento. Inicialmente um job nessas condições não tem qualquer utilidade. Abaixo podemos verificar a criação de um job vazio com o título Backup MASTER:

execute sp_add_job @job_name = ‘Backup MASTER’

sp_add_jobstep

Para darmos “vida” ao job criado anteriormente, precisamos adicionar funcionalidades a ele, por exemplo: um passo onde será executado o script de backup.  Para adicionar funcionalidades ao job Backup MASTER precisamos conhecer seu código gravado na sysjobs, para isso podemos executar o seguinte comando:

select  job_id

from  sysjobs

where name = ‘Backup MASTER’

O resultado será um big código! Isso porque o código gerado é do tipo UNIQUEIDENTIFIER, popularmente conhecido como Identificador Universal.  O resultado da minha consulta é: 7EC785F2-36D7-4BEB-B2E4-BFC38E7F4D31 (é mais prático trabalhar com conteúdos deste tipo armazenando-o numa variável, porém, neste texto iremos aborda-lo explicitamente em cada passo dos exemplos).

Ok. Agora vamos utilizar este big-código junto com a sp_add_jobstep para adicionarmos funcionalidade ao nosso JOB:

– Adiciona função ao Job

execute sp_add_jobstep

@job_id = ’7EC785F2-36D7-4BEB-B2E4-BFC38E7F4D31′,

@step_name = ‘Script Backup Master’,

@command = ‘backup master to disk = ”c:\master.bak”’

Observe que utilizamos três parâmetros junto à sp_add_jobstep: o código do job (@job_id), o nome da funcionalidade (@step_name) e finalmente o script de backup no parâmetro @command.

É interessante esclarecer que um job pode ter inúmeros passos/tarefas, logo você poderá utilizar esta procedure quantas vezes forem necessárias para adicionar novos passos a um mesmo job.

sp_add_jobserver

Agora vem o passo mais “abstrato” desse processo. Após criarmos o job e definir suas funções precisamos definir em qual servidor ele irá operar. Pressupõe-se que se o job foi criado no servidor X que ele deverá ser executado no contexto deste servidor, porém, aqui nós temos que explicitar isto, logo, precisaremos executar a procedure sp_add_jobserver e configurar o job para rodar no contexto do servidor local:

execute sp_add_jobserver

@job_id = ’7EC785F2-36D7-4BEB-B2E4-BFC38E7F4D31′,

@server_name = N’(local)’

Pronto!

Neste momento nosso job já tem uma forma e já pode ser executado.

Se quisermos testar a execução manualmente, podemos executar o seguinte comando:

sp_start_job ‘Backup MASTER’

Resultado:

Job ‘Backup MASTER’ started successfully.

Vejam que nosso job foi executado com sucesso e que o arquivo foi criado:

sp_add_jobschedule

Considerando que a principal funcionalidade do SQL Server Agent e seus jobs é automatizar tarefas, não há muito sentindo em executar jobs manualmente, logo, precisamos criar um agendamento para nosso job e assim partimos para a última etapa deste processo onde recorremos à procedure sp_add_jobschedule:

execute sp_add_jobschedule

@job_id = ’7EC785F2-36D7-4BEB-B2E4-BFC38E7F4D31′,

@name = N’Agenda Backup’,

@freq_type = 4,

@active_start_time = 120000,

@freq_interval = 1

O comando pode parecer complexo, mas analisando com calma veremos que é bem tranquilo. Vamos analisar cada um dos parâmetros separadamente:

No @job_id definimos para qual job estamos criando o agendamento utilizando o “big-código”.

Em @name atribuímos um nome para o nosso agendamento.

Em @freq_type temos as seguintes possibilidades:

No nosso script @freq_type = 4, logo, o comando indica que o job será executado diariamente.

Em @active_start_time definimos o horário da execução, no nosso exemplo 12:00:00, sem os sinais de separação entre horas, minutos e segundos. Se o conteúdo desse parâmetro fosse 215600, o job seria executado às 09:56 da noite.

Por fim temos o parâmetro @freq_interval que está diretamente atrelado ao parâmetro @freq_type e foi definido como 1 porque nosso backup será executado todos os dias.

(Pode ser complexo definir valor para o parâmetro @freq_interval, mas não iremos nos aprofundar nele neste momento. Para entender sua composição consulte: http://msdn.microsoft.com/pt-br/library/ms366342.aspx)

Para verificar todos os parâmetros das procedures listadas acima, digite por exemplo:

sp_help sp_add_jobschedule

CONCLUSÃO

Neste texto podemos notar que automatizar tarefas via script não é uma tarefa tão árdua, mas sem dúvidas, na maioria dos cenários, a utilização de uma ferramenta gráfica proporcionará maior produtividade; porém se um dia você se deparar com um MSDE ou situação semelhante, irá lembrar que com basicamente 4 passos é possível automatizar suas rotinas.

Existem três tipos básicos de backups no SQL Server: o backup completo, o backup diferencial e o backup incremental. O dois últimos sempre trabalham em conjunto com o backup completo.

Uma estratégia de backup é algo muito particular de cada negócio; em alguns ambientes críticos é inadimissível a perda de um minuto de informação, já em outros lugares, na ocasião de uma falha, um backup do dia anterior é a solução ideal; logo, a forma como mesclar os diferentes tipos de backups é uma questão a ser analisada (e testada!) com muito critério.

No entanto de uma coisa temos certeza: toda estratégia de backup incluirá um backup completo (comumente chamado de backup FULL) e neste texto iremos focar na recuperação (via script) de um backup completo no SQL Server; para isso utilizaremos como base dois cenários:

• O primeiro cenário abordará o restore de um backup FULL sobre a base original (do backup), por exemplo, sua base de dados atual sofreu alterações inadequadas e agora precisa da restauração do último backup para reaver os dados anteriores.
• No segundo cenário iremos visualizar um DBA que recebe um backup completo de um cliente e precisa restaurá-lo em outro ambiente, por exemplo, para sua equipe de desenvolvimento.

CENÁRIO 1

Temos aqui um arquivo de backup chamado AdventuresWorks_FULL.bak. Antes de restaurá-lo precisamos verificar qual o conteúdo desse arquivo físico e se o backup existente irá atender a necessidade do restore; para isso utilizaremos o seguinte comando:

restore headeronly from disk =’C:\LabRestore\AdventuresWorks_FULL.bak’

Veja o resultado:

No resultado da execução do comando RESTORE HEADERONLY podemos identificar que o arquivo em questão contém três backups (sim! um arquivo físico pode conter inúmeros backups de uma mesma base). Observe a posição de cada backup dentro do arquivo (campo Position), o tamanho de cada um (BackupSize)  e suas respectivas datas (BackupStartDate).

No nosso exemplo vamos restaurar o backup do dia 03 de Fevereiro, logo, o backup a ser restaurado será o da posição 2 (dois). Vamos ao script:

USE MASTER

GO

RESTORE DATABASE AdventureWorks

FROM DISK = ‘C:\LabRestore\AdventuresWorks_FULL.bak’

WITH FILE = 2, REPLACE, STATS = 10

A base de dados a ser restaurada é a AdventureWorks, o arquivo de backup está localizado no endereço: C:\LabRestore\AdventuresWorks_FULL.bak. O backup que será restaurado está na posição 2 deste arquivo (FILE = 2). Como a base já existe é necessário sobrescrevê-la, para isto utilizamos a opção REPLACE. O STATS mostrará o progresso da restauração em intervalos de 10 em 10%.

Importante: Numa operação de restore a base não deve estar em uso por nenhum usuário (inclusive você), por isso antes de iniciar o script direcionamos a sessão para o database Master. Se a base estiver em uso, a seguinte mensagem de erro será exibida:

Msg 3101, Level 16, State 1, Line 1

Exclusive access could not be obtained because the database is in use.

Se tudo estiver ok, ao final da execução do script você verá uma mensagem similar a esta:

RESTORE DATABASE successfully processed 22514 pages in 10.209 seconds (18.065 MB/sec).

CENÁRIO 2

Neste cenário o DBA deverá restaurar um backup completo recebido de um cliente externo. O arquivo de backup está identificado como SistemaX_FULL.bak e será restaurado no ambiente de desenvolvimento que é composto por um servidor com um único disco (C:\).

Vamos analisar o conteúdo do arquivo com o RESTORE HEADERONLY:

restore headeronly from disk = ‘C:\LabRestore\SistemaX_FULL.bak’

Veja o resultado:

No resultado acima verificamos que existe um único backup neste arquivo. A base do cliente (campo DatabaseName) está identificada por SistemaX e podemos verificar também outros dados como o tamanho do backup e data.

Até aqui tudo bem, mas neste cenário precisamos analisar novos elementos, isso porque a base em questão ainda não existe e ao efetuar a restauração o SQL Server irá trazer além dos objetos deste banco (tabelas, procedures, triggers) suas configurações originais como: endereço dos arquivos físico de dados e log, modo de recovery, etc. Para verificar o estado de algumas destas propriedades podemos utilizar o comando RESTORE FILELISTONLY:

restore filelistonly from disk = ‘C:\LabRestore\SistemaX_FULL.bak’

Veja o resultado:

Observe que a base do cliente e seus respectivos arquivos de dados e log estão localizados em discos diferentes. Neste caso, se o DBA realizar um restore comum (como o script utilizado no exemplo anterior) o SQL Server tentará alocar estes arquivos em seus caminhos de origem, logo precisamos alterar este comportamento, já que neste cenário o servidor onde será realizado o restore só possui um disco. Veja o comando:

USE MASTER

GO

RESTORE DATABASE SistemaX

FROM DISK = ‘C:\LabRestore\SistemaX_FULL.bak’

WITH

MOVE ‘SistemaX’ TO ‘C:\LabRestore\SistemaX.mdf’,

MOVE ‘SistemaX_log’ TO ‘C:\LabRestore\SistemaX_log.ldf’,

STATS = 10

A base de dados a ser restaurada é a SistemaX e o arquivo de backup está em: C:\LabRestore\SistemaX_FULL.bak. Observe que adicionamos a opção MOVE; esta opção direciona os arquivos de dados e log para um novo caminho. O restante não muda; continuo utilizando o STATS e desta vez não precisamos do REPLACE já que a base não existia.

É importante destacar que os comandos RESTORE FILELISTONLY e RESTORE HEADERONLY não são obrigatórios num processo de restauração de banco; eles são comandos que recuperam informações sobre os arquivos de backup e estas informações podem auxiliar o DBA no processo de restauração.

Existem outros comandos similares, como o RESTORE VERIFYONLY que verifica se o arquivo de backup está legível.

CONCLUSÃO

Como podemos verificar, o restore de um backup full, via script não é difícil, basta conhecer os comandos certos para recuperar informações sobre o conteúdo do arquivo de backup; estas informações  irão auxiliar o usuário na construção do comando de restore.

Nos próximos posts iremos abordar o restore de backups diferenciais e log. Até +

Bom trabalho!

Existem diferentes formas de configurar uma instância SQL Server, uma delas é através da procedure sp_configure. O interessante de utilizar a sp_configure é que o DBA não fica dependente da utilização de uma interface gráfica.

Ao executar a sp_configure sem parâmetros, são exibidas as configurações atuais da instância. Cada registro representa uma configuração e no campo run_value é possível visualizar o valor atual de cada configuração.

Num cenário padrão ao executar a sp_configure o resultado só exibe algumas das inúmeras opções de configuração; isso porque por padrão o SQL Server oculta opções avançadas. Para exibir todas as opções você deve executar:

USE master;

GO

EXEC sp_configure ‘show advanced option’, ’1′;

GO

RECONFIGURE;

sp_configure ‘nome da configuração’, ‘novo valor da configuração’.

Uma das configurações que podemos alterar utilizando a sp_configure é o limite de memória utilizada pelo SQL Server, vamos exemplificar a alteração desta configuração:

Atualmente minha instância está configurada para utilizar no máximo 500 MB de memória. Ao executar o comando sp_configure é possivel verificar que a opção max server memory (MB) está com o valor 500 nos campos config_value e run_value.

Para alterar a quantidade máxima de memória que a minha instância poderá utilizar executo o seguinte comando:

EXEC sp_configure ‘max server memory (MB)’, ’300′;

No comando acima configurei o máximo de memória disponível para a instância para 300 MB, no entanto se executarmos a sp_configure verificaremos que a opção run_value ainda continua com 500. Para efetivar a alteração preciso executar o comando RECONFIGURE; assim a alteração entrará em vigor.

Figura 1 – Monitorando o contador Target Server Memory durante execução do RECONFIGURE.

É importante salientar que apesar do comando RECONFIGURE ser obrigatório, nem todas as configurações são efetivadas somente com a execução do RECONFIGURE, para estas opções a efetivação só ocorre com a reinicialização do serviço do SQL Server. Para verificar quais são estas opções basta consultar a tabela sys.configurations (disponível no SQL Server 2005/2008). As configurações que tiverem o campo is_dynamic igual a 0 (zero) só entrarão em vigor quando o serviço do SQL Server for reiniciado. Note que se o comando RECONFIGURE não for executado, mesmo que a instância seja reiniciada a nova configuração não entrará em vigor.

Outras configurações possíveis através da sp_configure: habilitar a procedure xp_cmdshell,  procedures do Database Mail,  código gerenciado (CLR), configurar o número de processadores utilizados pela instância (paralelismo), configurar memória extendida (AWE), etc.

• RECONFIGURE ou RECONFIGURE WITH OVERRIDE?

Se ao alterar uma configuração o DBA definir um valor que foge às recomendações do SQL Server, ao executar a opção RECONFIGURE o SQL Server irá rejeitar a alteração e notificar o usuário. Por exemplo, na versão 2000 era possível realizar alterações nas tabelas de sistema do SQL Server (isso mudou um pouco nas versões 2005 e 2008), para isso bastava executar o comando:

EXEC sp_configure ‘allow updates’, ’1′.

No entanto, por razões óbvias esta não é uma prática recomendada, então nessas situações, ao executar somente o RECONFIGURE, o SQL Server exibia a seguinte mensagem:

Configuration option ‘allow updates’ changed from 1 to 1. Run the RECONFIGURE statement to install.

Msg 5808, Level 16, State 1, Line 1

Ad hoc updates to system catalogs not recommended. Use the RECONFIGURE WITH OVERRIDE statement to force this configuration.

Logo o DBA só poderia concretizar essa operação se utilizasse o RECONFIGURE WITH OVERRIDE, ou seja, esta é a forma do SQL Server se proteger contra ações indevidas e dizer ao DBA:  “amigo, isso é por sua conta e risco”. Portanto, o WITH OVERRIDE é uma opção a ser evitada e só é recomendada em situações pontuais.

• Conclusão

Conhecer as diferentes formas de configurar uma instância SQL Server dá ao DBA maior liberdade no momento de realizar estas tarefas, neste caso, além das ferramentas gráficas o DBA também poderá utilizar a sp_configure no SQLCMD, OSQL ou agendar alterações de configurações através de jobs e etc.

Para ter acesso a todas as opções de configurações disponíveis na sp_configure, consulte a tabela sys.configurations ou acesse o Books Online.

Bom trabalho, bons estudos.

No próximo sábado tem programão para a comunidade SQL Server!!!

Depois do SQL Server Day que promoveu 12 horas ininterruptas de palestras sobre SQL Server, pra fechar bem o ano de 2009 alguns caras vão se unir no próximo sábado para promover mais 5 horas de SQL Server, a partir das 18h.

Dá uma olhada na grade:

- Powershell & Transact-SQL (Laerte Jr) – 18:00 as 18:50 horas
- Profiler e Perfmon – (Vladimir Magalhães) – 18:50 as 19:40 horas
- Alta Disponibilidade: Mirroring (Vitor Fava) – 19:40 às 20:30 horas
- Performance & Tuning – (Rodrigo Crespi) – 20:30 horas as 21:20 horas
- Database Snapshots (Alexandre Lopes) – 21:20 às 22:10 horas
- SQL Server 2008 R2 (Thiago Zavaschi) – 22:10 às 23:00 horas

Para se inscrever: http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032437130&Culture=pt-BR

E pra quem não pôde conferir as palestras do SQL Server Day, os arquivos já estão disponíveis para download em: http://www.sqlserverday.com.br/.

Bom trabalho, bons estudos!

Uma dica rápida antes do feriadão:

Como agendar um script ou executá-lo de forma recorrente sem utilizar o SQL Agent?

O SQL possui um comando de controle de fluxo que pode nos auxiliar nessas tarefas: WAITFOR.

Como utilizá-lo?

Digamos que você queira monitorar o crescimento dos logs a cada 5 minutos. Nesse caso podemos utilizar o WAITFOR DELAY junto com uma estrutura de repetição como o while. Veja o exemplo:

declare @i int

set @i = 1

while @i < 12

begin

– coleta informação sobre espaço utilizado pelo log

dbcc sqlperf(logspace)

– aguarda 05 minutos para continuar

waitfor delay ’00:05:00′

set @i = @i + 1

end

Agora imagine um cenário onde você precise “agendar” a execução de um script para as 22h. Veja o exemplo:

– espera até às 22h

waitfor time ’22:00:00′

GO

dbcc sqlperf(logspace)

GO

select getdate() horaExecucao

É importante salientar que este comando não substitui o SQL Agent! Ele normalmente é utilizado em situações pontuais. Por exemplo, para o DBA às vezes é interessante monitorar durante alguns minutos a situação dos locks e para isso não é necessário criar um job e agendá-lo no SQL Agent, é mais simples utilizar o WAITFOR DELAY. Além disso você pode acompanhar o resultado das execuções diretamente no Management Studio, Query Analyser, sqlcmd, etc.

O comando é interessante, mas não veja nele uma forma de implementar uma nova política de backup, ok?

Bom feriadão!

Apesar de não ser minha praia, não posso deixar de comentar sobre o evento SharePoint Brasil Summit 2009 que aconteceu nesse fim de semana e o qual tive a oportunidade de participar. Meu foco de estudo e trabalho é banco de dados, mas algumas soluções são realmente fantásticas e o Sharepoint e o Office estão na minha lista de soluções preferidas (além disso, o Sharepoint e SQL Server se complementam de forma magistral).

Durante as apresentações era interessante ouvir as novidades que os palestrantes traziam e a reação do público (rolou até aplausos para algumas features).  Em particular gostei muito da nova interface Ribbon. O produto tem sido moldado para ser mais dinâmico e dá pra notar isso em coisas simples como a alteração e classificação (rating) de conteúdo, mudança entre janelas, etc.

Mas o que eu gostei de ver foi a prévia do Office Web Apps!! Fiquei surpreendido! Trabalhar com arquivos do Office, num browser, com a maioria das funcionalidades da versão instalada foi muito legal. E mais, a Microsoft promete isso em QUALQUER browser (isso eu quero conferir pessoalmente, risos). A feature co-autoria também ficou sensacional. A idéia é realmente facilitar a comunicação e ter o cuidado de tornar a experiência do usuário ainda melhor (creio que o Google Docs terá que reformular algumas coisas pra bater o que está vindo por aí).

Infelizmente a palestra de Excel Services e Business Conectivity Services não rolou e  era a que eu mais esperava, mas os organizadores do evento prometeram um vídeo sobre o conteúdo.

Em geral o evento foi bem interessante, muito organizado mas com um clima descontraído que facilitou a interação entre os participantes. Parabéns aos palestrantes e organizadores: Helio Sá Moreira, Rodolfo Roim e  Thiago Cruz Soares!

Agora é só aguardar pela versão definitiva do Sharepoint e do Office pro ano que vem… por enquanto, bom trabalho e bons estudos!

Curiosidade…

Já pensou em quantos profissionais possuem certificação Microsoft no mundo?

A Microsoft divulga estes números em seu site e segundo a última atualização realizada em 30/10/2009 são:

• 63.823 MCTS SQL Server 2005;
• 9.632 MCITP SQL Server 2005;
• 39 MCM SQL Server 2005;
• e 19 MCA Database.

Para chegar na certificação Master (MCM) que é pré-requisito para o MCA, o cara tem que fazer suas provas lá em Redmond, na própria Microsoft. É um teste de fogo, que além das provas teóricas e práticas, envolve também um investimento de uns U$ 20.000.

E ae… vai encarar?  :)

Para visualizar todos os números, visite este link.

Bom trabalho, bons estudos!