Taille transaction log et reconstruction index

Citation:

---

Envoyé par mikedavem

Non l'instruction est écrite dans le journal. C'est un mode mimimal. Mais ce mode est intéressant surtout pour les chargements en bloc de données tout comme NOLOGGING.
C'est le CHECKPOINT de SQL Server qui permet de tronquer les données du journal lorsque celles-ci ne servent plus à SQL Server pour le mode de récupération SIMPLE. La fréquence d'exécution dépend principalement de l'option de serveur recovery interval
++

---

Bien,
Donc il n'existe pas sous SQL Server une option qui permet à un moment donné de dire à SQL Server de ne rien écrire dans le JT.
à mon avis l'implémentation de l'option NOLOGGING sous SQL SERVER va permettre aux Développeurs/Adminstrateurs de mieux contrôler le grossissement du JT lors certaines opérations comme :
--> la maintenance des index
--> la mise à jour massive de données,
--> l'insertion des traces dans des fichiers/tables de traces
--> ...

David, qu'est ce que tu en penses ?

Citation:

---

Donc il n'existe pas sous SQL Server une option qui permet à un moment donné de dire à SQL Server de ne rien écrire dans le JT.
à mon avis l'implémentation de l'option NOLOGGING sous SQL SERVER va permettre aux Développeurs/Adminstrateurs de mieux contrôler le grossissement du JT lors certaines opérations comme :
--> la maintenance des index
--> la mise à jour massive de données,
--> l'insertion des traces dans des fichiers/tables de traces
--> ...

---

Je suis assez mitigé sur cette idée. Tu parles de contrôle mais je ne crois pas que ce soit vraiment le cas. Ne pas écrire dans le journal c'est la porte ouverte à la perte de données hasardeuse.

Que va-t-il se passer si une reconstruction d'index ou un chargement en masse est en cours et qu'un problème survient ? Je perds mes données ? Je me retrouve dans un état qui n'est pas intègre ?

D'ailleurs sur Oracle on précise bien que cette option est dangeureuse car comme elle n'écrit rien dans le REDO LOG une perte de données est tout à fait possible. D'ailleurs il y a toujours un backup avant ce genre d'opération.

++

--

Citation:

---

Envoyé par zinzineti

Bien,
Donc il n'existe pas sous SQL Server une option qui permet à un moment donné de dire à SQL Server de ne rien écrire dans le JT.
à mon avis l'implémentation de l'option NOLOGGING sous SQL SERVER va permettre aux Développeurs/Adminstrateurs de mieux contrôler le grossissement du JT lors certaines opérations comme :
--> la maintenance des index
--> la mise à jour massive de données,
--> l'insertion des traces dans des fichiers/tables de traces
--> ...

---

- On ne peux pas ne pas journaliser, c'est un des fondements de la cohérence transactionnelle. Sans journal, pas de cohérence transactionnelle.
- Le mode BULK_LOGGED sert à minimiser l'impact sur le journal et accélérer ces traitements. Mais il ne casse pas la cohérence transactionnelle, contrairement au NOLOGGING.

Citation:

---

Envoyé par mikedavem

Je suis assez mitigé sur cette idée. Tu parles de contrôle mais je ne crois pas que ce soit vraiment le cas. Ne pas écrire dans le journal c'est la porte ouverte à la perte de données hasardeuse.

Que va-t-il se passer si une reconstruction d'index ou un chargement en masse est en cours et qu'un problème survient ? Je perds mes données ? Je me retrouve dans un état qui n'est pas intègre ?

D'ailleurs sur Oracle on précise bien que cette option est dangeureuse car comme elle n'écrit rien dans le REDO LOG une perte de données est tout à fait possible. D'ailleurs il y a toujours un backup full avant ce genre d'opération.
++
--

---

Je ne suis pas convaincu. Par exemple lorsqu'une base est en mode SIMPLE => Il est impossible de faire de BACKUP LOG => mais ceci n'empêche pas de faire des opérations de maintenance et de modifications massives de données !? Si en plus je peux avoir une option NOLOGGING qui me permet :

1. Réduire la taille des fichiers JT
2. Diminuer la durée d'exécutions des instructions
Ce serait génial ! :D
Oui c'est comme tout dans la vie ! le couteau qui sert à couper le pain peut également couper le doigt si on ne fait pas attention ! mais on est quand même content d'avoir un couteau quand on est à table (les indiens et les africains peuvent s'en passer de couteau à table, les doigts de la main et les dents font l'affaire parfaitement ... je confirme :D )

Justement les modes BULK LOGGED et SIMPLE ne journalisent pas la création des index. Seule l'ordre CREATE INDEX est journalisé, pas les entrées de l'index.

A +

Citation:

---

Je ne suis pas convaincu. Par exemple lorsqu'une base est en mode SIMPLE => Il est impossible de faire de BACKUP LOG => mais ceci n'empêche pas de faire des opérations de maintenance et de modifications massives de données !? Si en plus je peux avoir une option NOLOGGING qui me permet :

---

Oui mais en cas de crash, le fait d'avoir loggué dans le journal permet de revenir à une situation pérenne alors que l'option NOLOGGING pas.

Citation:

---

1. Réduire la taille des fichiers JT

---

Le modèle de récupération BULK LOGGED permet de faire cela.

Citation:

---

2. Diminuer la durée d'exécutions des instructions
Ce serait génial !

---

Le mode BULK LOGGED + permet cela même si son but est avant tout de diminuer la quantité d'enregistrement dans le journal mais implicitement dans la plupart des cas cela accélère aussi les traitements

Citation:

---

ui c'est comme tout dans la vie ! le couteau qui sert à couper le pain peut également couper le doigt si on ne fait pas attention ! mais on est quand même content d'avoir un couteau quand on est à table (les indiens et les africains peuvent s'en passer de couteau à table, les doigts de la main et les dents font l'affaire parfaitement ... je confirme )

---

Encore une fois SQL Server a un mode pour faire cela. A quoi cela sert d'accélerer les opérations si on en perd la moitié en route ...

++

Citation:

---

Envoyé par mikedavem

Encore une fois SQL Server a un mode pour faire cela. A quoi cela sert d'accélerer les opérations si on en perd la moitié en route ...
++

---

En cas d'échec ! mais dans le cas contraire il y a bien gain de temps et d'espace disque. Je comprends bien ton point de vue mais ce qui me gène tu vois c'est que même avec ce mode BULK LOGGED mes BULK INSERT, mes BCP , .... sont forcément inscrits dans le JT quoi !

Citation:

---

Envoyé par SQLpro

Justement les modes BULK LOGGED et SIMPLE ne journalisent pas la création des index. Seule l'ordre CREATE INDEX est journalisé, pas les entrées de l'index.

A +

---

??? avec BULK LOGGED l'ordre de création des index (CREATE INDEX ...) est Journalisée

Citation:

---

En cas d'échec ! mais dans le cas contraire il y a bien gain de temps et d'espace disque. Je comprends bien ton point de vue mais ce qui me gène tu vois c'est que même avec ce mode BULK LOGGED mes BULK INSERT, mes BCP , .... sont forcément inscrits dans le JT quoi !

---

D'accord mais bon ce ne sont que les allocations d'extensions qui le sont ... cela représente quand même bien un gain plus que significatif quand ce mode peut être utilisé.

Mais bon on peut aller plus loin. Est-ce que l'on a vraiment un gain significatif à faire un backup de la base + NOLOGGING sur Oracle contre un simple passage en mode BULK-LOGGED + insertion en masse sur SQL Server ? A voir ...

++