Acordo de Nível de Serviço (SLA)

Um passo importantíssimo para entregar o valor esperado pelos clientes com os serviços de TI é garantir que exista um acordo de nível de serviço, planejado por todas as áreas de TI bem como com o cliente final. Logicamente não basta existir um SLA (Service Level Agreements), ele deve ser cumprido, mas o fato de existir algum SLA já é o primeiro passo, por que significa que o mesmo foi discutido dentro da área de TI bem como com o cliente.

O SLA é útil para garantir que os serviços entregues atendem às expectativas de negócios, as metas de desempenho e os custos necessários para a entrega de um determinado serviço de TIC a um conjunto de clientes. Um SLA eficaz reflete a comunicação entre os clientes e usuários (os consumidores do serviço) e deverá traduzir-se na tabela de indicadores. Os objetivos de nível de serviço que são identificados, em seguida, serão usados para desenvolver e personalizar o scorecard de aderência para o serviço.

O SLA deve ser balanceado entre ser relevante e factível. Em geral, a disponibilidade desejada por todos é de 100%, mas isso, infelizmente, é irreal. O SLA deve conter um objetivo relevante a ponto de atingir o nível de serviço realmente necessário e exigido pelo negócio, mas também deve ser possível de ser entregue, não pode conter premissas ou promessas irreais.

Um SLA deve possuir a descrição e definição, em linguagem clara para o cliente, de todos os pontos importantes sobre o serviço de TIC. Por exemplo, descrição do serviço, seus requerimentos, necessidades de dados de entrada, saídas esperadas, horários de funcionamento do serviço, tempos de atendimento ao usuário em caso de problema, disponibilidade total esperada, tempo de retorno em caso de indisponibilidade, etc.

Cálculo de Disponibilidade

Um dos pontos mais comuns de ser descrito em um SLA é a disponibilidade esperada do serviço. Um indicador comum usado para medir a disponibilidade é o percentual de tempo que um serviço foi capaz de servir aos seus clientes e usuários.

• Percentagem de disponibilidade = Tempo Total em Serviço / Tempo Total Esperado em Serviço

No caso de um serviço que é esperado que funcione 24 x 7, o tempo total esperado, no ano, é de 24 horas x 365 dias = 8760 horas.

Em geral, a disponibilidade desejada por todos é 100%, mas isso, infelizmente, é irreal. Num caso mais realista, a disponibilidade nos SLAs é medida em “noves”, ou seja, quantos “noves” no percentual são esperados. Um serviço que é esperado “3 noves” deve ter disponibilidade de 99,9%.

A tabela abaixo mostra os cálculos de disponibilidade em relação a um serviço 24×7, com base anual.

% Disponibilidade	Horas Totais no Ano (24×7)	Tempo máximo de indisponibilidade	Horas Totais no Ano (8×5)	Tempo máximo de indisponibilidade
90%	8760 horas	876 horas (36,5 dias)	2086 horas	208.6 horas (26 dias)
95%	8760 horas	438 horas (18,3 dias)	2086 horas	104 horas (13 dias)
99% (2 noves)	8760 horas	87 horas (3,6 dias)	2086 horas	20,86 horas (2,6 dias)
99,9% (3 noves)	8760 horas	8,76 horas	2086 horas	2 horas
99,99% (4 noves)	8760 horas	52,56 minutos	2086 horas	12,5 minutos
99,999% (5 noves)	8760 horas	5,3 minutos	2086 horas	1,25 minutos

Como pode ser reparado na tabela de tempos de indisponibilidade, o tempo máximo aceitável de indisponibilidade é alterado com a alteração do tempo total esperado de serviço (janela de funcionamento do serviço). No caso de um serviço em horário comercial (8×5), uma queda do sistema durante a madrugada, com o serviço voltando a funcionar antes ainda do horário comercial não afeta o cálculo de disponibilidade para efeitos do SLA, por que o serviço não tinha a obrigação de funcionar fora da sua janela estipulada.

O que deve ser considerado para confecção de um SLA?

A Microsoft recomenda considerar os seguintes pontos quando da criação e manutenção de SLAs e medições de disponibilidade:

