d=E9butante en SQL, j'aimerai savoir pourquoi
une base qui =E0 87% d'espace libre ne se compresse
pas lorsqu'on lance la compression ??
j'ai bien fait une sauvegarde compl=E8te de la base
et une sauvegarde =E9galement du journal de transaction mais
elle ne se compresse pas malgr=E9 tout.
il s'agit d'une base InterchangeSQ utilis=E9e par biztalk.
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
Christian
Voici la syntaxe a exécuter dans l'analyseur de requète : DBCC SHRINKDATABASE
(database, %, notruncate / truncateonly)
go
Database : nom de la base de données
% : Pourcentage d'espace disponible restant souhaité dans le fichier de données après la réduction de la base de données.
Notruncate : Permet de conserver l'espace de fichier libéré dans les fichiers de la base de données. Sauf indication, l'espace libéré est libéré par le système d'exploitation.
Truncateonly : Tout espace inutilisé dans les fichiers de données est libéré par le système d'exploitation et le fichier est limité à la dernière étendue allouée, ce qui en réduit la taille sans toucher aux données.
Ceci te permet de compacter ta base de données.
Tu peux compacter par fichier séparément :
DBCC SHRINKFILE
(nom_log, taille, notruncate / truncateonly)
Go
Nom_log : nom logique du fichier journal à réduire (voir dans le spropriétés de la base de données)
Taille : taille du fichier journal après rédution
Notruncate : Permet de conserver l'espace de fichier libéré dans les fichiers de la base de données. Sauf indication, l'espace libéré est libéré par le système d'exploitation.
Truncateonly : Tout espace inutilisé dans les fichiers de données est libéré par le système d'exploitation et le fichier est limité à la dernière étendue allouée, ce qui en réduit la taille sans toucher aux données.
ceci pour le fichier des journaux de transactions.
Toujours faire un backup log avant de lancer un compactage.
Bon courage...
Christian
"Florence" a écrit dans le message de news:881401c3e972$dac67a90$ Bonjour,
débutante en SQL, j'aimerai savoir pourquoi une base qui à 87% d'espace libre ne se compresse pas lorsqu'on lance la compression ?? j'ai bien fait une sauvegarde complète de la base et une sauvegarde également du journal de transaction mais elle ne se compresse pas malgré tout. il s'agit d'une base InterchangeSQ utilisée par biztalk.
Merci à vous,
Florence
Voici la syntaxe a exécuter dans l'analyseur de requète :
DBCC SHRINKDATABASE
(database, %, notruncate / truncateonly)
go
Database : nom de la base de données
% : Pourcentage d'espace disponible restant souhaité dans le fichier de
données après la réduction de la base de données.
Notruncate : Permet de conserver l'espace de fichier libéré dans les
fichiers de la base de données. Sauf indication, l'espace libéré est libéré
par le système d'exploitation.
Truncateonly : Tout espace inutilisé dans les fichiers de données est libéré
par le système d'exploitation et le fichier est limité à la dernière étendue
allouée, ce qui en réduit la taille sans toucher aux données.
Ceci te permet de compacter ta base de données.
Tu peux compacter par fichier séparément :
DBCC SHRINKFILE
(nom_log, taille, notruncate / truncateonly)
Go
Nom_log : nom logique du fichier journal à réduire (voir dans le spropriétés
de la base de données)
Taille : taille du fichier journal après rédution
Notruncate : Permet de conserver l'espace de fichier libéré dans les
fichiers de la base de données. Sauf indication, l'espace libéré est libéré
par le système d'exploitation.
Truncateonly : Tout espace inutilisé dans les fichiers de données est libéré
par le système d'exploitation et le fichier est limité à la dernière étendue
allouée, ce qui en réduit la taille sans toucher aux données.
ceci pour le fichier des journaux de transactions.
Toujours faire un backup log avant de lancer un compactage.
Bon courage...
Christian
"Florence" <anonymous@discussions.microsoft.com> a écrit dans le message de
news:881401c3e972$dac67a90$a401280a@phx.gbl...
Bonjour,
débutante en SQL, j'aimerai savoir pourquoi
une base qui à 87% d'espace libre ne se compresse
pas lorsqu'on lance la compression ??
j'ai bien fait une sauvegarde complète de la base
et une sauvegarde également du journal de transaction mais
elle ne se compresse pas malgré tout.
il s'agit d'une base InterchangeSQ utilisée par biztalk.
Voici la syntaxe a exécuter dans l'analyseur de requète : DBCC SHRINKDATABASE
(database, %, notruncate / truncateonly)
go
Database : nom de la base de données
% : Pourcentage d'espace disponible restant souhaité dans le fichier de données après la réduction de la base de données.
Notruncate : Permet de conserver l'espace de fichier libéré dans les fichiers de la base de données. Sauf indication, l'espace libéré est libéré par le système d'exploitation.
Truncateonly : Tout espace inutilisé dans les fichiers de données est libéré par le système d'exploitation et le fichier est limité à la dernière étendue allouée, ce qui en réduit la taille sans toucher aux données.
Ceci te permet de compacter ta base de données.
Tu peux compacter par fichier séparément :
DBCC SHRINKFILE
(nom_log, taille, notruncate / truncateonly)
Go
Nom_log : nom logique du fichier journal à réduire (voir dans le spropriétés de la base de données)
Taille : taille du fichier journal après rédution
Notruncate : Permet de conserver l'espace de fichier libéré dans les fichiers de la base de données. Sauf indication, l'espace libéré est libéré par le système d'exploitation.
Truncateonly : Tout espace inutilisé dans les fichiers de données est libéré par le système d'exploitation et le fichier est limité à la dernière étendue allouée, ce qui en réduit la taille sans toucher aux données.
ceci pour le fichier des journaux de transactions.
Toujours faire un backup log avant de lancer un compactage.
Bon courage...
Christian
"Florence" a écrit dans le message de news:881401c3e972$dac67a90$ Bonjour,
débutante en SQL, j'aimerai savoir pourquoi une base qui à 87% d'espace libre ne se compresse pas lorsqu'on lance la compression ?? j'ai bien fait une sauvegarde complète de la base et une sauvegarde également du journal de transaction mais elle ne se compresse pas malgré tout. il s'agit d'une base InterchangeSQ utilisée par biztalk.
Merci à vous,
Florence
Merci pour votre réponse, mais mon soucis n'est pas que je ne sais pas comment on fait mais plutot qu'il n'y a pas de résultat suite à une compression. le journal de transaction fait 69.75 Mo et à un espace disponible de 53.82Mo si je fais une compression cela ne change rien, c'est toujours la même taille. j'ai bien sur fait une sauvegarde du journal avant.
ce n'est quand même pas le fait de la faire par l'analyser de requetes qui change les choses ?? je fais ma compression via SLQ manager.
Merci à vous, Florence
-----Message d'origine----- Voici la syntaxe a exécuter dans l'analyseur de requète : DBCC SHRINKDATABASE
(database, %, notruncate / truncateonly)
go
Database : nom de la base de données
% : Pourcentage d'espace disponible restant souhaité dans
le fichier de
données après la réduction de la base de données.
Notruncate : Permet de conserver l'espace de fichier
libéré dans les
fichiers de la base de données. Sauf indication, l'espace
libéré est libéré
par le système d'exploitation.
Truncateonly : Tout espace inutilisé dans les fichiers de
données est libéré
par le système d'exploitation et le fichier est limité à
la dernière étendue
allouée, ce qui en réduit la taille sans toucher aux
données.
Ceci te permet de compacter ta base de données.
Tu peux compacter par fichier séparément :
DBCC SHRINKFILE
(nom_log, taille, notruncate / truncateonly)
Go
Nom_log : nom logique du fichier journal à réduire (voir
dans le spropriétés
de la base de données)
Taille : taille du fichier journal après rédution
Notruncate : Permet de conserver l'espace de fichier
libéré dans les
fichiers de la base de données. Sauf indication, l'espace
libéré est libéré
par le système d'exploitation.
Truncateonly : Tout espace inutilisé dans les fichiers de
données est libéré
par le système d'exploitation et le fichier est limité à
la dernière étendue
allouée, ce qui en réduit la taille sans toucher aux
données.
ceci pour le fichier des journaux de transactions.
Toujours faire un backup log avant de lancer un
compactage.
Bon courage...
Christian
"Florence" a écrit
dans le message de
news:881401c3e972$dac67a90$ Bonjour,
débutante en SQL, j'aimerai savoir pourquoi une base qui à 87% d'espace libre ne se compresse pas lorsqu'on lance la compression ?? j'ai bien fait une sauvegarde complète de la base et une sauvegarde également du journal de transaction mais elle ne se compresse pas malgré tout. il s'agit d'une base InterchangeSQ utilisée par biztalk.
Merci à vous,
Florence
.
Merci pour votre réponse, mais mon soucis n'est pas que
je ne sais pas comment on fait mais plutot qu'il n'y
a pas de résultat suite à une compression.
le journal de transaction fait 69.75 Mo
et à un espace disponible de 53.82Mo
si je fais une compression cela ne change rien, c'est
toujours la même taille.
j'ai bien sur fait une sauvegarde du journal avant.
ce n'est quand même pas le fait de la faire par l'analyser
de requetes qui change les choses ?? je fais ma
compression via SLQ manager.
Merci à vous,
Florence
-----Message d'origine-----
Voici la syntaxe a exécuter dans l'analyseur de requète :
DBCC SHRINKDATABASE
(database, %, notruncate / truncateonly)
go
Database : nom de la base de données
% : Pourcentage d'espace disponible restant souhaité dans
le fichier de
données après la réduction de la base de données.
Notruncate : Permet de conserver l'espace de fichier
libéré dans les
fichiers de la base de données. Sauf indication, l'espace
libéré est libéré
par le système d'exploitation.
Truncateonly : Tout espace inutilisé dans les fichiers de
données est libéré
par le système d'exploitation et le fichier est limité à
la dernière étendue
allouée, ce qui en réduit la taille sans toucher aux
données.
Ceci te permet de compacter ta base de données.
Tu peux compacter par fichier séparément :
DBCC SHRINKFILE
(nom_log, taille, notruncate / truncateonly)
Go
Nom_log : nom logique du fichier journal à réduire (voir
dans le spropriétés
de la base de données)
Taille : taille du fichier journal après rédution
Notruncate : Permet de conserver l'espace de fichier
libéré dans les
fichiers de la base de données. Sauf indication, l'espace
libéré est libéré
par le système d'exploitation.
Truncateonly : Tout espace inutilisé dans les fichiers de
données est libéré
par le système d'exploitation et le fichier est limité à
la dernière étendue
allouée, ce qui en réduit la taille sans toucher aux
données.
ceci pour le fichier des journaux de transactions.
Toujours faire un backup log avant de lancer un
compactage.
Bon courage...
Christian
"Florence" <anonymous@discussions.microsoft.com> a écrit
débutante en SQL, j'aimerai savoir pourquoi
une base qui à 87% d'espace libre ne se compresse
pas lorsqu'on lance la compression ??
j'ai bien fait une sauvegarde complète de la base
et une sauvegarde également du journal de transaction mais
elle ne se compresse pas malgré tout.
il s'agit d'une base InterchangeSQ utilisée par biztalk.
Merci pour votre réponse, mais mon soucis n'est pas que je ne sais pas comment on fait mais plutot qu'il n'y a pas de résultat suite à une compression. le journal de transaction fait 69.75 Mo et à un espace disponible de 53.82Mo si je fais une compression cela ne change rien, c'est toujours la même taille. j'ai bien sur fait une sauvegarde du journal avant.
ce n'est quand même pas le fait de la faire par l'analyser de requetes qui change les choses ?? je fais ma compression via SLQ manager.
Merci à vous, Florence
-----Message d'origine----- Voici la syntaxe a exécuter dans l'analyseur de requète : DBCC SHRINKDATABASE
(database, %, notruncate / truncateonly)
go
Database : nom de la base de données
% : Pourcentage d'espace disponible restant souhaité dans
le fichier de
données après la réduction de la base de données.
Notruncate : Permet de conserver l'espace de fichier
libéré dans les
fichiers de la base de données. Sauf indication, l'espace
libéré est libéré
par le système d'exploitation.
Truncateonly : Tout espace inutilisé dans les fichiers de
données est libéré
par le système d'exploitation et le fichier est limité à
la dernière étendue
allouée, ce qui en réduit la taille sans toucher aux
données.
Ceci te permet de compacter ta base de données.
Tu peux compacter par fichier séparément :
DBCC SHRINKFILE
(nom_log, taille, notruncate / truncateonly)
Go
Nom_log : nom logique du fichier journal à réduire (voir
dans le spropriétés
de la base de données)
Taille : taille du fichier journal après rédution
Notruncate : Permet de conserver l'espace de fichier
libéré dans les
fichiers de la base de données. Sauf indication, l'espace
libéré est libéré
par le système d'exploitation.
Truncateonly : Tout espace inutilisé dans les fichiers de
données est libéré
par le système d'exploitation et le fichier est limité à
la dernière étendue
allouée, ce qui en réduit la taille sans toucher aux
données.
ceci pour le fichier des journaux de transactions.
Toujours faire un backup log avant de lancer un
compactage.
Bon courage...
Christian
"Florence" a écrit
dans le message de
news:881401c3e972$dac67a90$ Bonjour,
débutante en SQL, j'aimerai savoir pourquoi une base qui à 87% d'espace libre ne se compresse pas lorsqu'on lance la compression ?? j'ai bien fait une sauvegarde complète de la base et une sauvegarde également du journal de transaction mais elle ne se compresse pas malgré tout. il s'agit d'une base InterchangeSQ utilisée par biztalk.
Merci à vous,
Florence
.
Christian
Si, la compression par entreprise manager ne fonctionne pas bien ou il faut combiner et répéter plusieurs fois les compactages... Par l'analyseur de requête, ca fonctionne de suite...
Christian
a écrit dans le message de news:8b0901c3e9a5$c06b77d0$
Merci pour votre réponse, mais mon soucis n'est pas que je ne sais pas comment on fait mais plutot qu'il n'y a pas de résultat suite à une compression. le journal de transaction fait 69.75 Mo et à un espace disponible de 53.82Mo si je fais une compression cela ne change rien, c'est toujours la même taille. j'ai bien sur fait une sauvegarde du journal avant.
ce n'est quand même pas le fait de la faire par l'analyser de requetes qui change les choses ?? je fais ma compression via SLQ manager.
Merci à vous, Florence
-----Message d'origine----- Voici la syntaxe a exécuter dans l'analyseur de requète : DBCC SHRINKDATABASE
(database, %, notruncate / truncateonly)
go
Database : nom de la base de données
% : Pourcentage d'espace disponible restant souhaité dans
le fichier de
données après la réduction de la base de données.
Notruncate : Permet de conserver l'espace de fichier
libéré dans les
fichiers de la base de données. Sauf indication, l'espace
libéré est libéré
par le système d'exploitation.
Truncateonly : Tout espace inutilisé dans les fichiers de
données est libéré
par le système d'exploitation et le fichier est limité à
la dernière étendue
allouée, ce qui en réduit la taille sans toucher aux
données.
Ceci te permet de compacter ta base de données.
Tu peux compacter par fichier séparément :
DBCC SHRINKFILE
(nom_log, taille, notruncate / truncateonly)
Go
Nom_log : nom logique du fichier journal à réduire (voir
dans le spropriétés
de la base de données)
Taille : taille du fichier journal après rédution
Notruncate : Permet de conserver l'espace de fichier
libéré dans les
fichiers de la base de données. Sauf indication, l'espace
libéré est libéré
par le système d'exploitation.
Truncateonly : Tout espace inutilisé dans les fichiers de
données est libéré
par le système d'exploitation et le fichier est limité à
la dernière étendue
allouée, ce qui en réduit la taille sans toucher aux
données.
ceci pour le fichier des journaux de transactions.
Toujours faire un backup log avant de lancer un
compactage.
Bon courage...
Christian
"Florence" a écrit
dans le message de
news:881401c3e972$dac67a90$ Bonjour,
débutante en SQL, j'aimerai savoir pourquoi une base qui à 87% d'espace libre ne se compresse pas lorsqu'on lance la compression ?? j'ai bien fait une sauvegarde complète de la base et une sauvegarde également du journal de transaction mais elle ne se compresse pas malgré tout. il s'agit d'une base InterchangeSQ utilisée par biztalk.
Merci à vous,
Florence
.
Si, la compression par entreprise manager ne fonctionne pas bien ou il faut
combiner et répéter plusieurs fois les compactages...
Par l'analyseur de requête, ca fonctionne de suite...
Christian
<anonymous@discussions.microsoft.com> a écrit dans le message de
news:8b0901c3e9a5$c06b77d0$a501280a@phx.gbl...
Merci pour votre réponse, mais mon soucis n'est pas que
je ne sais pas comment on fait mais plutot qu'il n'y
a pas de résultat suite à une compression.
le journal de transaction fait 69.75 Mo
et à un espace disponible de 53.82Mo
si je fais une compression cela ne change rien, c'est
toujours la même taille.
j'ai bien sur fait une sauvegarde du journal avant.
ce n'est quand même pas le fait de la faire par l'analyser
de requetes qui change les choses ?? je fais ma
compression via SLQ manager.
Merci à vous,
Florence
-----Message d'origine-----
Voici la syntaxe a exécuter dans l'analyseur de requète :
DBCC SHRINKDATABASE
(database, %, notruncate / truncateonly)
go
Database : nom de la base de données
% : Pourcentage d'espace disponible restant souhaité dans
le fichier de
données après la réduction de la base de données.
Notruncate : Permet de conserver l'espace de fichier
libéré dans les
fichiers de la base de données. Sauf indication, l'espace
libéré est libéré
par le système d'exploitation.
Truncateonly : Tout espace inutilisé dans les fichiers de
données est libéré
par le système d'exploitation et le fichier est limité à
la dernière étendue
allouée, ce qui en réduit la taille sans toucher aux
données.
Ceci te permet de compacter ta base de données.
Tu peux compacter par fichier séparément :
DBCC SHRINKFILE
(nom_log, taille, notruncate / truncateonly)
Go
Nom_log : nom logique du fichier journal à réduire (voir
dans le spropriétés
de la base de données)
Taille : taille du fichier journal après rédution
Notruncate : Permet de conserver l'espace de fichier
libéré dans les
fichiers de la base de données. Sauf indication, l'espace
libéré est libéré
par le système d'exploitation.
Truncateonly : Tout espace inutilisé dans les fichiers de
données est libéré
par le système d'exploitation et le fichier est limité à
la dernière étendue
allouée, ce qui en réduit la taille sans toucher aux
données.
ceci pour le fichier des journaux de transactions.
Toujours faire un backup log avant de lancer un
compactage.
Bon courage...
Christian
"Florence" <anonymous@discussions.microsoft.com> a écrit
débutante en SQL, j'aimerai savoir pourquoi
une base qui à 87% d'espace libre ne se compresse
pas lorsqu'on lance la compression ??
j'ai bien fait une sauvegarde complète de la base
et une sauvegarde également du journal de transaction mais
elle ne se compresse pas malgré tout.
il s'agit d'une base InterchangeSQ utilisée par biztalk.
Si, la compression par entreprise manager ne fonctionne pas bien ou il faut combiner et répéter plusieurs fois les compactages... Par l'analyseur de requête, ca fonctionne de suite...
Christian
a écrit dans le message de news:8b0901c3e9a5$c06b77d0$
Merci pour votre réponse, mais mon soucis n'est pas que je ne sais pas comment on fait mais plutot qu'il n'y a pas de résultat suite à une compression. le journal de transaction fait 69.75 Mo et à un espace disponible de 53.82Mo si je fais une compression cela ne change rien, c'est toujours la même taille. j'ai bien sur fait une sauvegarde du journal avant.
ce n'est quand même pas le fait de la faire par l'analyser de requetes qui change les choses ?? je fais ma compression via SLQ manager.
Merci à vous, Florence
-----Message d'origine----- Voici la syntaxe a exécuter dans l'analyseur de requète : DBCC SHRINKDATABASE
(database, %, notruncate / truncateonly)
go
Database : nom de la base de données
% : Pourcentage d'espace disponible restant souhaité dans
le fichier de
données après la réduction de la base de données.
Notruncate : Permet de conserver l'espace de fichier
libéré dans les
fichiers de la base de données. Sauf indication, l'espace
libéré est libéré
par le système d'exploitation.
Truncateonly : Tout espace inutilisé dans les fichiers de
données est libéré
par le système d'exploitation et le fichier est limité à
la dernière étendue
allouée, ce qui en réduit la taille sans toucher aux
données.
Ceci te permet de compacter ta base de données.
Tu peux compacter par fichier séparément :
DBCC SHRINKFILE
(nom_log, taille, notruncate / truncateonly)
Go
Nom_log : nom logique du fichier journal à réduire (voir
dans le spropriétés
de la base de données)
Taille : taille du fichier journal après rédution
Notruncate : Permet de conserver l'espace de fichier
libéré dans les
fichiers de la base de données. Sauf indication, l'espace
libéré est libéré
par le système d'exploitation.
Truncateonly : Tout espace inutilisé dans les fichiers de
données est libéré
par le système d'exploitation et le fichier est limité à
la dernière étendue
allouée, ce qui en réduit la taille sans toucher aux
données.
ceci pour le fichier des journaux de transactions.
Toujours faire un backup log avant de lancer un
compactage.
Bon courage...
Christian
"Florence" a écrit
dans le message de
news:881401c3e972$dac67a90$ Bonjour,
débutante en SQL, j'aimerai savoir pourquoi une base qui à 87% d'espace libre ne se compresse pas lorsqu'on lance la compression ?? j'ai bien fait une sauvegarde complète de la base et une sauvegarde également du journal de transaction mais elle ne se compresse pas malgré tout. il s'agit d'une base InterchangeSQ utilisée par biztalk.
