none
Manutenção de Base de Dados e Contas de Usuário RRS feed

  • Pergunta

  •  

    Uma vez por semana faço a reindexação dos DBs, reorganizo os indices, backup do transac, backup full do DB e por  ultimo um shrink. Este shrink pelo que vi, é só da BASE né? O shrink do transaction tenho que fazer na mão ou via t-sql, colocando um job. Só não sei a periodicidade "ideal" para esta manutenção, visto que tenho uma base de 400MB (SISTEMA LOCAL DA EMPRESA) e 3 de 85GB (SAP).

     

    Também configuro um limite para o arquivo de transac-log, senao "engorda" muito. Está na faixa de 20-25% do tamanho total do banco. Se eu colocar um arquivo de log muito pequeno, o que ocorre quando chega no limite? Ele começa a sobrescrever o arquivo, substituindo as transações mais antigas???

     

     

    Tenho dois servidores SQL, um para produção e outro para testes. Os usuários cadastrados (para string de conexão, essas coisas) são iguais e com a mesma senha. Mas, se eu restaurar uma base de um SQL para o outro, tenho que remover os usuários da guia de segurança do banco restaurado e colocá-los novamente. Acredito que isto ocorra em virtude do SID. Mesmo que os usuários tenham o mesmo nome e senha, no fundo são diferentes.

     

    Os usuários são do SQL e não do Windows. A autenticação é mista pois acesso o SQL como SA ou como Admin Local do servidor. O acesso aos bancos são feitos pelos usuários do SQL mesmo.

     

     

    Até.

    domingo, 14 de setembro de 2008 14:24

Respostas

  • Olá Hélio,

     

    Se você "dropa" o usuário automaticamente são perdidas as permissões. Mesmo que você possa reinserí-lo, as permissões foram perdidas e dependendo do banco isso não é algo muito administrável (imagine 5 usuários diferentes com mais de 1.000 permissões em tabelas específicas ?)

     

    Não é preciso montar um script e nem reinserí-lo. Há uma procedure que atualiza o SID do usuário para refletir o SID do login desejado. Execute o código abaixo:

     

    exec sp_change_users_login 'Update_One', 'Usuario', 'Login'

     

    Acredito que essa SP resolva seus problemas da maneira prática que você estava procurando.

     

    [ ]s,

     

    Gustavo

    segunda-feira, 15 de setembro de 2008 18:50

Todas as Respostas

  • Hélio,

     

    O seu problema esta sendo em restaurar o banco de dados, e já existir os usuários cadastrados?

     

    segunda-feira, 15 de setembro de 2008 12:24
    Moderador
  • Não pois eu "dropo" os usuários do banco restaurado e o insiro novamente. O que queria era uma maneira mais prática para não ter que fazer isso, mas acredito que não exista. A não ser que utilizasse autenticação do Windows, agregada ao meu domínio. Acontece que não fiz isso pois os servidores estão em uma DMZ, isolada da rede interna.

     

    Abraço!

    segunda-feira, 15 de setembro de 2008 12:46
  • Helio,

     

    Aqui na empresa eu também tenho este tipo de problema com algumas bases da RM, desenvolvi um script especifico para realizar este tipo de procedimento!!!!

    segunda-feira, 15 de setembro de 2008 12:58
    Moderador
  • Pois é. Mesmo que o usuário do SQL seja o mesmo, o SID é diferente. Não tem jeito, só dropando e reinserindo.

     

    Achei que houvesse uma maneira mais prática para isso!

     

     

    Abraço!

    segunda-feira, 15 de setembro de 2008 13:20
  • Olá Hélio,

     

    Se você "dropa" o usuário automaticamente são perdidas as permissões. Mesmo que você possa reinserí-lo, as permissões foram perdidas e dependendo do banco isso não é algo muito administrável (imagine 5 usuários diferentes com mais de 1.000 permissões em tabelas específicas ?)

     

    Não é preciso montar um script e nem reinserí-lo. Há uma procedure que atualiza o SID do usuário para refletir o SID do login desejado. Execute o código abaixo:

     

    exec sp_change_users_login 'Update_One', 'Usuario', 'Login'

     

    Acredito que essa SP resolva seus problemas da maneira prática que você estava procurando.

     

    [ ]s,

     

    Gustavo

    segunda-feira, 15 de setembro de 2008 18:50