Archives
Você na nuvem!
Em meados de 2007 comecei a ouvir de forma recorrente a palavra “nuvem” invadir os círculos de bate papo da turma de TI. A idéia da nuvem era fortemente baseada no conceito de computação em grade, onde inúmeros computadores eram interligados e juntos somavam uma quantidade abundante de recursos computacionais. Grandes empresas como Amazon, Google e Microsoft começaram a explorar o lado comercial desta idéia, vendendo seus recursos para empresas que desejavam hospedar suas aplicações remotamente. O termo nuvem foi adotado porque o acesso a estes super conjunto de computadores se dá pela internet e para o cliente não importa necessariamente qual hardware está suportando esta estrutura; a idéia é justamente deixar essa infraestrutura transparente para os clientes.
Nesta epoca diversos “evangelistas” pregavam de forma veemente que dentro de poucos anos toda a estrutura de servidores das empresas seria descartada e tudo seria transportado para a nuvem: ERPs, CRMs, servidores de e-mail, bancos de dados… tudo estaria na nuvem. Isso levantou muita polêmica, mas a idéia tinha suas vantagens pois com isso as empresas teriam mais foco em seu próprio negócio e não teriam gastos diretos com manutenção de hardware, software, licenças, salas refrigeradas, consumo de energia e etc.
Participei desses círculos de forma bem neutra, pois algo que eu estranhava nesse cenário é que tudo dependia de um bom link com a internet e justamente, em Julho de 2008 presenciamos uma pane na Telefônica que deixou São Paulo desconectado; grandes empresas e inclusive o orgãos do governo ficaram sem link por horas e o prejuízo foi grande.
Num cenário desses, qual diretor de TI apostaria na hospedagem de seus serviços na nuvem, sendo que a depêndencia com um link é vital?!
De lá pra cá passaram-se 4 anos. O assunto “nuvem” ainda continua na crista da onda, mas já não de forma tão febril quanto antes. Mas o que tenho observado é que, sim, estamos aos poucos indo pra nuvem e a mudança está começando por nós, usuários.
Hoje a agenda e fotos do meu celular estão sincronizados com a nuvem. Quando trocar de aparelho bastará associar meu login para ter tudo de volta. Atualmente também hospedo meus principais arquivos no DropBox, aplicativo onde armazeno meus arquivos na nuvem e sincronizo uma cópia em todos os PCs que possuo, inclusive tablets e celulares. HDs não são confiáveis, de uma hora pra outra dão um problema e te deixam na mão, então porque não deixar tudo na nuvem?
Por U$ 50,00 anuais tenho 200 GB de espaço no Google para armazenar meus vídeos e fotos. Isso mitiga todos os riscos? Não. É claro que o Google e o DropBox podem perder meus arquivos, mas o risco não é comparado ao ter meus arquivos num único HD. Essas empresas armazenam nossos arquivos em datacenters espalhados pelo mundo, com profissionais dedicados 24×7 na manutenção destes ambientes.
Mas quais as vantagens da nuvem para nós usuarios, além da alta disponibilidade e a possibilidade de acessar seus arquivos de qualquer parte do mundo? Uma vantagem interessante é que você paga pelo que usa; se hoje 200 GB é muito para armazenar todas as suas fotos, então contrate 20 GB iniciais e pague somente U$ 5,00 anuais. Agora pense o quanto isto pode ser interessante pra sua empresa. Imagine aqueles períodos sazonais onde sua empresa tem grande demanda comercial e a necessidade de consumo de recursos computacionais é maior?!
Enfim; para essa coisa virar ainda é necessário muito investimento em infraestrutura no Brasil e quando isso se concretizar, eu acredito sim, que nós (empresas e usuários) estaremos nas nuvens!
Teched 2011
Semana passada rolou o Teched 2011 e eu estive lá durante os 2 dias do evento. Reencontrei muitos amigos e conheci outros que só conhecia da comunidade virtual. Show de bola, fortalecendo o networking :)
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
O que é SQL?
Pra começar você precisa saber que SQL não é um banco de dados; SQL é um idioma (entre especialistas costumamos substituir o termo “idioma” por “linguagem”). A sigla SQL significa Structured Query Language; em português: linguagem de consulta estruturada. Destaquei o “consulta” porque o foco dela é justamente isso: consultar!
Os bancos de dados (ou gerenciadores de bancos de dados) nasceram antes da linguagem SQL e cada qual tinha sua própria linguagem de consulta. Logo os usuários e fabricantes notaram que essa torre de babel não era interessante e optaram pela criação de um único idioma para consultar bancos de dados relacionais (em outra oportunidade falaremos sobre os bancos dimensionais). O órgão American National Standards Institute (ANSI) ficou responsável pela padronização desta linguagem e de tempos em tempos realiza encontros entre fabricantes para discutir a linguagem SQL e propor melhorias; no entanto esta padronização não impede que cada fabricante personalize a linguagem SQL para atender suas necessidades, e é aí que surgem os dialetos. Por exemplo, o “dialeto” do gerenciador de banco de dados Oracle é o PL/SQL; o do SQL Server é o T-SQL (transact SQL) e etc.
Agora é importante que você não confunda a linguagem SQL com gerenciadores de banco de dados! Isso é um erro muito comum!
Por exemplo, o gerenciador de banco de dados Microsoft SQL Server (como o nome já diz), é um programa que gerencia bancos de dados. A arquitetura dos sistemas gerenciadores de bancos de dados (SGBDs) é definida de forma que os dados possam estar sempre consistentes e que sejam recuperados da forma mais rápida possível! Digamos que estes são itens de série de qualquer SGBD. Para tornar os gerenciadores de bancos de dados ainda mais atraentes, os fabricantes adicionam outras inúmeras funcionalidades para facilitar o trabalho dos DBAs, aumentar a segurança, a disponibilidade e etc.
Hoje existem diversos gerenciadores de 
bancos de dados disponíveis no mercado, como o Oracle, o Microsoft SQL Server, o PostgreSQL, entre outros. Todos utilizam a linguagem SQL para consultar dados.
A grande dúvida que paira na cabeça de alguns profissionais de TI é: qual o melhor banco de dados? SQL Server? Oracle?! DB2?
O que eu digo é o seguinte: o melhor gerenciador de banco de dados é aquele que atende adequadamente o seu negócio. É como comprar um carro: você compraria uma Ferrari para fazer rally?! Compraria um Fusca para fazer uma longa viagem pelo Brasil?
Conclusão
SQL é uma linguagem de consulta a bancos de dados relacionais. No mercado atual existem inúmeros sistemas gerenciadores de bancos de dados relacionais (comumente chamados apenas pela sigla SGBD); podemos citar como exemplo o Oracle, Microsoft SQL Server, DB2, etc. Estes gerenciadores de bancos de dados utilizam a linguagem SQL para consultar os dados; porém, adicionam à esta linguagem soluções para atender suas particularidades e aí nascem dialetos como o PL/SQL, PL/pgSQL e o T-SQL.
Nos próximos posts falaremos mais sobre a linguagem SQL e os gerenciadores de bancos de dados.
Para conhecer mais detalhes sobre a linguagem SQL, dê uma olhada nesse post e fique familiarizado com outras siglas populares no mundo SQL como: DDL e DML!
Até +
Backup FULL reinicia sequência do LOG. Mito?
Olá,
No mês de Abril fiz o curso de SQL Server Internals com o Luciano Moreira, mais conhecido na comunidade como Luti; não vou me estender muito neste assunto, mas se você é um DBA SQL Server, recomendo fortemente que faça este curso. Excelente…
Mas vamos ao foco do nosso post. Durante o curso de internals alguns mitos foram por água abaixo; um deles foi “Ao realizar um backup full, perdemos a sequência do log”.
Verdade? Sim ou Não?
Bom, confesso que eu sempre tive isso como verdade absoluta e tenho certeza que outros inúmeros DBAs SQL Server pensam o mesmo; mas a verdade é que não, realizar um backup full não quebra a sequência do seu log. Mas falando assim não tem graça né, vamos testar a brincadeira:
Primeiro criamos um banco para nosso teste (no fim do post está o script completo do nosso teste):
CREATE DATABASE testeBackup
Por padrão o SQL Server criar o banco com o recovery model FULL (exceto na edição Express). Isto é importante para o nosso teste já que iremos realizar backup do log. Para confirmar:
-- Recovery Model = FULL SELECT recovery_model_desc FROM sys.databases WHERE NAME LIKE 'testeBackup'
Vamos criar uma tabela para nossos testes e realizar nosso primeiro backup FULL:
USE testeBackup -- Cria tabela CREATE TABLE registroBackup (id INT IDENTITY, registro VARCHAR(50)) -- Realiza backup FULL BACKUP DATABASE testeBackup TO DISK = 'C:\testeBackupFULL.bak' WITH INIT
Agora utilizando uma estrutura de repetição inserimos 1 registro na tabela e realizamos um backup de log. Isso repetirá por 5 vezes:
DECLARE @i INT
SET @i = 1
WHILE @i <= 5
BEGIN
-- Insere registro
INSERT INTO registroBackup
VALUES ('Antes do '+CAST(@i AS VARCHAR(2))+'º backup de LOG')
-- Realiza backup de log
BACKUP LOG testeBackup
TO DISK = 'C:\testeBackupLOG.bak'
WITH NOINIT
-- Incrementa contador
SET @i = @i + 1
END
Verificamos então os registros inseridos na tabela:
SELECT * FROM registroBackup
Resultado:
E verificamos os nossos backups de log:
RESTORE HEADERONLY FROM DISK = 'C:\testeBackupLOG.bak'
Resultado:
Como verificamos temos aí 5 registros e 5 backups de log.
Agora realizamos um novo backup FULL:
BACKUP DATABASE testeBackup TO DISK = 'C:\testeBackupFULL_2.bak' WITH INIT
E repetimos a execução do laço:
DECLARE @i INT
SET @i = 6
WHILE @i <= 10
BEGIN
-- Insere registro
INSERT INTO registroBackup
VALUES ('Antes do '+CAST(@i AS VARCHAR(2))+'º backup de LOG')
-- Realiza backup de log
BACKUP LOG testeBackup
TO DISK = 'C:\testeBackupLOG.bak'
WITH NOINIT
-- Incrementa contador
SET @i = @i + 1
END
Ao fim temos 10 registros em nossa tabela, 10 backups de LOG e 2 backups FULL.
Agora entra a figura do estagiário que exclui o segundo arquivo de backup FULL… (sacanagem, rss)
Segundo a lenda, isso inválida todos os backups de log posteriores e teríamos que realizar um backup FULL imediatamente, porque ao realizar o segundo backup FULL perderíamos a seqüência do log. Certo? Bom… vamos testar:
Excluímos a base de dados:
USE MASTER GO DROP DATABASE testeBackup
E restauramos os backups (FULL + LOGs) ignorando o segundo backup FULL:
RESTORE DATABASE testeBackup FROM DISK = 'C:\testeBackupFULL.bak' -- primeiro backup FULL WITH NORECOVERY -- Restauramos os 10 arquivos de log DECLARE @i INT SET @i = 1 WHILE @i <= 10 BEGIN RESTORE LOG testeBackup FROM DISK = 'C:\testeBackupLOG.bak' WITH FILE = @i, NORECOVERY SET @i = @i + 1 END RESTORE DATABASE testeBackup WITH RECOVERY -- colocamos a base em operação
Verifique que restauramos os 10 registros de nossa tabela:
USE testeBackup SELECT COUNT(*) FROM registroBackup
Resultado:
Enfim, note que a realização do 2º backup FULL não quebrou a seqüência dos nossos backups de log!
Agora a pergunta que não quer calar: qual a função do parâmetro de backup COPY_ONLY lançado a partir do SQL Server 2005?!
Um backup diferencial tem total dependência do último backup FULL; logo, se você perder o backup FULL anterior, não será possível restaurar o diferencial, mesmo com um FULL mais antigo. Então pense numa situação que você precise de um backup FULL adicional, mas não deseja que ele afete seus próximos backups diferenciais (que deverão continuar utilizando como referência o backup FULL anterior), então aqui utilizaríamos o COPY_ONLY.
Resumindo: Os backups diferenciais posteriores iram ignorar um backup FULL com COPY_ONLY.
CONCLUSÃO
Backup FULL não altera a sequência dos backups de LOG. Se você perdeu seu último backup FULL, mas tem um do mês passado e de lá pra cá todos os seus backups de LOG estão intactos, não se desespere! Você conseguirá restaurar seu backup.
PS: Obrigado Luti pela super dica :D
Disponibilizei o script completo deste teste aqui.
Até +
Solucionando usuários orfãos
Um problema comum:
Você restaura um backup numa nova instância e ao tentar conceder as permissões para seus usuários encontra o seguinte erro:
User, group, or role ‘nome_do_usuario‘ already exists in the current database.
(No fim deste post está disponível um arquivo contendo base e scripts utilizados neste cenário.)
Ou seja, o login já existe na instância e ao tentar defini-lo como usuário da base, o SQL reclama que ele já é um usuário da base de dados; no entanto, ao tentar conectar no banco com este usuário o SQL Server adverte que o mesmo não tem permissões para se conectar:
Msg 916, Level 14, State 1, Line 1
The server principal “nome_do_usuario” is not able to access the database “nome_do_banco” under the current security context.
… assim não é possível conceder permissões ao usuário e nem utilizá-lo.
Normalmente este problema ocorre porque o login em questão já era usuário da base de dados em sua instância de origem. Ao restaurar o backup em outra instância, onde o mesmo login existe, o SQL Server não estabele um link automático entre o login pré-existente e o usuário que veio junto com base restaurada; assim surgem os usuários órfãos.
Veja que é um problema muito comum, no entanto, muitas pessoas tentam resolve-lo apagando o usuário da base e recriando novamente a partir do login; no entanto, ao fazer isto, perceba que perdemos todas as configurações atribuídas àquele usuário na base determinada, como permissões e etc.
Para solucionar este problema adequadamente utilizamos o procedimento: sp_change_users_login
Inicialmente podemos executar a procedure (dentro da base restaurada) com o seguinte parâmetro:
EXEC sp_change_users_login 'Report';
Com este parâmetro o procedimento irá mostrar todos os usuários órfãos da sua base; ou seja, usuários que existem na sua base de dados, mas que não possuem um login correspondente:
Para solucionar efetivamente o problema, executamos a procedure com diferentes parâmetros. No exemplo abaixo, executamos a procedure passando como parâmetro o nome do usuário órfão e o login correspondente. Ao executá-lo, o SQL Server estabelece uma relação entre ambos:
EXEC sp_change_users_login 'Update_One', 'usuario42', 'usuario42';
Note que o nome do login e do usuário não precisam ser iguais, no entanto é muito comum utilizamos o mesmo nome para logins e usuários, então para abreviar a solução podemos utilizar somente:
EXEC sp_change_users_login 'Auto_Fix', 'usuario42';
Assim o SQL Server entende que a relação deverá ocorrer entre um usuário e um login de mesmo nome.
Este procedimento pode ser utilizado também quando você possuir um usuário, mas ainda não possuir um login correspondente criado; assim em um único comando é possível cadastrar o novo login, atribuir sua senha e estabeler a relação entre eles; veja o exemplo:
EXEC sp_change_users_login 'Auto_Fix', 'usuario42', NULL, '@#mochil3ir0'; -- senha
Conclusão
Neste post entendemos o que são usuários orfãos e como estabeler vínculos entre logins e usuários de banco de dados utilizando o procedimento sp_change_users_login. Este procedimento tem diferentes comportamentos de acordo com os parâmetros passados. Utilizar este procedimento simplifica a configuração da sua base de dados e mantém todas as características de seus usuários previamente configuradas.
Para simular este erro e sua solução, baixe este arquivo contendo a base e script do cenário.
Até +
BEGIN TRANSACTION 2011
Um belo ano terminou e agora 2011 começa efetivamente pra mim. E já começou em ritmo alucinante com o nascimento da minha filha (vide post anterior); sem dúvidas uma experiência marcante, sensacional e indescritível. Apesar das noites sem sono (sim, já estou passando por essa fase, risos) a sensação é de que um evento que foge a nossa razão está ocorrendo a cada momento… e a gente percebe que tudo irá mudar daqui pra frente, e isso é fantástico!
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
Ho Ho Ho!!!
USE BOAS_FESTAS GO PRINT 'FELIZ NATAL!!!!!!!' GO
:))))
Movimentando arquivos da base de dados
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é +
Livros
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é +
Restaurar Backup via Script
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!
SQL Server Saturday Night
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!