Fecho o ano formado em Banco de Dados pelo IBTA; o TCC foi um trabalho puxado, mas junto com meus camaradas Flavio Trigolo e Altair Alexandre conseguimos uma nota 10 de tirar o folego :) Sem dúvidas, o resultado foi fruto da dedicação e vontade em fazermos um trabalho de qualidade. Agradeço a esses dois caras pela super força!

Logo no início do ano atualizei o MCITP para o SQL Server 2008 e adquiri o MCT; agora sou um instrutor oficial Microsoft :) Agora acreditem, o melhor do MCT eu descobri depois: a biblioteca disponível para os MCTs é sensacional, uma excelente fonte de estudos.

O OCP não rolou; e a desculpa é fajuta (mas verdadeira): faltou tempo.

O projeto atual está a todo vapor e estou trabalhando como nunca… mas é um projeto sensacional; pra resumir o cenário imagine: a construção de um ERP (do zero) para um grande varejista do mercado… é este o lugar que estou trabalhando.

Aqui no blog foram 5500 visitas em média por mês… infelizmente em contrapartida eu falhei com a meta dos 2 posts por mês; essa meta ficou aquém do que eu havia planejado, mas pretendo compensar esse desfalque em 2012.

Na vida pessoal, graças a Deus, a vida com a família tem ido muito bem. A filhota completa em Janeiro 1 ano de idade e tem crescido com muita saúde. Não há felicidade maior que isso para um pai fresco, risos…

Enfim, que venha 2012!

A você, meu amigo, meus sinceros votos de um ano rico em saúde e conhecimento. Continuaremos juntos por aqui.

Forte abraço,

Silas Mendes

Assisti 8 trilhas e acho interessante tecer minhas considerações:

General Session

Essa foi a trilha de abertura do evento e abordou em resumo todas as novidades do mundo Microsoft para os próximos meses. Gostei. Teve um toque de show com direito a discurso do presidente da Microsoft Brasil, algumas demos apresentando o System Center 2012, Windows Phone 7, SQL Server Denali, Office 365, Cloud, Cloud, Cloud, Cloud (isso mesmo; acho que ouvi essa palavra umas 100 vezes, risos) e etc.

Em especial gostei:

• da notícia da fabricação do XBOX no Brasil;
• da apresentação do Windows Phone e suas aplicações;
• do System Center interagindo com dispositivos Android e iOS;
• dos novos relatórios (super dinâmicos) do Reporting Services sendo exibidos/editados no browser (via SharePoint).

Achei esta sessão um pouco longa; durou cerca de 3 horas… mas vamos falar um pouco das outras palestras:

O que há de novo no Microsoft SQL Server Code-Named “Denali”

Foi a segunda palestra que assisti e sinceramente, foi decepcionante. Não posso avaliar o conhecimento dos palestrantes, mas o conteúdo e a apresentação estavam muito aquém do que se espera de um evento desse porte. Sai dessa trilha na esperança de que o nível melhorasse nas próximas… e melhorou.

Como montar um ambiente de alta disponibilidade com o Hyper-V

O palestrante Rodrigo Immaginario mandou muito bem nessa sessão, abordando as vantagens e desvantagens das diferentes formas de implementação de um cluster + Hyper-V. O cara acessou o ambiente de produção dele no Espírito Santo e fez um live migration “no quente”. Gostei.

Microsoft SQL Server Code-Named “Denali” AlwaysOn: Introduzindo a nova geração de soluções para alta disponibilidade

Uma das melhores trilhas que assisti… Nilton Pinheiro fez uma  apresentação impecável da nova feature de alta disponibilidade do Denali: AlwaysOn. Foi nesta trilha que descobri algo muito interessante no Denali: agora poderemos instalar o SQL Server num Windows Server Core! Bacana!

No 2º dia assisti as seguintes trilhas:

T-SQL: o que você deve saber do Microsoft SQL Server 2008 R2 e as novidades do SQL Server Code-Named “Denali”