• Necessidades reais de negócio – Os custos de alcançar maior disponibilidade podem não valer a pena considerando os benefícios reais necessários. Analise a real disponibilidade de serviço de TIC que sua empresa realmente precisa antes de definir metas. Ter sempre meta de 24×7 com 99,999% de disponibilidade pode ser desejável para todos os serviços, mas obriga um enorme investimento em pessoas, processos e tecnologia a fim de atingir esse nível e poucos serviços realmente precisam disso.
• Correta granularidade – Um sistema de TI, seja qual for, tem múltiplas medições e monitorações de disponibilidade, e não simplesmente funcionando e parado. Partes distintas podem estar funcionando enquanto outras podem ter algum problema de disponibilidade. Uma regra simples, clara e justa deve ser alcançada para que o cálculo não seja mais custoso que a informação resultante deste.
• Responsabilidade e Cobrança – uma pessoa ou time deve ser responsável por cada medição, e deve ser garantido poder de decisão necessário para que seja feito o que é necessário para controlar o serviço e respeitar os SLAs.
• Riscos Ordinários e Extraordinários – Falha de disco ou memória, bem como rede e falta de energia são riscos ordinários, previsíveis, que são parte do cotidiano. Você sabe que os enfrentará mais cedo ou mais tarde e deve se planejar para quando isso ocorrer. A maior probabilidade de indisponibilidade pode ser tratada analisando e previnindo riscos ordinários.
  O tipo de planejamento a ser feito para riscos extraordinários é bem diferente e deve inclusive levar em conta risco de perda de pessoal e instalações. São eventos mais raros e especiais, mas que devem ser avaliados se vale a pena prevení-los ou apenas conhecê-los e preparar reação em caso de ocorrência. Isso vai depender do custo da prevenção e também da quantidade e importância dos recursos envolvidos pelo risco.
• Escopo e tolerâncias – métricas rígidas e absolutas podem trazer mais malefícios do que benefícios. Atritos entre áreas, avaliações e auditorias no cálculo do SLA e outros fatores podem ser resultados de intolerâncias. Em geral, recomenda-se trabalhar com médias e desvio padrão para cálculos de indicadores de SLA.
• Mensurabilidade – cada item do SLA deve ter um indicador e meta determinada. O SLA deve ser oficializado em cima de valores trangíveis e objetivos, nunca sobre avaliações pessoais e subjetividade. Termos como “melhor”, “mais disponível”, “total”, etc. devem ser evitados, dando-se preferência para “10% de melhoria a cada ano”, ou ainda, “99% de disponibilidade claculada sobre a fórumula XXX =YYY / ZZZ”.
• Margens de Erro – um outro aspecto da capacidade de medir algo é a margem de erro de medição. Por exemplo, a Microsoft possui dezenas de Active Directory Domain Controllers e Exchange Servers espalhados pelo mundo em diversos datacenters. Sincronização de horário entre todos os serviodres pode levar um certo tempo e ainda assim acontecer com pequenas diferenças de horário. Uma mensagem de ping pode ter o seu horário de chegada, visto por um servidor, milisegundos antes do seu horário de saída. Sabemos que isso é impossível, logo deve-se ao fato de sincronização e outros detalhes inerentes a distribuição e às margens de erro de medição. As objetivos de nível de serviço não devem ser tão pequenos e precisos que sejam da mesma ordem de grandeza que a margem de erro de medição.

Reunião de Revisão de Nível de Serviço

Conduzir uma reunião regular de Revisão de Nível de Serviço é uma forma importante de entender o estado atual do serviço. A revisão frequente dos dados atingidos mantém o foco de trabalho nos mais importantes indicadores de negócio, bem como pode alertar com boa antecedência para eventuais desvios aos objetivos dos SLAs.

Após a documentação e formalização do serviço do SAJ com mapa de serviço, SLAs, OLAs, e a tecnologia totalmente revisada e corretamente configurada, a manutenção dos níveis de serviço requerem criação de:

• Procedimentos operacionais para todos os componentes do serviço, a fim de garantir que todas as engrenagens estão funcionando corretamente, e de suporte, a fim de garantir que o atendimento ao usuário está sendo feito conforme o acordado no SLA;
• Disciplina e comprometimento do time a fim de colocarem em prática uma reunião de Revisão de Nível de Serviço com frequência mínima quinzenal.

Fonte: Ronaldo Smith Jr

Perda de dados custa às empresas brasileiras US$ 26 bilhões em 12 meses

L&A Soluções – Consultoria em Banco de Dados SQL Server ( Suas informações em boas mãos! )

