Sempre conversamos aqui sobre bancos de dados… mas hoje “quebro o protocolo” para apresentar aos meus amigos nerds minha filhinha, nascida na última quarta-feira (05/01/2010)… sensação fantástica e indescritível…
Demais :)
Até +
USE BOAS_FESTAS GO PRINT 'FELIZ NATAL!!!!!!!' GO
:))))
Uma das atividades que pontuam a rotina de um DBA é a movimentação de arquivos de bancos de dados; normalmente resultado de falta de espaço em disco, mudança de arquitetura, otimização e etc.
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é +
A edição Enterprise do SQL Server 2008 veio com uma funcionalidade nova e bastante interessante conhecida como CDC, abreviação de Change Data Capture. Esta função permite que o DBA capture e registre todas as mudanças feitas numa determinada tabela, de forma bastante simples.
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:
Vimos também que na tabela de registro do CDC temos diversos valores para o campo __$operation, sendo:
| Comando DML | __$operation |
| DELETE | 1 |
| INSERT | 2 |
| Antes do UPDATE | 3 |
| Depois do UPDATE | 4 |
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:
Algumas literaturas adicionam outras subdivisões, mas neste post vamos nos ater somente as citadas acima.
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;
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;
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;
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é +
Livros são ótimas companhias e se eu pudesse não me desfaria de nenhum… no entanto meu apartamento anda meio abarrotado :)
Estou colocando a venda a preços bem camaradas alguns livros da minha prateleira. Os preços variam de R$ 4,00 a R$ 25,00; a maioria relacionada com bancos de dados.
Se quiser dar uma olhada, clique aqui :)
Até +
Dica de última hora!!!
Pra você que é estudante e quer ficar mais próximo do mercado de TI, vai aí uma dica bem interessante:
Até o dia 28/09/2010, a Microsoft recebe inscrições para a 7º edição do Microsoft Students to Business; esse é um programa que pretende aproximar os estudantes para o mercado de TI, fornecendo um super treinamento de 84 horas… e o melhor de tudo: gratuito.
O público alvo são alunos do ensino médio, cursos técnicos, superior e pós-graduação… e o estudante pode optar pelas seguintes áreas: desenvolvimento de sistemas, infraestrutura, banco de dados, Expression Web e Dynamics CRM.
Então fique ligado:
Inscrições até o dia 28/09/2010.
Mais informações no site: http://proform.msdnbrasil.com.br/PortalS2B/
Boa sorte!
A compressão de backups sempre foi um dilema para quem lida com grandes bases de dados no SQL Server. Muitos DBAs criaram rotinas para compactar arquivos de backup utilizando o bom e velho RAR, outros utilizavam soluções mais interessantes como o SQL Backup da RedGate.
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!
O SQL Server 2008 trouxe para o T-SQL um comando brilhante que realmente facilita a vida de muita gente; o comando em questão é o MERGE. A idéia deste comando é mesclar dados, logo você pode comparar duas tabelas e utilizar o comando MERGE para sincronizá-las.
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;
Acabei de ver essa no Buzz do meu amigo e professor Rodrigo Smarzaro… muito boa!
Fonte: http://xkcd.com/327/
Traduzido por: seginfo.com.br
A cada nova versão do SQL Server a Microsoft torna 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é +
Eu estava reagendando esta prova a mais de um mês. Toda vez que eu folheava o Training Kit me deparava com uma novidade do SQL Server 2008 que me fazia olhar e querer entender mais os detalhes, e assim eu reagendava o exame pois achava que não estava preparado. No fim de semana estabeleci que faria a prova na segunda-feira (ontem) e que não iria adiar mais.
A questão é que o foco do 70-432 não são os detalhes, você precisa ter o conhecimento das novas features, entender suas principais finalidades e os pré-requisitos para implementá-las.
O exame me surpreendeu porque eu esperava um grau maior de dificuldade… mas foi uma boa prova; o grande foco está nas novidades, mas em algumas questões você tem que utilizar soluções de versões anteriores. Ao contrário da 70-431 não teve o teste prático (que eu achava interessante) e foram quase duas horas para responder aproximadamente 40
questões. Comparando os dois exames, para mim o 70-432 está mais fácil.
Se você está preocupado com a complexidade das novas features do SQL Server 2008, eu te encorajo dizendo que este não é o exame que irá abordar detalhes. Foque na visão geral da administração e encare a prova.
Tenho que acrescentar também que esta foi a primeira vez que fiz uma prova na Brás Figueiredo e a experiência foi muito agradável: ambiente silencioso, ar-condicionado numa temperatura adequada, um bom equipamento, enfim, recomendo.
Depois de escrever tudo isso tenho que complementar que fui aprovado :)
A sensação de não utilizar a “Segunda Chance” é sempre boa (não posso negar) e eu só posso desejar o mesmo a todos vocês.
Bom trabalho e bom estudo!