Excelente trilha com o Gustavo Maia. O cara apresentou com muita propriedade as novidades da linguagem T-SQL no SQL Server 2008 R2 e Denali, fazendo comparativos entre SGBDs, apresentando dados históricos, e etc. Enfim, essa palestra foi muito bacana porque eu ainda não tinha parado pra olhar as novidades do T-SQL no Denali; somou muito!

Boas práticas para o SQL Server em ambientes virtualizados

O palestrante Airton Leal mandou muito bem; era nítido o domínio do cara nas tecnologias de virtualização e ele deu dicas preciosíssimas para quem quer trabalhar com ambiente virtualizado. Uma informação muito interessante que ele disponibilizou: se você tem um sistema rodando numa maquina física e deseja transporta-lo para uma maquina virtual, esteja ciente que o overhead mínimo no desempenho será de 12%. Essa informação foi bem bacana, porque muita gente defende que não tem custo nenhum; afirmação que para mim sempre pareceu bem absurda. O único ponto que achei muito estranho nessa palestra: o título! Tudo era focado em boas práticas para ambientes virtualizados, porém, nada focado em SQL Server. Mesmo assim, somou!

Cenários de otimização com o SQL Server “Denali” e 2008

Trilha de alto nível técnico com o Luti e Fabiano Amorim… os caras deram dicas preciosas de otimização, todas muito bem argumentadas e demonstradas. Se eu não tivesse feito o curso de internals e de índices (com o Luti), diria que essa teria sido, para mim, a melhor trilha do evento, pois em 1 hora, os caras deram informações que você não encontra na maioria dos livros de tunning. Muito bom mesmo!

Raio-X do SQL Server: Arquitetura interna do gerenciador de banco de dados

Outra trilha fantástica! Inicialmente não tinha me programado para assistir essa palestra, porque fiz o curso de internals recentemente; mas mudei os planos mais na curiosidade e fui surpreendido pela apresentação do Catae e do Felipe Pimenta… em 1 hora os caras conseguiram resumir e discorrer sobre os principais pilares da arquitetura do SQL Server. Muita gente saiu dessa trilha com o cérebro fritando, mas os palestrantes foram ótimos e se esforçaram em serem o mais didático possível. Fechei o Teched com 2 trilhas nível 400 de verdade :)

Conclusão

O evento foi muito bom, com excelente organização e pontualidade. A maioria dos palestrantes eram “feras” e isso enriqueceu muito a experiência. Agora a pergunta que muita gente me faz: “voltaria ao evento em 2012?”. E eu respondo: o evento é muito bom, porém ainda acho que não vale o preço (principalmente quando o profissional paga do próprio bolso, risos). Enfim, poderiam dar uma melhorada no valor; ou quem sabe, no próximo ano, meu cliente resolve pagar essa conta; afinal ele é um dos principais beneficiados com esse investimento :D

Mas enfim, falando um pouco sobre profissão e bancos de dados, posso dizer que 2010 foi um ano memorável. Adquiri muito conhecimento, tanto em SQL Server como em Oracle. O SQL Server continua a minha principal plataforma de banco de dados, mas foi interessante estender o olhar para outro gerenciador e notar as diferenças, pontos fortes e fracos de ambos… percebi que é muito importante ter referências; afinal quando temos um único ponto de vista, não podemos falar com propriedade de outros…

Além disso entrei num projeto onde estou rodeado de uma dezena de DBAs. Além de excelentes contatos (risos), conquistei muitos amigos. Um ambiente assim é um sonho pra qualquer pessoa que deseja se desenvolver ainda mais. Implantamos a primeira parte de um sistema em produção, o processo exigiu muito esforço mas entrou no ar e foi gratificante.

Aqui no blog foram aproximadamente 3000 visitas por mês, pode parecer pouco, mas pra quem começou sem qualquer pretensão é um belo número!

Mas 2011 promete muito mais…

