Recursos para o DBA acidental [fechado]

Question

Na plataforma Microsoft, a maioria dos programas de nível corporativo (SharePoint, qualquer um dos aplicativos do System Center, qualquer um dos aplicativos do Dyamics, etc) é executada em cima do SQL Server. Para os administradores desses programas, o SQL Server geralmente é uma caixa preta instalada como um pré-requisito para qualquer programa que seja seu foco principal. Como resultado, há muito pouco planejamento (se houver algum) que vai para o lado SQL da instalação, levando a problemas que surgem em algum lugar mais a montante.

• Logs de transações que preenchem unidades
• Não há planos de manutenção (ou desinformados, como planos que reorganizem e reconstruam os índices)
• Autogrowth não gerenciado
• Bancos de dados e logs nos mesmos eixos
• Níveis de RAID mal escolhidos
• Sem backup (ou plano de recuperação)

Então ... que tipos de problemas "DBAs acidentais" tendem a atingir, e que recursos melhor ajudariam um administrador de banco de dados acidental a se familiarizar com os conceitos básicos de planejamento, administração e ajuste de desempenho do SQL?

    

Answer 1

Confira a série de artigos e Q & As colunas que escrevo para a TechNet Magazine - eles são principalmente escritos com o DBA Acidental (chamamos de 'involuntário') em mente.

Início Dicas para Manutenção Efetiva do Banco de Dados foram escritas especificamente como uma cartilha para DBAs involuntários entenderem os problemas de manutenção do banco de dados.

Entendendo o registro e a recuperação em SQL Server

Problemas e soluções comuns de segurança do SQL Server

Noções básicas sobre backups do SQL Server - parte 1 de uma série de 3 partes. A parte 2 estará usando a restauração (na edição de 09 de setembro) e a parte 3 estará recuperando sem backups (na edição de 09 de novembro)

Você também deve verificar o meu blog e blog da minha esposa (não é propaganda ou qualquer informação) - nós dois blogamos muito em vários níveis técnicos.

Uma boa série de postagens para examinar são os editoriais para os resultados de minhas pesquisas semanais . Eles geralmente estão em torno de um tópico amplo que ajudaria os DBAs involuntários. Os posts editoriais começam com "Importância de" ou "Importante". Na verdade, a pesquisa desta semana é sobre ser um DBA involuntário - muito oportuna!

Entendemos muito bem a coisa involuntária do DBA - na verdade, Kimberly e eu lecionamos alguns dias da classe Microsoft Certified Masters do SharePoint para que os administradores do SharePoint saibam o que fazer com seus SQL Servers (também ensinamos uma semana inteira SQL um).

Espero que isso seja útil para você.

    

Answer 2

Sean, eu entendo de onde você está vindo.

Estamos em um barco semelhante aqui, como seria de esperar muitos outros. Não resistindo à economia de hoje.

Apesar das reclamações repetidas à administração (incluindo a gerência sênior de negócios), nossa situação é a seguinte; O autodeclarado "DBA" (em separado, "equipe de desenvolvimento" em outro andar) infelizmente sabe menos do que um júnior empunhando dois livros da O'Reilly e um dump de impressão da KB. Ela conseguiu o emprego e é ótima em derramar mel no ouvido da pessoa que também derrama mel no ouvido do muco de muco mais alto.

Certamente, seria ideal poder aprender o "comércio" do DBA, mas de novo. O que queremos e o que podemos ter são coisas muito diferentes. :)

Eu, pessoalmente, enfrentei os seguintes problemas, que (para ecoar squillman é bastante brusco, mas não completamente incorreto) exigiu muito do googling.

• Tranlogs. Você está certo. O que diabos foram essas coisas? Então tivemos que restaurar um banco de dados e um servidor, o que significa 'reproduzir os logs de tran?', Exatamente? :)
• Espere, o que você quer dizer com esses bancos de dados ficarem maiores? Como os reduzimos? Ou pelo menos manter seu crescimento?
• Padronização de instalações em diferentes servidores, (esta imagem é para "dev", esta imagem é para "prod" e esta pequena imagem chorou todo o caminho para casa, do mercado.)
• Scripts de manutenção e como ajudar a gerenciar os bancos de dados por um longo período de tempo (como crescer plantas de casa e garantir que eles não se transformem em kudzu.)
• Sempre certificando-se, os proggies vão no C: \, o logging e / ou bancos de dados vão no D: \, que tipo de formulou nossa padronização, (C: \ é dois discos espelhados, D: \ é usualmente um caso RAID5.)
• Ter que comprar uma licença e um cliente SQL separados para backups.
• Confira os usuários de gerenciamento que a equipe de desenvolvimento atribui ao próprio banco de dados SQL, gerenciando funções de DBO, etc. Verifique se você tem um bom modelo de segurança quando se trata dos direitos do usuário no banco de dados.
• Pesquisa de uma conta de serviço de domínio com a qual os serviços SQL podem operar. Quais direitos essa conta de serviço precisa, se houver alguma.

(Você atingiu alguns bons, no seu post.)

Como você está operando com handicap como alguns outros, certifique-se de espalhar o conhecimento de SQL entre a equipe, se puder. Compartilhe o que você sabe, ensine aos outros o mesmo. Seja amigável. É uma dor real ter que usar o chapéu de SQL, mas pelo menos muitos olhos e processos de pensamento são melhores que um único.

No entanto, acima de tudo, tente como o diabo para obter um DBA na equipe. :)

    

Answer 3

Eu tenho o título DBA cara cerca de um ano no meu trabalho. Isso foi há cerca de 5 meses. Desde então, tenho lido vários blogs da vista de 500.000 pés para o (às vezes, batendo no deck rígido a 500 pés) 250.000 visualizações , para a visualização de 500 pés . Além disso, SQLServerPedia é seu amigo; eles têm muita coisa boa para o DBA acidental.

Eu fui jogado em situações que me deixaram desconfortável. Por exemplo, tenho feito backups desde que eu “recebi” esse trabalho para que Fulls, diffs e t-logs estivessem disponíveis para minha primeira restauração de dados de produção, ninguém mais parecia pânico, então imaginei que não poderia mostrar Quão enjoado eu me senti. Mais vezes do que não, eu exagero quando coloco meu chapéu de DBA, mas eu acho que não é meu trabalho em tempo integral (administrador de rede), então eu deveria estar 'melhor prevenir do que remediar'.

    

Answer 4

Dicas importantes para manutenção efetiva do banco de dados

    

Answer 5

Comece com os esforços táticos. Se o seu banco de dados está falhando ou não está funcionando bem, concentre-se em resolver esses problemas.

Próximo começo com itens mais estratégicos: backup e restaurações. Saiba como restaurar seus bancos de dados dentro e fora e crie procedimentos detalhados para evitar erros dispendiosos durante uma interrupção de produção.

Se você não tem hardware para testar alterações importantes e coisas como backup / restauração - descubra como obtê-lo.

    

Answer 6

Quando contratei um DBA júnior, comprei o Companion do administrador do Microsoft® SQL Server ™ 2005. É o livro que eu gostaria de ter quando estava começando.