Companhias tiveram 17 horas de tempo de inatividade inesperado no período, o que acarretou consequências perda de receita e atrasos no desenvolvimento de produtos

A perda de dados e tempo de inatividade custou aproximadamente US$ 26 bilhões às empresas brasileiras no último ano. Mundialmente, o montante foi de US$ 1,7 trilhão. É o que apontou um estudo encomendado pela EMC, que indica que 62% dos profissionais de TI do Brasil não confiam integralmente em sua capacidade de recuperar informações após um incidente.

Além disso, 61% das organizações não têm plano de recuperação de desastres para cargas de trabalho emergentes; e apenas 4% têm planos para big data, nuvem híbrida e dispositivos móveis. De acordo com o levantamento, “nenhuma das organizações do Brasil são ‘Líderes’ em proteção de dados; 9% são ‘Adotantes’; 91% estão desatualizadas”, informa a fabricante.

Apesar de o número de incidentes estar em queda, o volume de dados perdidos por incidente cresce exponencialmente. De acordo com o estudo, 59% das empresas pesquisadas passaram por perda de dados ou tempo de inatividade nos últimos 12 meses.

Na média, as empresas tiveram 17 horas (mais de dois dias de trabalho) de tempo de inatividade inesperado no período, o que acarretou consequências perda de receita e atrasos no desenvolvimento de produtos.

Segundo a pesquisa, empresas com três ou mais fornecedores perderam quase cinco vezes mais dados em comparação com as que têm estratégia de um só fornecedor.

“As empresas com três fornecedores também tenderam a gastar, em média, US$ 15 milhões a mais na infraestrutura de proteção de dados, em comparação com as que têm apenas um”, informa o relatório.

O EMC Global Data Protection Index, realizado pela Vanson Bourne, pesquisou 3,3 mil responsáveis por decisões de TI de médias a grandes empresas em 24 países entre agosto e setembro de 2014.

Fonte: Site Computerworld

O Plano B

Fonte e direitos: RENATO CESAR MONTEIRO

Todos nós recordamos daquele trágico dia 11 de setembro de 2001 – o dia em que as torres gêmeas de Nova York vieram abaixo pelas mãos dos terroristas que jogaram nelas dois aviões Boeing 767 que haviam sido sequestrados. Sem dúvida uma das maiores tragédias da história moderna. A partir dali, tudo mudou nos Estados Unidos: as leis de imigração ficaram mais rígidas, o controle sobre o tráfego aéreo aumentou,foi deflagrada uma verdadeira guerra contra o terrorismo que, mui tas vezes, passou por cima dos direitos humanos. Foram ordenadas execuções sumárias, mui tas vezes sem provas criminais e contrariando as leis internacionais. Mas a partir daquele dia também mudou a história da Tecnologia da Informação.

Todos sabemos que o armazenamento de informações e documentos são fundamentais para a continuidade de qualquer negócio. Os meios de armazenamento atuais incluem, quase que na maioria das empresas, backup em fitas magnéticas, em servidores remotos ou sites de backup (existem os modelos co-location, que nada mais são do que data centers independentes que oferecem hospedagem compartilhada para mais de uma organização). As boas práticas sugeridas pela ITIL (Information Technology Infrastructure Library, modelo britânico utilizado em muitas empresas, cito, por exemplo, a Gerdau e a Stefanini IT Solutions) recomendam que as mídias de backup de cada empresa sejam armazenadas em local seguro e nunca no mesmo prédio-sede. Em caso de destruição total do patrimônio físico de uma empresa (o que pode ser recuperado através de seguro) , estes arquivos poderão ser restaurados.

Naturalmente, o monitoramento destes backups através do uso de software apropriado, bem como a análise de logs e testes de restore periódicos também são recomendáveis. Acontece que muitas empresas que operavam nas torres gêmeas de NY possuíam seus backups na torre vizinha. Isso mesmo: fitas de backup, servidores de backup e links de contingência ficavam no outro prédio. Ninguém imaginava que as duas torres desabariam. Ali, caro leitor, muitas empresas vieram à falência por não terem mais o histórico de seus clientes ou simplesmente por não poderem comprovar dívidas e créditos: todo o histórico digital estava perdido!

