Oracle a des commandes SQL que l'on peut exécuter afin qu'une transaction ne soit pas enregistrée. Y a-t-il quelque chose de similaire pour SQL Server 2008?
Mon scénario : Nous avons besoin de journaux Tx sur les serveurs (Dev, QA, Prod), mais peut-être pouvons-nous nous en passer sur les machines des développeurs.
Vous ne pouvez pas vous passer des journaux de transactions dans SQL Server, en aucune circonstance. Le moteur ne fonctionnera tout simplement pas.
Vous POUVEZ définir votre modèle de récupération sur SIMPLE sur vos machines de développement - cela empêchera le gonflement du journal des transactions lorsque les sauvegardes du journal des transactions ne sont pas effectuées.
ALTER DATABASE MyDB SET RECOVERY SIMPLE;
SQL Server nécessite un journal des transactions pour fonctionner.
Cela dit, il existe deux modes de fonctionnement pour le journal des transactions :
En mode Complet, le journal des transactions continue de croître jusqu'à ce que vous sauvegardiez la base de données. En mode Simple : l'espace dans le journal des transactions est 'recyclé' à chaque Point de contrôle.
Très peu de gens ont besoin de faire fonctionner leurs bases de données en mode de récupération Complète. Le seul intérêt d'utiliser le mode Complet est si vous souhaitez sauvegarder la base de données plusieurs fois par jour et que la sauvegarde de la base de données entière prend trop de temps - donc vous sauvegardez uniquement le journal des transactions.
Le journal des transactions continue de croître toute la journée, et vous continuez à sauvegarder juste ce dernier. Cette nuit-là, vous réalisez votre sauvegarde complète, et SQL Server tronque ensuite le journal des transactions, commence à réutiliser l'espace alloué dans le fichier du journal des transactions.
Si vous ne réalisez que des sauvegardes complètes de la base de données, vous ne voulez pas utiliser le mode de récupération Complet.
Il existe un troisième mode de récupération non mentionné ci-dessus. Le mode de récupération détermine finalement la taille des fichiers LDF et la fréquence à laquelle ils sont écrits. Dans les cas où vous allez effectuer des insertions en bloc, vous devez définir la base de données en mode "BULK/LOGGED". Cela permet aux insertions en bloc de se déplacer rapidement et peut être modifié à la volée.
Pour ce faire,
USE master ;
ALTER DATABASE model SET RECOVERY BULK_LOGGED ;Pour le changer :
USE master ;
ALTER DATABASE model SET RECOVERY FULL ;Dans l'esprit d'ajouter à la conversation sur les raisons pour lesquelles quelqu'un ne voudrait pas d'un LDF, j'ajoute ceci : Nous faisons de la modélisation multidimensionnelle. Essentiellement, nous utilisons la base de données comme un grand stock de variables qui sont traitées en bloc à l'aide de programmes externes. Nous n'avons JAMAIS besoin de rollbacks. Si nous pouvions obtenir un gain de performance en désactivant TOUTE la journalisation, nous le ferions en un clin d'œil.
Quel est votre problème avec les journaux Tx? Ils augmentent? Alors il suffit de définir l'option de troncature sur checkpoint.
D'après la documentation de Microsoft:
Dans SQL Server 2000 ou dans SQL Server 2005, le modèle de récupération "Simple" est équivalent à "tronquer le journal à chaque checkpoint" dans les anciennes versions de SQL Server. Si le journal des transactions est tronqué à chaque fois qu'un checkpoint est exécuté sur le serveur, cela empêche son utilisation pour la récupération de la base de données. Vous ne pouvez utiliser que des sauvegardes complètes de la base de données pour restaurer vos données. Les sauvegardes du journal des transactions sont désactivées lorsque le modèle de récupération "Simple" est utilisé.
J'ai en fait rencontré une situation dans laquelle le fait de ne pas écrire dans les journaux de transactions a tout son sens.
J'ai quelques tables que j'utilise pour indexer des données. Les données dans les tables sont entièrement des données calculées et doivent être mises à jour périodiquement avec les dernières informations. Elles ont une sorte de nature de jointure croisée et peuvent parfois devenir très grandes. Elles n'ont pas besoin d'être sauvegardées, car elles peuvent être recalculées à partir des autres tables à tout moment. Cependant, le recalcul remplit rapidement les journaux de transactions et je sens que les calculs pourraient aller plus vite si la base de données n'essayait pas de tenir compte du journal. Je peux sauvegarder les journaux pour les maintenir petits, mais je finis quand même par sauvegarder d'énormes quantités de données qui pourraient être déduites d'autres données.
En écrivant ceci, je me souviens que plusieurs fichiers de données peuvent être utilisés pour une seule base de données. Je vais voir si je peux placer les tables calculées dans un fichier différent qui est sauvegardé séparément et éliminé plus fréquemment.
Cela me serait encore utile, cependant, si MS fournissait un moyen d'indiquer que certaines tables ne doivent pas être journalisées. Si quelqu'un sait que c'est possible, veuillez décrire cela.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
