Tabelas no banco de dados "mestre" do SQL Server, elas causarão problemas?

3

Gente, por favor, seja gentil comigo ... Eu sou apenas um DBA 'acidental' devido ao nosso DBA demitido, então eu sou totalmente novato no DBA ...

Veja, eu tenho este aplicativo, "ESET Remote Administration Server" (ERAS) que armazena seus logs e análises em (originalmente) um banco de dados Access local.

A decisão foi migrar seu banco de dados para uma máquina do SQL Server 2008 R2.

A ESET (fabricante do software) forneceu ferramentas úteis para realizar essa migração; infelizmente, sendo o neófito do DBA que sou, não percebi que primeiro tenho que criar meu próprio banco de dados (no lado do SQL Server) e atribuir esse banco de dados como o banco de dados 'padrão' para a conexão ODBC do ERAS.

Agora, a ferramenta de migração criou com sucesso várias tabelas dentro do banco de dados "principal".

Minhas perguntas:

Should I leave things be as it is, or should I re-migrate the ERAS database to a different database?

Se você me sugerir executar uma reimigração, meu plano é (1) criar uma nova instância, (2) criar um novo banco de dados na nova instância, (3) criar um novo DSN do Sistema ODBC no servidor ERAS apontando para o novo banco de dados na etapa 2, (4) use a ferramenta de migração da ESET para migrar do DSN atual para o novo DSN.

Você acha que eu perdi um passo lá?

Obrigado antecipadamente por qualquer orientação.

    
por pepoluan 28.06.2013 / 11:42

1 resposta

3

Eu recomendaria fazer a mudança para um banco de dados dedicado. Aqui estão algumas razões:

  • Se você quiser migrar esse banco de dados para uma instância diferente do SQL Server, precisará fazer isso de qualquer maneira. Você não pode migrar o mestre.
  • O banco de dados mestre não é destinado a dados do usuário. Ele deve ser o ponto central para dados e códigos necessários para manter a instância funcional. Adicionando coisas no mestre enlamear as águas lá.
  • Adicionar coisas ao mestre requer a alteração desnecessária da segurança no mestre.

Estes podem não ser grandes problemas para você na sua situação, mas eu sempre defendo as práticas recomendadas, a menos que exista um sólido caso de negócio para fazer o contrário.

Com relação ao seu plano de reimigração, não vejo que você precise criar uma nova instância do SQL Server. Você deve estar bem apenas com a criação de um novo banco de dados para o ERAS e refazer a migração. Então você pode limpar o mestre dos objetos que o ERAS criou nele. Na sua conexão ODBC, você especifica qual banco de dados a conexão deve usar, portanto, você deve poder alterá-la bem para apontar para o novo banco de dados.

Então, aqui estão os passos que eu sugeriria:

  • Crie seu novo banco de dados (chame-o de ERAS ou qualquer outro)
  • Crie um novo login do SQL (no nível do servidor) se ainda não tiver feito
  • Adicione o novo login do SQL como usuário em seu novo banco de dados (provavelmente como membro da função dbo)
  • Altere sua conexão ODBC para apontar para o novo banco de dados (e para usar as novas credenciais de login que você acabou de criar, se necessário)
  • Execute as etapas de migração, que agora devem criar todos os objetos e dados de esquema necessários em seu novo banco de dados
  • Limpar mestre. Aqui é melhor você remover manualmente os objetos ERAS em vez de restaurar a partir de um backup. Restaurar o mestre não é uma tarefa trivial e, se algo der errado, poderá inutilizar toda a sua instância do SQL Server
  • Lucro!
por 28.06.2013 / 14:45