Desde então a grande maioria dos bons profissionais de Tecnologia da Informação vêm buscando especializar-se e implementar em suas empresas as práticas de continuidade de negócio mais modernas, atualizadas a partir daquela tragédia. Isso não se restringe ao armazenamento de dados, mas tem sido levado em conta, também, o capital intelectual. Não me surpreende o fato dos dois diretores de uma famosa empresa de consultoria e treinamento aqui de Porto Alegre viajarem periodicamente em voos diferentes. Eles sabem que detém grande conhecimento sobre a sua empresa e que o falecimento de ambos seria extremamente prejudicial para a continuidade do negócio. Logo, se acontecer a queda de um dos aviões, viria a falecer somente um dos diretores… Parece loucura, mas muitas empresas adotam esta prática. Apenas não admitem publicamente. Se refletirmos um pouco chegaremos a uma conclusão semelhante no que diz respeito ao conhecimento, à patente do software. O monopólio da informação, o não compartilhamento do código pode gerar a perda irreversível de grandes ideias. Quantos grandes softwares foram descontinuados simplesmente porque o código-fonte não foi aberto e, assim, não foi dada a continuidade por parte de outros desenvolvedores?

O “plano B”, caro leitor, resume-se a uma única palavra: continuidade. Isso pode ser implementado a partir de um simples nobreak até um si te em co-location.
Cabe aos profissionais de Tecnologia, ir além e nos anteciparmos aos imprevistos

Vejam também:
Missão Crítica: conceitos básicos

Banco de dados corrompido (Análise)

Esta é uma área que gosto muito, apesar que não gostaria de passar por uma situação desta em produção… hehehe

Encontrei este Post no Blog do Erickson Ricci, segue abaixo conforme o autor escreveu (todo o mérito é do autor, que esta de parabéns pelo excelente material)…
Neste post farei a análise de um banco de dados corrompido. O banco de dados corrompido que irei utilizar foi disponibilizado num grupo de estudos para a certificação MCM no qual estou participando. O grupo foi iniciado pelo MVP Jason Strate ( blog | @StrateSQL ) e quem quiser mais informações pode acessar este post dele: http://www.jasonstrate.com/2011/12/sql-mcm-study-group/.

Vocês poderão baixar o banco de dados corrompido aqui.

Vamos começar a análise então. Antes de mais nada, precisamos deixar nosso banco de dados disponível em nossa instância. A maneira mais simples de fazer isto é anexar (attach) a base, seja pela interface gráfica ou via comando, desta forma:

CREATE DATABASE [CorruptDB1] ON
( FILENAME = N'C:\temp\CorruptDBs\CorruptDB1\DBFiles\CorruptDB1.mdf' ),
( FILENAME = N'C:\temp\CorruptDBs\CorruptDB1\DBFiles\CorruptDB1_log.ldf' )
FOR ATTACH;
GO

Substitua o caminho “C:\temp\CorruptDBs\…” para o local onde você escolher descompactar os arquivos.

Uma vez que o banco de dados estiver anexado, vamos rodar um DBCC CHECKDB para ver qual o estado do nosso banco.

DBCC CHECKDB(CorruptDB1)
WITH ALL_ERRORMSGS, NO_INFOMSGS

Foi utilizado as opções ALL_ERRORMSGS e NO_INFOMSGS para exibir como resultado somente mensagens de erro e ignorar mensagens informativas. Se desejar mais informações sobre o comando DBCC CHECKDB, clique aqui. O resultado que temos é o seguinte:

Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 99, index ID 0, partition ID 0, alloc unit ID 6488064 (type System allocation data),
page (1:7). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12716041 and -4.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘(Object ID 99)’ (object ID 99).
CHECKDB found 1 allocation errors and 0 consistency errors in database ‘CorruptDB1′.

Há algo errado com nosso banco de dados. E agora, que ação devemos tomar?

O comando CHECKDB possui duas opções chamadas REPAIR_ALLOW_DATA_LOSS e REPAIR_REBUILD. A primeira impressão é “…ótimo, o DBCC CHECKDB vai resolver meu problema de corrupção!”.

A primeira opção “tenta” reparar o problema de corrupção e pode ocasionar perda de dados. Já a segunda opção “tenta” executar reparos que não possibilitem perda de dados. Como não queremos perder nenhum dado da base, vamos executar a segunda opção primeiro. Vou alterar o acesso do banco de dados para SINGLE_USER e vou executar estas opções.

ALTER DATABASE CorruptDB1 SET SINGLE_USER
WITH ROLLBACK IMMEDIATE;
GO

