2009-05-07 5 views
3

Dans SQL 2005, quelles sont les choses que vous devriez pas faire une base de données qui a permis Log Shipping (et qui fonctionne sous le modèle de récupération complète)? Je suppose que la planification de sauvegardes supplémentaires du journal des transactions vers un emplacement différent entraînera la rupture de l'envoi des journaux (car la chaîne de journalisation complète n'atteint plus le serveur secondaire).Restrictions sur une base de données des journaux de transaction

Je comprends également que Truncate Table est OK avec l'envoi de journaux (depuis Sql 2000).

Y a-t-il d'autres activités/commandes à éviter?

éditer: par exemple, est-ce que la base de données est rétractable ou est-ce que le rétrécissement est correct?

Répondre

6

Vous avez raison. Vous ne devez pas définir d'autres sauvegardes de journaux de transactions en dehors de la configuration de l'envoi de journaux, afin de garantir la maintenance de la séquence de journaux naturelle. Cependant, si vous souhaitez effectuer une sauvegarde de journaux de transaction Ad-Hoc, par exemple parce que vous effectuez une maintenance en direct sur la base de données de production, vous pouvez appeler le travail SQL Server utilisé par Log Shipping pour effectuer votre transaction. sauvegardes de journal. Il est généralement appelé LS_Backup. Cela maintiendra le LSN. D'après ce que je comprends, aucune fonctionnalité opérationnelle de la base de données en cours d'expédition n'est limitée en utilisant cette technologie de disponibilité.

Certaines choses qui peuvent causer des complications:

chiffrement

Si vous êtes l'envoi de journaux à un autre serveur et utilisez le chiffrement natif SQL Server, vous ne serez pas en mesure d'accéder à des données cryptées dans le journal base de données fournie, sauf si SQL Server utilise la même clé principale de service.

Assemblées

Vous pouvez rencontrer des difficultés d'accès des assemblages signés dans un journal base de données expédiées, comme vous ne pouvez pas activer la propriété digne de confiance.

Permission

Si vous avez l'intention de fournir un accès en lecture à la base de données des journaux de transaction alors les logins SQL Server devront avoir le même SID que ceux du serveur source pour que les connexions à la carte automatiquement correctement .

Espérons que cela aide. À votre santé.

+0

+1 Une bonne idée sur les permissions! –

2

Les croissances/rétrécissements de base de données/journaux sont corrects, ils seront expédiés et la mise en veille augmentera/se rétractera également.La seule chose que je suis au courant de cela cassera les choses sont:

BACKUP LOG AVEC TRUNCATE_ONLY

Modification du mode de récupération

Prenant la base de données primaire hors ligne (pas sûr de celui-ci, jamais essayé)

Tout le reste est bon, mais faire des REINDEXES de masse peut faire de très gros logs qui sont difficiles à traiter avec une grande base de données.

+0

Eh bien vous avez raison, merci dieu truncate log n'est plus autorisé sur sql 2008. –

Questions connexes