Pretendo escrever um pouco mais por aqui, tentando manter uma freqüência de pelo menos 2 posts por mês… aqui no projeto teremos o desafio de implantar a segunda parte do sistema em produção… último semestre da faculdade, junto com apresentação do TCC… quero adquirir mais uns MCITPs (e quem sabe um OCA) e enfim…

Se parar pra pensar é muita coisa pra fazer em 300 e poucos dias… mas vamos lá! Saúde e entusiasmo pra todos nós!

BEGIN TRANSACTION 2011

Demais :)

Até +

USE BOAS_FESTAS
GO
PRINT 'FELIZ NATAL!!!!!!!'
GO

:))))

Nosso cenário: Os arquivos de dados e log da base de dados MoveArquivo estão no mesmo disco. Para otimizar a performance decidimos movimentar o arquivo de log para outro disco.

Existem diversos meios de realizar esta tarefa, a seguir iremos analisar uma delas (e a que particularmente acho mais prática):

“Mão na massa”

Primeiro, precisamos ter algumas informações em mãos; por exemplo, o nome lógico do arquivo que será alterado e o local atual do arquivo de log de nossa base de dados:

Para isso podemos utilizar o comando sp_helpdb:

Ok; já sabemos onde está nosso arquivo de log. Agora precisamos alterar este endereço e para isto utilizamos o seguinte comando:

USE MASTER
GO
ALTER DATABASE MoveArquivo
MODIFY FILE (NAME = 'MoveArquivo_log', FILENAME = 'E:\SQLDbs\Log\MoveArquivo_log.ldf')
GO

Após execução do comando temos a seguinte mensagem:

The file “MoveArquivo_log” has been modified in the system catalog. The new path will be used the next time the database is started.

Temos então, numa tradução livre, o alerta: “O novo caminho só será utilizado após reinicialização da base”. Então fique atento! Este comando não alterou efetivamente o endereço físico do arquivo; para concluir a operação precisamos reiniciar a base.

Para não afetarmos a operação dos outros bancos da instância e para reduzirmos o tempo de parada, não vamos mexer com o serviço do SQL Server; vamos apenas alterar o estado da base de dados, deixando-a offline:

ALTER DATABASE MoveArquivo
SET offline
GO

Após execução deste comando a base fica indisponível para qualquer usuário e agora podemos copiar fisicamente o arquivo de log para seu novo endereço. Neste momento, através de um CTRL + C, CTRL+ V (ou qualquer outro meio de copiar um arquivo no Windows) copiamos o arquivo para seu novo endereço.

Atenção: tenha certeza de copiar o arquivo para o mesmo endereço informado no primeiro comando ALTER DATABASE.

Finalizada a cópia, podemos reiniciar nossa base de dados com o seguinte comando:

ALTER DATABASE MoveArquivo
SET online
GO

Pronto! Arquivo de log movimentado para novo endereço.

O mesmo procedimento pode ser utilizado para outros tipos de arquivos (como arquivos de dados). Para as bases de sistema (MASTER, TEMPDB, etc) não será possível utilizar a opção SET ONLINE/OFFLINE; neste caso teremos que reiniciar o serviço do SQL Server, afetando a disponibilidade de toda instância.

Até +

Em versões anteriores do SQL Server, poderíamos utilizar triggers DML para suprir necessidades similares, e para isso tínhamos que programar a trigger que seria disparada e que gravaria a alteração em outra tabela; no entanto, este processo demandava esforço e exigia um controle na manutenção das triggers e tabelas de apoio. Com o CDC, a partir do momento que o DBA habilita-o em determinada tabela, o SQL Server se responsabiliza por toda a estrutura necessária para capturar e registrar as mudanças.

Como funciona?

O CDC captura e registra alterações baseado no log do SQL Server; basicamente ele utiliza o mesmo mecanismo da replicação transacional: o CDC lê o log do SQL Server e registra as alterações em suas tabelas. Note que este processo é assíncrono, ou seja, um dado é alterado e a alteração fica registrada no log; periodicamente é feita uma leitura no log e as alterações são registradas nas tabelas do CDC (criadas pelo SQL Server no schema CDC).

