J'ai une base dont le recovery model est simple. Malgré cela, je trouve ce
matin le journal de transactions dont la taille est passé à 7 go et plein à
92%.
J'ai fait un backup full et il reste dans le même état.
J'ai donc fait un backup log with truncate_only qui m'a permis de résoudre
le problème.
Quelqu'un peut-il m'expliquer cela?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
SQLpro [MVP]
Brigitte a écrit :
Bonjour,
J'ai une base dont le recovery model est simple. Malgré cela, je trouve ce matin le journal de transactions dont la taille est passé à 7 go et plein à 92%. J'ai fait un backup full et il reste dans le même état. J'ai donc fait un backup log with truncate_only qui m'a permis de résoudre le problème. Quelqu'un peut-il m'expliquer cela?
Une base de données ne peut pas vivre sans le journal des transactions. Il assure l'acidité des transactions, c'est à dire que tous les ordres SELECT, UPDATE, DELETE, INSERT, CREATE, ALTER, DROP... et bien d'autres peuvent être validés ou annulés. Le modèle simple ne fait que minimiser le volume enregistré dans le JT.
Le JT peut croitre de façon beaucoup plus importante que la base et c'est tout à fait normal.
Par exemple le script suivant laissera une base vide et un journal plein
CREATE DATABASE DB_TEST_JT GO
USE DB_TEST_JT GO
CREATE TABLE T_UID (UID UNIQUEIDENTIFIER) GO
DECLARE @I INT
SET @I = 0
WHILE @I <> 1000 BEGIN INSERT INTO T_UID VALUES (NEWID()) SET @I = @I + 1 END
DELETE FROM T_UID GO
A +
Merci
Bonne journée
Brigitte
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Brigitte a écrit :
Bonjour,
J'ai une base dont le recovery model est simple. Malgré cela, je trouve ce
matin le journal de transactions dont la taille est passé à 7 go et plein à
92%.
J'ai fait un backup full et il reste dans le même état.
J'ai donc fait un backup log with truncate_only qui m'a permis de résoudre
le problème.
Quelqu'un peut-il m'expliquer cela?
Une base de données ne peut pas vivre sans le journal des transactions.
Il assure l'acidité des transactions, c'est à dire que tous les ordres
SELECT, UPDATE, DELETE, INSERT, CREATE, ALTER, DROP... et bien d'autres
peuvent être validés ou annulés.
Le modèle simple ne fait que minimiser le volume enregistré dans le JT.
Le JT peut croitre de façon beaucoup plus importante que la base et
c'est tout à fait normal.
Par exemple le script suivant laissera une base vide et un journal plein
CREATE DATABASE DB_TEST_JT
GO
USE DB_TEST_JT
GO
CREATE TABLE T_UID
(UID UNIQUEIDENTIFIER)
GO
DECLARE @I INT
SET @I = 0
WHILE @I <> 1000
BEGIN
INSERT INTO T_UID VALUES (NEWID())
SET @I = @I + 1
END
DELETE FROM T_UID
GO
A +
Merci
Bonne journée
Brigitte
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
J'ai une base dont le recovery model est simple. Malgré cela, je trouve ce matin le journal de transactions dont la taille est passé à 7 go et plein à 92%. J'ai fait un backup full et il reste dans le même état. J'ai donc fait un backup log with truncate_only qui m'a permis de résoudre le problème. Quelqu'un peut-il m'expliquer cela?
Une base de données ne peut pas vivre sans le journal des transactions. Il assure l'acidité des transactions, c'est à dire que tous les ordres SELECT, UPDATE, DELETE, INSERT, CREATE, ALTER, DROP... et bien d'autres peuvent être validés ou annulés. Le modèle simple ne fait que minimiser le volume enregistré dans le JT.
Le JT peut croitre de façon beaucoup plus importante que la base et c'est tout à fait normal.
Par exemple le script suivant laissera une base vide et un journal plein
CREATE DATABASE DB_TEST_JT GO
USE DB_TEST_JT GO
CREATE TABLE T_UID (UID UNIQUEIDENTIFIER) GO
DECLARE @I INT
SET @I = 0
WHILE @I <> 1000 BEGIN INSERT INTO T_UID VALUES (NEWID()) SET @I = @I + 1 END
DELETE FROM T_UID GO
A +
Merci
Bonne journée
Brigitte
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Brigitte
Merci. Pourquoi le backup n'a pas permis de vider le journal de transactions. J'ai restauré ce dump sur une plateforme de secours et le log avait bien une taille de 7go mais plein à 2% au lieu de 92%.
Bonne journée
Brigitte
"SQLpro [MVP]" a écrit :
Brigitte a écrit : > Bonjour, > > J'ai une base dont le recovery model est simple. Malgré cela, je trouve ce > matin le journal de transactions dont la taille est passé à 7 go et plein à > 92%. > J'ai fait un backup full et il reste dans le même état. > J'ai donc fait un backup log with truncate_only qui m'a permis de résoudre > le problème. > Quelqu'un peut-il m'expliquer cela?
Une base de données ne peut pas vivre sans le journal des transactions. Il assure l'acidité des transactions, c'est à dire que tous les ordres SELECT, UPDATE, DELETE, INSERT, CREATE, ALTER, DROP... et bien d'autres peuvent être validés ou annulés. Le modèle simple ne fait que minimiser le volume enregistré dans le JT.
Le JT peut croitre de façon beaucoup plus importante que la base et c'est tout à fait normal.
Par exemple le script suivant laissera une base vide et un journal plein
CREATE DATABASE DB_TEST_JT GO
USE DB_TEST_JT GO
CREATE TABLE T_UID (UID UNIQUEIDENTIFIER) GO
DECLARE @I INT
SET @I = 0
WHILE @I <> 1000 BEGIN INSERT INTO T_UID VALUES (NEWID()) SET @I = @I + 1 END
DELETE FROM T_UID GO
A +
> > Merci > > Bonne journée > > Brigitte
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Merci.
Pourquoi le backup n'a pas permis de vider le journal de transactions.
J'ai restauré ce dump sur une plateforme de secours et le log avait bien une
taille de 7go mais plein à 2% au lieu de 92%.
Bonne journée
Brigitte
"SQLpro [MVP]" a écrit :
Brigitte a écrit :
> Bonjour,
>
> J'ai une base dont le recovery model est simple. Malgré cela, je trouve ce
> matin le journal de transactions dont la taille est passé à 7 go et plein à
> 92%.
> J'ai fait un backup full et il reste dans le même état.
> J'ai donc fait un backup log with truncate_only qui m'a permis de résoudre
> le problème.
> Quelqu'un peut-il m'expliquer cela?
Une base de données ne peut pas vivre sans le journal des transactions.
Il assure l'acidité des transactions, c'est à dire que tous les ordres
SELECT, UPDATE, DELETE, INSERT, CREATE, ALTER, DROP... et bien d'autres
peuvent être validés ou annulés.
Le modèle simple ne fait que minimiser le volume enregistré dans le JT.
Le JT peut croitre de façon beaucoup plus importante que la base et
c'est tout à fait normal.
Par exemple le script suivant laissera une base vide et un journal plein
CREATE DATABASE DB_TEST_JT
GO
USE DB_TEST_JT
GO
CREATE TABLE T_UID
(UID UNIQUEIDENTIFIER)
GO
DECLARE @I INT
SET @I = 0
WHILE @I <> 1000
BEGIN
INSERT INTO T_UID VALUES (NEWID())
SET @I = @I + 1
END
DELETE FROM T_UID
GO
A +
>
> Merci
>
> Bonne journée
>
> Brigitte
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Merci. Pourquoi le backup n'a pas permis de vider le journal de transactions. J'ai restauré ce dump sur une plateforme de secours et le log avait bien une taille de 7go mais plein à 2% au lieu de 92%.
Bonne journée
Brigitte
"SQLpro [MVP]" a écrit :
Brigitte a écrit : > Bonjour, > > J'ai une base dont le recovery model est simple. Malgré cela, je trouve ce > matin le journal de transactions dont la taille est passé à 7 go et plein à > 92%. > J'ai fait un backup full et il reste dans le même état. > J'ai donc fait un backup log with truncate_only qui m'a permis de résoudre > le problème. > Quelqu'un peut-il m'expliquer cela?
Une base de données ne peut pas vivre sans le journal des transactions. Il assure l'acidité des transactions, c'est à dire que tous les ordres SELECT, UPDATE, DELETE, INSERT, CREATE, ALTER, DROP... et bien d'autres peuvent être validés ou annulés. Le modèle simple ne fait que minimiser le volume enregistré dans le JT.
Le JT peut croitre de façon beaucoup plus importante que la base et c'est tout à fait normal.
Par exemple le script suivant laissera une base vide et un journal plein
CREATE DATABASE DB_TEST_JT GO
USE DB_TEST_JT GO
CREATE TABLE T_UID (UID UNIQUEIDENTIFIER) GO
DECLARE @I INT
SET @I = 0
WHILE @I <> 1000 BEGIN INSERT INTO T_UID VALUES (NEWID()) SET @I = @I + 1 END
DELETE FROM T_UID GO
A +
> > Merci > > Bonne journée > > Brigitte
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
SQLpro [MVP]
Brigitte a écrit :
Merci. Pourquoi le backup n'a pas permis de vider le journal de transactions. J'ai restauré ce dump sur une plateforme de secours et le log avait bien une taille de 7go mais plein à 2% au lieu de 92%.
la sauvegarde du JT prépare la troncature (logique) la troncature s'effectue avec un ordre TRUNCATE explicite ou implicite, mais toujours une sauvegarde du JT) c'est la réduction logique du JT Le SHRINK permet de réduire physiquement le fichier. Il peut être implicite (AUTOHSRINK à ON) ou explicite
En conséquence, les 3 actions doivent se succéder pour satisfaire la réduction physique du JT.
A +
Bonne journée
Brigitte
"SQLpro [MVP]" a écrit :
Brigitte a écrit :
Bonjour,
J'ai une base dont le recovery model est simple. Malgré cela, je trouve ce matin le journal de transactions dont la taille est passé à 7 go et plein à 92%. J'ai fait un backup full et il reste dans le même état. J'ai donc fait un backup log with truncate_only qui m'a permis de résoudre le problème. Quelqu'un peut-il m'expliquer cela?
Une base de données ne peut pas vivre sans le journal des transactions. Il assure l'acidité des transactions, c'est à dire que tous les ordres SELECT, UPDATE, DELETE, INSERT, CREATE, ALTER, DROP... et bien d'autres peuvent être validés ou annulés. Le modèle simple ne fait que minimiser le volume enregistré dans le JT.
Le JT peut croitre de façon beaucoup plus importante que la base et c'est tout à fait normal.
Par exemple le script suivant laissera une base vide et un journal plein
CREATE DATABASE DB_TEST_JT GO
USE DB_TEST_JT GO
CREATE TABLE T_UID (UID UNIQUEIDENTIFIER) GO
DECLARE @I INT
SET @I = 0
WHILE @I <> 1000 BEGIN INSERT INTO T_UID VALUES (NEWID()) SET @I = @I + 1 END
DELETE FROM T_UID GO
A +
Merci
Bonne journée
Brigitte
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
Brigitte a écrit :
Merci.
Pourquoi le backup n'a pas permis de vider le journal de transactions.
J'ai restauré ce dump sur une plateforme de secours et le log avait bien une
taille de 7go mais plein à 2% au lieu de 92%.
la sauvegarde du JT prépare la troncature (logique)
la troncature s'effectue avec un ordre TRUNCATE explicite ou implicite,
mais toujours une sauvegarde du JT) c'est la réduction logique du JT
Le SHRINK permet de réduire physiquement le fichier. Il peut être
implicite (AUTOHSRINK à ON) ou explicite
En conséquence, les 3 actions doivent se succéder pour satisfaire la
réduction physique du JT.
A +
Bonne journée
Brigitte
"SQLpro [MVP]" a écrit :
Brigitte a écrit :
Bonjour,
J'ai une base dont le recovery model est simple. Malgré cela, je trouve ce
matin le journal de transactions dont la taille est passé à 7 go et plein à
92%.
J'ai fait un backup full et il reste dans le même état.
J'ai donc fait un backup log with truncate_only qui m'a permis de résoudre
le problème.
Quelqu'un peut-il m'expliquer cela?
Une base de données ne peut pas vivre sans le journal des transactions.
Il assure l'acidité des transactions, c'est à dire que tous les ordres
SELECT, UPDATE, DELETE, INSERT, CREATE, ALTER, DROP... et bien d'autres
peuvent être validés ou annulés.
Le modèle simple ne fait que minimiser le volume enregistré dans le JT.
Le JT peut croitre de façon beaucoup plus importante que la base et
c'est tout à fait normal.
Par exemple le script suivant laissera une base vide et un journal plein
CREATE DATABASE DB_TEST_JT
GO
USE DB_TEST_JT
GO
CREATE TABLE T_UID
(UID UNIQUEIDENTIFIER)
GO
DECLARE @I INT
SET @I = 0
WHILE @I <> 1000
BEGIN
INSERT INTO T_UID VALUES (NEWID())
SET @I = @I + 1
END
DELETE FROM T_UID
GO
A +
Merci
Bonne journée
Brigitte
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
Merci. Pourquoi le backup n'a pas permis de vider le journal de transactions. J'ai restauré ce dump sur une plateforme de secours et le log avait bien une taille de 7go mais plein à 2% au lieu de 92%.
la sauvegarde du JT prépare la troncature (logique) la troncature s'effectue avec un ordre TRUNCATE explicite ou implicite, mais toujours une sauvegarde du JT) c'est la réduction logique du JT Le SHRINK permet de réduire physiquement le fichier. Il peut être implicite (AUTOHSRINK à ON) ou explicite
En conséquence, les 3 actions doivent se succéder pour satisfaire la réduction physique du JT.
A +
Bonne journée
Brigitte
"SQLpro [MVP]" a écrit :
Brigitte a écrit :
Bonjour,
J'ai une base dont le recovery model est simple. Malgré cela, je trouve ce matin le journal de transactions dont la taille est passé à 7 go et plein à 92%. J'ai fait un backup full et il reste dans le même état. J'ai donc fait un backup log with truncate_only qui m'a permis de résoudre le problème. Quelqu'un peut-il m'expliquer cela?
Une base de données ne peut pas vivre sans le journal des transactions. Il assure l'acidité des transactions, c'est à dire que tous les ordres SELECT, UPDATE, DELETE, INSERT, CREATE, ALTER, DROP... et bien d'autres peuvent être validés ou annulés. Le modèle simple ne fait que minimiser le volume enregistré dans le JT.
Le JT peut croitre de façon beaucoup plus importante que la base et c'est tout à fait normal.
Par exemple le script suivant laissera une base vide et un journal plein
CREATE DATABASE DB_TEST_JT GO
USE DB_TEST_JT GO
CREATE TABLE T_UID (UID UNIQUEIDENTIFIER) GO
DECLARE @I INT
SET @I = 0
WHILE @I <> 1000 BEGIN INSERT INTO T_UID VALUES (NEWID()) SET @I = @I + 1 END
DELETE FROM T_UID GO
A +
Merci
Bonne journée
Brigitte
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
-- Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com Audit, conseil, expertise, formation, modélisation, tuning, optimisation ********************* http://www.datasapiens.com ***********************
bruno reiter
regardes avec DBCC OPENTRAN la plus ancienne transaction
br
"Brigitte" a écrit dans le message de news:
Bonjour,
J'ai une base dont le recovery model est simple. Malgré cela, je trouve ce matin le journal de transactions dont la taille est passé à 7 go et plein à 92%. J'ai fait un backup full et il reste dans le même état. J'ai donc fait un backup log with truncate_only qui m'a permis de résoudre le problème. Quelqu'un peut-il m'expliquer cela?
Merci
Bonne journée
Brigitte
regardes avec DBCC OPENTRAN la plus ancienne transaction
br
"Brigitte" <Brigitte@discussions.microsoft.com> a écrit dans le message de
news: 8981C5B1-71F8-472B-B675-F53B08076AA4@microsoft.com...
Bonjour,
J'ai une base dont le recovery model est simple. Malgré cela, je trouve ce
matin le journal de transactions dont la taille est passé à 7 go et plein
à
92%.
J'ai fait un backup full et il reste dans le même état.
J'ai donc fait un backup log with truncate_only qui m'a permis de résoudre
le problème.
Quelqu'un peut-il m'expliquer cela?
regardes avec DBCC OPENTRAN la plus ancienne transaction
br
"Brigitte" a écrit dans le message de news:
Bonjour,
J'ai une base dont le recovery model est simple. Malgré cela, je trouve ce matin le journal de transactions dont la taille est passé à 7 go et plein à 92%. J'ai fait un backup full et il reste dans le même état. J'ai donc fait un backup log with truncate_only qui m'a permis de résoudre le problème. Quelqu'un peut-il m'expliquer cela?