DBCC CHECKDB(CorruptDB1, REPAIR_REBUILD)
WITH ALL_ERRORMSGS, NO_INFOMSGS

E temos o seguinte resultado:

Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 99, index ID 0, partition ID 0, alloc unit ID 6488064 (type System allocation data), page (1:7). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.
The repair level on the DBCC statement caused this repair to be bypassed.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘(Object ID 99)’ (object ID 99).
CHECKDB found 1 allocation errors and 0 consistency errors in database ‘CorruptDB1′.

Hummm… Nada resolvido. Ainda tivemos o erro 8939. Vamos forçar a barra e tentar o reparo com possível perda de dados.

DBCC CHECKDB(CorruptDB1, REPAIR_ALLOW_DATA_LOSS)
WITH ALL_ERRORMSGS, NO_INFOMSGS

E o resultado:

Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 99, index ID 0, partition ID 0, alloc unit ID 6488064 (type System allocation data), page (1:7). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.
The repair level on the DBCC statement caused this repair to be bypassed.
CHECKDB found 1 allocation errors and 0 consistency errors in table ‘(Object ID 99)’ (object ID 99).
CHECKDB found 1 allocation errors and 0 consistency errors in database ‘CorruptDB1′.

 

Novamente, nada feito. Pelo nível de corrupção do banco de dados, o comando DBCC CHECKDB não consegue reparar este problema. Vamos ter que fazer uma análise um pouco mais profunda e por a mão na massa para resolver o problema.

Nós vamos encontrar a explicação deste erro aqui. Em linhas gerais, ele nos informa que foi realizada uma validação numa determinada página, e esta validação falhou por uma corrupção no cabeçalho (Header) da página. Interessante não?!

Analisando a mensagem completa de erro que nos foi dada, podemos observar que ela nos informa qual é a página que está com problema: “…page (1:7). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. …”. Fica a dica: LEIA TODA A MENSAGEM DE ERRO!!! Achei que isto deveria ficar em destaque pois é muito comum ver as pessoas sem saber o que fazer e a mensagem de erro te dá dicas valiosas sobre o que aconteceu. Nem sempre é assim, mas na maioria das vezes é válido. Vamos dar uma olhada nesta página:

DBCC TRACEON(3604)
GO
DBCC PAGE('CorruptDB1', 1, 7, 3)

Quer saber mais sobre o Trace Flag 3604 e sobre o comando DBCC PAGE, acesse aqui e aqui.
O resultado completo que temos é o seguinte:

DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Msg 8939, Level 16, State 98, Line 1
Table error: Object ID 99, index ID 0, partition ID 0, alloc unit ID 6488064 (type System allocation data), page (1:7). Test (IS_OFF (BUF_IOERR, pBUF->bstat)) failed. Values are 12584969 and -4.PAGE: (1:7)BUFFER:BUF @0x000000008EFA8F40bpage = 0x000000008E17E000           bhash = 0×0000000000000000           bpageno = (1:7)
bdbid = 17                           breferences = 0                      bcputicks = 0
bsampleCount = 0                     bUse1 = 50557                        bstat = 0xc00809
blog = 0×21212159                    bnext = 0×0000000000000000PAGE HEADER:Page @0x000000008E17E000m_pageId = (1:7)                     m_headerVersion = 0                  m_type = 0
m_typeFlagBits = 0×0                 m_level = 0                          m_flagBits = 0×200
m_objId (AllocUnitId.idObj) = 99     m_indexId (AllocUnitId.idInd) = 0    Metadata: AllocUnitId = 6488064
Metadata: PartitionId = 0            Metadata: IndexId = 0                Metadata: ObjectId = 99
m_prevPage = (0:0)                   m_nextPage = (0:0)                   pminlen = 90
m_slotCnt = 2                        m_freeCnt = 6                        m_freeData = 8182
m_reservedCnt = 0                    m_lsn = (0:0:1)                      m_xactReserved = 0
m_xdesId = (0:0)                     m_ghostRecCnt = 0                    m_tornBits = 105713478Allocation StatusGAM (1:2) = ALLOCATED                SGAM (1:3) = NOT ALLOCATED           PFS (1:1) = 0×44 ALLOCATED 100_PCT_FULL
DIFF (1:6) = CHANGED                 ML (1:7) = NOT MIN_LOGGED
Msg 2514, Level 16, State 5, Line 1