“Mão na massa”

Agora vamos exemplificar um cenário simples utilizando o CDC, monitorando uma única tabela.

No primeiro passo iremos criar a tabela que será utilizada em nossos testes:

-- Cria tabelas para teste

CREATE TABLE Funcionario (
codigoFuncionario INT NOT NULL,
nome VARCHAR(60),
idade INT,
numeroCPF CHAR(11)
);
GO
ALTER TABLE Funcionario
ADD CONSTRAINT PK_CodFunc
PRIMARY KEY (codigoFuncionario);

Agora ativamos o CDC na base de dados e na tabela Funcionario:

-- Habilita CDC banco

EXEC sys.sp_cdc_enable_db;
GO
-- Habilita CDC na tabela Funcionario

EXECUTE sys.sp_cdc_enable_table
@source_schema = 'dbo',
@source_name = 'Funcionario',
@role_name = 'roleCDC';

Ao habilitar o CDC, o SQL Server cria jobs que serão executados pelo SQL Server Agent. Estes jobs serão os responsáveis pelo registro das alterações nas tabelas do CDC; logo, para o CDC funcionar corretamente, lembre-se que o SQL Server Agent deve estar em execução.

Com o CDC habilitado, vamos popular a tabela Funcionario:

-- Carga de dados

INSERT INTO Funcionario (codigoFuncionario, nome, idade, numeroCPF)
VALUES
(1, 'Silas Mendes', 29, '08643238736'),
(2, 'Antonio Robberto', 36, '04686398765'),
(3, 'Joana Maxado', 45, '52341369844'),
(4, 'Roberto',null, null),
(5, 'Armando Filo', null, '41397601223');

Agora já podemos consultar a tabela do CDC que armazena as alterações na tabela Funcionario:

Observe que a tabela do CDC está no esquema CDC.

Lembre-se que este é um processo assíncrono, portanto ao executar o comando abaixo, pode ser que a tabela ainda não tenha sido atualizada; neste caso, repita a execução do comando.

SELECT * FROM cdc.dbo_Funcionario_CT;

No resultado são retornadas 9 colunas. Neste momento atente-se à coluna __$operation. Note que ela está com o valor: 2. O valor 2 significa que estes registros foram resultado de inserções.

Vamos continuar manipulando os dados para verificar os reflexos das alterações nas tabelas do CDC:

-- UPDATEs na tabela Funcionario

UPDATE Funcionario
SET Nome = 'Antonio Roberto'
WHERE codigoFuncionario = 2;

UPDATE Funcionario
SET Nome = 'Joana Machado'
WHERE codigoFuncionario = 3 ;

UPDATE Funcionario
SET Nome = 'Roberto Nespolitano',
Idade = 18, NumeroCPF = '08468354173'
WHERE codigoFuncionario = 3;

Observe o registro das alterações na tabela do CDC:

SELECT * FROM cdc.dbo_Funcionario_CT;

Agora observe que aumentou a quantidade de registros da tabela do CDC. Além das inserções (__$operation = 2) temos também o ANTES e DEPOIS nas operações de UPDATE. Observe agora que, onde o campo __$operation é igual a 3 o registro contém o estado antes do UPDATE, e onde o campo __$operation = 4 temos o estado do registro após o UPDATE.

Para finalizar nosso exemplo, vamos realizar uma exclusão e verificar como essa alteração é registrada:

DELETE FROM Funcionario
WHERE codigoFuncionario IN (2,3);

Execute novamente a consulta na tabela do CDC:

SELECT * FROM cdc.dbo_Funcionario_CT;

Agora notamos: onde o campo __$operation = 1 temos os registros que foram excluídos da tabela Funcionario.

CONCLUSÃO

Como observamos, basicamente são necessários 4 passos para utilizar o CDC:

• Utilizar a versão Enterprise (ou superior) do SQL Server 2008;
• O serviço SQL Server Agent deve estar ativo;
• Ativar o CDC no banco de dados utilizando a procedure sp_cdc_enable_db;
• Ativar o CDC nas tabelas que serão monitoradas utilizando a procedure sp_cdc_enable_table.

Vimos também que na tabela de registro do CDC temos diversos valores para o campo __$operation, sendo:

Hoje abordamos somente os processos básicos do CDC. Irei estender este assunto em outros  posts, onde pretendo abordar alguns detalhes interessantes desta nova feature do SQL Server 2008.

Até +

A linguagem SQL é composta por inúmeros comandos, os quais são agrupados da seguinte maneira:

• Comandos que definem dados;
• Comandos que manipulam dados;
• Comandos de controle de dados.

Algumas literaturas adicionam outras subdivisões, mas neste post vamos nos ater somente as citadas acima.

• DDL

Quando você cria um banco de dados, ele inicialmente está “vazio”; antes de começar a consultar e alterar dados é preciso definir onde e como as informações serão gravadas dentro do novo banco; então você cria diversas tabelas explicitando o tipo de dados de cada campo, as chaves estrangeiras, os índices, as regras e etc. Estes comandos de criação e alteração de estrutura são os comandos de DEFINIÇÃO dos dados, pois definem como os dados serão armazenados; em inglês são chamados de: Data Definition Language (DDL). Logo, quando falamos em comandos do tipo DDL estamos falando de comandos do tipo: CREATE, ALTER ou DROP; comandos que criam, alteram ou excluem objetos como tabelas, procedures, índices, relacionamentos e etc.

Exemplos de comandos DDL:

-- Cria uma tabela

CREATE TABLE Pessoa(
codigoPessoa char(11),
nomePessoa varchar(50));

-- Altera tabela

ALTER TABLE Pessoa
ADD numeroTelefone varchar(11);

-- Exclui tabela

DROP TABLE Pessoa;

• DML

Depois que você criou suas tabelas, definiu relacionamentos, índices e etc., é hora de  manipular seus dados; os comandos SQL que MANIPULAM dados são os populares SELECT, INSERT, UPDATE e DELETE. Em inglês esses comandos são chamados de Data Manipulation Language o que explica a abreviação DML.

Em algumas literaturas o comando SELECT não é considerado um comando de manipulação de dados, sendo enquadrado numa outra categoria: DQL, Data Query Language, em português: Linguagem de consulta.

Exemplos de comandos DML:

-- Seleciona dados

SELECT nome+' '+sobrenome
FROM Pessoa;

-- Altera dados

UPDATE Pessoa
SET codigoPessoa = '35649869711';

-- Exclui dados

DELETE Pessoa;

• DCL

Com o banco de dados pronto e rodando é importante definir quem poderá acessá-lo, enfim, precisamos definir a segurança do seu banco. Em inglês, os comandos responsáveis pelo controle dos dados são chamados de Data Control Language (DCL). Os comandos GRANT e REVOKE fazem parte deste grupo.

-- Permissão de seleção na tabela Pessoa para a usuária Maria

GRANT SELECT ON Pessoa TO Maria;

-- Permissão de seleção e inserção na tabela Pessoa para o usuário Alberto

GRANT SELECT, INSERT ON Pessoa TO Alberto;

-- Negando alterações na tabela Pessoa para usuários do grupo GRP_RH

DENY INSERT, UPDATE, DELETE ON Pessoa TO GRP_RH;

• CONCLUSÃO

A linguagem SQL é constituída de diferentes tipos de comandos e estes comandos são agrupados em três categorias principais, sendo: comandos DDL as instruções que definem estruturas de armazenamento dos dados; DML os comandos que manipulam os dados e DCL os comandos que controlam o acesso aos dados.

Durante as atividades do dia-a-dia você utilizará com mais freqüência os comandos do tipo DDL e DML.