A DBCC PAGE error has occurred: Invalid page type – dump style 3 not possible.

Obviamente houve erros no resultado. Mas o que chama a atenção são os pontos que destaquei em negrito. Se dermos uma olhada no Internals (um modo “carinhoso” de chamar o livro Microsoft SQL Server 2008 Internals), veremos no capítulo 3, página 147, parágrafo 2 ( :-O Não, eu não decorei isto, fui ver no livro… ^.^ ) as explicações sobre as páginas de alocação de dados, em resumo, assim:

• Page 0 – File Header
• Page 1 – PFS Page Free Space
• Page 2 – GAM Global Allocation Map
• Page 3 – SGAM Shared Global Allocation Map
• Page 4 e Page 5 – não são utilizadas
• Page 6 – DCM Differential Changed Map
• Page 7 – BCM Bulk Changed Map

Isto nos leva à conclusão de que a página que temos corrompida neste banco de dados é a página BCM, Bulk Changed Map. Não vou entrar neste momento no detalhe das páginas de controle, ficando apenas por dizer que é uma das páginas de controle de alocação de dados do SQL Server.

Ótimo! Agora sabemos o que fazer. Podemos então fazer o restore desta página e tudo resolvido. Será?!
Vamos tentar.

USE MASTER;
GO

RESTORE DATABASE CorruptDB1
   PAGE = '1:7'
FROM DISK = 'C:\temp\CorruptDBs\CorruptDB1\Bak\CorruptDB1.bak'
WITH RECOVERY

Vamos utilizar o comando RESTORE para restaurar somente a nossa página corompida. O resultado que temos é:

Msg 3111, Level 16, State 1, Line 2
Page (1:7) is a control page which cannot be restored in isolation. To repair this page, the entire file must be restored.
Msg 3013, Level 16, State 1, Line 2
RESTORE DATABASE is terminating abnormally.

 

Ops! O SQL Server não nos permite restaurar isoladamente páginas de controle… E nos informa que para resolução do problema temos de restaurar o arquivo completo.

Solução para o problema e evitar perda de dados. Faça um backup de log (Tail Log Backups) e aplica um restore do banco de dados e depois aplique os logs na sequência, se houver, e por último aplique o último backup de log gerado (tail log). Depois de seguir estes passos, execute novamente o comando DBCC CHECKDB para ter certeza de que seu problema foi resolvido.

Esta foi a solução que foi encontrada para este problema de corrupção.

---

Veja também:

Integridade do Banco de Dados

Possible Index Corruption. Diagnosticando o problema

Corruption demo databases and scripts

Corrigindo Erro de Suspect Database (novo)

Corrompendo um Banco SQL (novo)

Corrupção de Dados direto das trincheiras (novo)

Ver páginas corrompidas (SQL Server)

Verificação de Página e Restore de Bases no SQL Server

Recriando as databases de sistema

Automatizando a verificação de integridade de seus bancos de dados

Como Restaurar o Master, Model e MSDB

Entendendo e Melhorando seus backups (SQL Server)

Restaurando um Database Suspect – SQL Server

Databases em modo Suspect e Pendente Recovery

Creating, detaching, re-attaching, and fixing a SUSPECT database

Recriando as databases de sistema (SQL Server 2017 / 2005)

Recriar bancos de dados do sistema (SQL Server 2017)

Pode ocorrer situações que precisamos recriar as databases de sistema, tais como:
– arquivo master corrompido e sem backup.
– alteração do collation da instancia

Implicações:
– todos os bancos de dados deverão ser restaurados ou atachados.
– logins terão que ser recriados
– jobs (msdb)
– planos de manutenção (msdb)

Como fazer no SQL Server 2005:
Executar os instaladores do SQL Server, no meu caso os instaladores se encontra em: D:\Servers\setup.exe

Exemplo:
C:\> start /wait D:\Servers\setup.exe /qb INSTANCENAME=SQL2005 REINSTALL=SQL_Engine REBUILDDATABASE=1 SAPWD=12345

Onde:
/qb – De forma Visual
SAPWD – Alterar a senha do sa

Dica:
– Sempre faça backup dos seguintes bancos de dados do sistema:
– master
– msdb (jobs, planos de manutenção)

• Vejam também:
  • Alterando o Local do TempDb
  • Reconstruindo o MSDB em caso de corrupção
  • Como Restaurar o Master, Model e MSDB

{ Alex Souza }