Até +

Finalmente na versão 2008 a Microsoft adicionou uma solução nativa para compactação de backups, no entanto esta opção só estava disponível na edição Enterprise.

Com a chegada do 2008 R2 a Microsoft estendeu a funcionalidade para a edição Standard; ou seja, a coisa tá ficando mais acessível.

“Mão na massa”

Para compactar o backup o processo é bem simples, basicamente precisamos adicionar a opção WITH COMPRESSION no comando de backup:

BACKUP DATABASE AdventureWorks
TO DISK = 'C:\AdventureWorks_compactado.BAK'
WITH COMPRESSION;

Agora o mais interessante: comparando backups da base AdventureWorks, um compactado e outro sem compactação, temos os seguintes números:

Vemos que o arquivo compactado tem cerca de 25% do tamanho do arquivo sem compactação. Bem bacana, não é?

Se você deseja que a compactação de backup seja Default na sua instância, altere a configuração backup compression default para 1:

EXEC sp_configure 'backup compression default', '1';
RECONFIGURE;

Assim, quando você realizar um backup, mesmo que não utilize explicitamente a opção WITH COMPRESSION (ou esqueça de utilizá-la) seus backups serão compactados.

Bom trabalho!

Vamos a um exemplo simples:

Primeiro criamos duas tabelas com estrutura idêntica. A chave primária destas tabelas é o campo CPF:

create table Tabela1 (
Nome varchar(50),
Idade int,
CPF char(11) primary key);

create table Tabela2 (
Nome varchar(50),
Idade int,
CPF char(11) primary key);

Agora inserimos dados nas tabelas. Observe que os dados estão diferentes, alguns tem diferença no nome, outros registros estão sobrando ou faltando em ambas tabelas:

insert into Tabela1 values
('Silas Mendes' , 29, '08148338716'),
('Maria José'   , 49, '55978913269'),
('Pedro Ribeiro', 53, '05899714732'),
('Joana Silva'  , 18, '74105689623');

insert into Tabela2 values
('SILAS Mendes'       , 29, '08148338716'),
('Maria Jose'         , 49, '55978913269'),
('Pedro Ribeiro Souza', 53, '05899714732'),
('Carlos Mania'       , 19, '12345678999');

Agora precisamos sincronizar as tabelas, vamos analisar passo-a-passo a construção do comando MERGE (o comando completo está disponível no fim do texto) .

A tabela de destino (target) é a tabela2; a tabela de origem (source) é a tabela1. A chave primária das tabelas será utilizada na comparação:

merge into tabela2 as target
using (select nome, idade, cpf from tabela1)
  as source (nome, idade, cpf)
  on (target.cpf = source.cpf)

Quando os números dos CPFs forem encontrados em ambas tabelas então atualizamos os dados na tabela alvo (target):

when matched then
		 update set target.nome = source.nome,
					target.idade = source.idade,
					target.cpf = source.cpf

Quando os números dos CPFs não forem encontrados na tabela de destino, então inserimos os dados da tabela de origem:

when not matched by target then
		 insert (nome, idade, cpf) values (nome, idade, cpf)

E finalmente, quando existirem números de CPFs no destino que não existem na origem, apagamos os registros que sobram:

when not matched by source then
		 delete;

Veja o código completo do comando MERGE:

merge into tabela2 as target
using (select nome, idade, cpf from tabela1)
  as source (nome, idade, cpf)
  on (target.cpf = source.cpf)

-- Atualiza registros diferentes
when matched then
		 update set target.nome = source.nome,
					target.idade = source.idade,
					target.cpf = source.cpf

-- Insere registros que não existem no destino
when not matched by target then
		 insert (nome, idade, cpf) values (nome, idade, cpf)

-- Se existir no destino e não existir na origem é apagado
when not matched by source then
		 delete;

Por fim realizamos o SELECT nas duas tabelas para verificar o resultado após a sincronização:

select * from Tabela1;
select * from Tabela2;