Bonjour
Je souhaite maintenir une quantité de données stable dans ma base de données
ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
procédures suivantes :
1. SUPPRESSION d’un nombre déterminé de données ;
2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
3. DBCC SHRINKDATABASE (@nomBD);
4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
Par la suite, le journal des transactions reprend l’espace disponible
initial désiré.
Par contre, l’espace disponible du fichier des données de semble pas
changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
données (la base de données devient saturée).
Auriez-vous une solution à ce problème ?
Merci pour toute aide.
Bonjour
Je souhaite maintenir une quantité de données stable dans ma base de données
ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
procédures suivantes :
1. SUPPRESSION d’un nombre déterminé de données ;
2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
3. DBCC SHRINKDATABASE (@nomBD);
4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
Par la suite, le journal des transactions reprend l’espace disponible
initial désiré.
Par contre, l’espace disponible du fichier des données de semble pas
changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
données (la base de données devient saturée).
Auriez-vous une solution à ce problème ?
Merci pour toute aide.
Bonjour
Je souhaite maintenir une quantité de données stable dans ma base de données
ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
procédures suivantes :
1. SUPPRESSION d’un nombre déterminé de données ;
2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
3. DBCC SHRINKDATABASE (@nomBD);
4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
Par la suite, le journal des transactions reprend l’espace disponible
initial désiré.
Par contre, l’espace disponible du fichier des données de semble pas
changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
données (la base de données devient saturée).
Auriez-vous une solution à ce problème ?
Merci pour toute aide.
carjo12 a écrit :
> Bonjour
>
> Je souhaite maintenir une quantité de données stable dans ma base de données
> ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
> à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
> ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
> procédures suivantes :
>
> 1. SUPPRESSION d’un nombre déterminé de données ;
> 2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
> 3. DBCC SHRINKDATABASE (@nomBD);
> 4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
>
> Par la suite, le journal des transactions reprend l’espace disponible
> initial désiré.
>
> Par contre, l’espace disponible du fichier des données de semble pas
> changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
> données (la base de données devient saturée).
>
> Auriez-vous une solution à ce problème ?
D'abord il ne s'agit nullement d'un problème, du comportement sain d'un
SGBDR performant...
Pour cela il faudrait défragmenter les différents index, ainsi que les
espaces morts relevant de colonnes supprimées par le DLL.
DBCC INDEXDEFRAG, DBREINDEX...
DBCC CLEANTABLE
....
Mais j'attire votre attention sur le fait que restreindre, augmenter ou
diminuer la taille des fichiers de la base de données, nuit
considérablement aux performances, car cela créée de la fragmentation
physique des fichiers de données, outre le fait que cela n'a aucun
intérêt et qu'il vaut mieux, pour de très nombreuses raisons, créer des
fichiers de données de taille fixe, dont le volume doit être estimé à la
capacité à terme de la base de données (par exemple 3 à 5 années
d'exploitation).
A +
>
> Merci pour toute aide.
>
--
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 ***********************
carjo12 a écrit :
> Bonjour
>
> Je souhaite maintenir une quantité de données stable dans ma base de données
> ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
> à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
> ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
> procédures suivantes :
>
> 1. SUPPRESSION d’un nombre déterminé de données ;
> 2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
> 3. DBCC SHRINKDATABASE (@nomBD);
> 4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
>
> Par la suite, le journal des transactions reprend l’espace disponible
> initial désiré.
>
> Par contre, l’espace disponible du fichier des données de semble pas
> changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
> données (la base de données devient saturée).
>
> Auriez-vous une solution à ce problème ?
D'abord il ne s'agit nullement d'un problème, du comportement sain d'un
SGBDR performant...
Pour cela il faudrait défragmenter les différents index, ainsi que les
espaces morts relevant de colonnes supprimées par le DLL.
DBCC INDEXDEFRAG, DBREINDEX...
DBCC CLEANTABLE
....
Mais j'attire votre attention sur le fait que restreindre, augmenter ou
diminuer la taille des fichiers de la base de données, nuit
considérablement aux performances, car cela créée de la fragmentation
physique des fichiers de données, outre le fait que cela n'a aucun
intérêt et qu'il vaut mieux, pour de très nombreuses raisons, créer des
fichiers de données de taille fixe, dont le volume doit être estimé à la
capacité à terme de la base de données (par exemple 3 à 5 années
d'exploitation).
A +
>
> Merci pour toute aide.
>
--
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 ***********************
carjo12 a écrit :
> Bonjour
>
> Je souhaite maintenir une quantité de données stable dans ma base de données
> ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
> à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
> ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
> procédures suivantes :
>
> 1. SUPPRESSION d’un nombre déterminé de données ;
> 2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
> 3. DBCC SHRINKDATABASE (@nomBD);
> 4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
>
> Par la suite, le journal des transactions reprend l’espace disponible
> initial désiré.
>
> Par contre, l’espace disponible du fichier des données de semble pas
> changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
> données (la base de données devient saturée).
>
> Auriez-vous une solution à ce problème ?
D'abord il ne s'agit nullement d'un problème, du comportement sain d'un
SGBDR performant...
Pour cela il faudrait défragmenter les différents index, ainsi que les
espaces morts relevant de colonnes supprimées par le DLL.
DBCC INDEXDEFRAG, DBREINDEX...
DBCC CLEANTABLE
....
Mais j'attire votre attention sur le fait que restreindre, augmenter ou
diminuer la taille des fichiers de la base de données, nuit
considérablement aux performances, car cela créée de la fragmentation
physique des fichiers de données, outre le fait que cela n'a aucun
intérêt et qu'il vaut mieux, pour de très nombreuses raisons, créer des
fichiers de données de taille fixe, dont le volume doit être estimé à la
capacité à terme de la base de données (par exemple 3 à 5 années
d'exploitation).
A +
>
> Merci pour toute aide.
>
--
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 ***********************
Si je comprends, bien, il est préférable que, lors de la création de la base
de données, d'attribuer par exemple une taille de 500 Mo, sans croissance
automatique, au lieu d'une taille de 27 Mo avec une croissance de 50 Mo ?
Merci.
"SQLpro [MVP]" a écrit :carjo12 a écrit :Bonjour
Je souhaite maintenir une quantité de données stable dans ma base de données
ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
procédures suivantes :
1. SUPPRESSION d’un nombre déterminé de données ;
2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
3. DBCC SHRINKDATABASE (@nomBD);
4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
Par la suite, le journal des transactions reprend l’espace disponible
initial désiré.
Par contre, l’espace disponible du fichier des données de semble pas
changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
données (la base de données devient saturée).
Auriez-vous une solution à ce problème ?
D'abord il ne s'agit nullement d'un problème, du comportement sain d'un
SGBDR performant...
Pour cela il faudrait défragmenter les différents index, ainsi que les
espaces morts relevant de colonnes supprimées par le DLL.
DBCC INDEXDEFRAG, DBREINDEX...
DBCC CLEANTABLE
....
Mais j'attire votre attention sur le fait que restreindre, augmenter ou
diminuer la taille des fichiers de la base de données, nuit
considérablement aux performances, car cela créée de la fragmentation
physique des fichiers de données, outre le fait que cela n'a aucun
intérêt et qu'il vaut mieux, pour de très nombreuses raisons, créer des
fichiers de données de taille fixe, dont le volume doit être estimé à la
capacité à terme de la base de données (par exemple 3 à 5 années
d'exploitation).
A +Merci pour toute aide.
--
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 ***********************
Si je comprends, bien, il est préférable que, lors de la création de la base
de données, d'attribuer par exemple une taille de 500 Mo, sans croissance
automatique, au lieu d'une taille de 27 Mo avec une croissance de 50 Mo ?
Merci.
"SQLpro [MVP]" a écrit :
carjo12 a écrit :
Bonjour
Je souhaite maintenir une quantité de données stable dans ma base de données
ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
procédures suivantes :
1. SUPPRESSION d’un nombre déterminé de données ;
2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
3. DBCC SHRINKDATABASE (@nomBD);
4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
Par la suite, le journal des transactions reprend l’espace disponible
initial désiré.
Par contre, l’espace disponible du fichier des données de semble pas
changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
données (la base de données devient saturée).
Auriez-vous une solution à ce problème ?
D'abord il ne s'agit nullement d'un problème, du comportement sain d'un
SGBDR performant...
Pour cela il faudrait défragmenter les différents index, ainsi que les
espaces morts relevant de colonnes supprimées par le DLL.
DBCC INDEXDEFRAG, DBREINDEX...
DBCC CLEANTABLE
....
Mais j'attire votre attention sur le fait que restreindre, augmenter ou
diminuer la taille des fichiers de la base de données, nuit
considérablement aux performances, car cela créée de la fragmentation
physique des fichiers de données, outre le fait que cela n'a aucun
intérêt et qu'il vaut mieux, pour de très nombreuses raisons, créer des
fichiers de données de taille fixe, dont le volume doit être estimé à la
capacité à terme de la base de données (par exemple 3 à 5 années
d'exploitation).
A +
Merci pour toute aide.
--
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 ***********************
Si je comprends, bien, il est préférable que, lors de la création de la base
de données, d'attribuer par exemple une taille de 500 Mo, sans croissance
automatique, au lieu d'une taille de 27 Mo avec une croissance de 50 Mo ?
Merci.
"SQLpro [MVP]" a écrit :carjo12 a écrit :Bonjour
Je souhaite maintenir une quantité de données stable dans ma base de données
ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
procédures suivantes :
1. SUPPRESSION d’un nombre déterminé de données ;
2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
3. DBCC SHRINKDATABASE (@nomBD);
4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
Par la suite, le journal des transactions reprend l’espace disponible
initial désiré.
Par contre, l’espace disponible du fichier des données de semble pas
changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
données (la base de données devient saturée).
Auriez-vous une solution à ce problème ?
D'abord il ne s'agit nullement d'un problème, du comportement sain d'un
SGBDR performant...
Pour cela il faudrait défragmenter les différents index, ainsi que les
espaces morts relevant de colonnes supprimées par le DLL.
DBCC INDEXDEFRAG, DBREINDEX...
DBCC CLEANTABLE
....
Mais j'attire votre attention sur le fait que restreindre, augmenter ou
diminuer la taille des fichiers de la base de données, nuit
considérablement aux performances, car cela créée de la fragmentation
physique des fichiers de données, outre le fait que cela n'a aucun
intérêt et qu'il vaut mieux, pour de très nombreuses raisons, créer des
fichiers de données de taille fixe, dont le volume doit être estimé à la
capacité à terme de la base de données (par exemple 3 à 5 années
d'exploitation).
A +Merci pour toute aide.
--
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 ***********************
carjo12 a écrit :
> Si je comprends, bien, il est préférable que, lors de la création de la base
> de données, d'attribuer par exemple une taille de 500 Mo, sans croissance
> automatique, au lieu d'une taille de 27 Mo avec une croissance de 50 Mo ?
Chaque opération de croissance est une opération lourde qui
statistiquement toutes les chances de se produire au plus mauvais moment
(charge maximum) pénalisant encore plus les traitements et distandant
les temps de réponse et la durée des transaction.
Une opération de disque coute environ 10 000 à 100 000 fois le temps
d'une instruction CPU.
De plus avec une stratégie de croissance auto, les fichiers ont toutes
les chances d'être physiquement fragmentés... donc moins rapide en
accès. Cette fragmentation là n'étant pas "réparable" à chaud.
A +
>
> Merci.
>
> "SQLpro [MVP]" a écrit :
>
>> carjo12 a écrit :
>>> Bonjour
>>>
>>> Je souhaite maintenir une quantité de données stable dans ma base de données
>>> ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
>>> à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
>>> ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
>>> procédures suivantes :
>>>
>>> 1. SUPPRESSION d’un nombre déterminé de données ;
>>> 2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
>>> 3. DBCC SHRINKDATABASE (@nomBD);
>>> 4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
>>>
>>> Par la suite, le journal des transactions reprend l’espace disponible
>>> initial désiré.
>>>
>>> Par contre, l’espace disponible du fichier des données de semble pas
>>> changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
>>> données (la base de données devient saturée).
>>>
>>> Auriez-vous une solution à ce problème ?
>> D'abord il ne s'agit nullement d'un problème, du comportement sain d'un
>> SGBDR performant...
>>
>> Pour cela il faudrait défragmenter les différents index, ainsi que les
>> espaces morts relevant de colonnes supprimées par le DLL.
>>
>> DBCC INDEXDEFRAG, DBREINDEX...
>> DBCC CLEANTABLE
>> ....
>>
>> Mais j'attire votre attention sur le fait que restreindre, augmenter ou
>> diminuer la taille des fichiers de la base de données, nuit
>> considérablement aux performances, car cela créée de la fragmentation
>> physique des fichiers de données, outre le fait que cela n'a aucun
>> intérêt et qu'il vaut mieux, pour de très nombreuses raisons, créer des
>> fichiers de données de taille fixe, dont le volume doit être estimé à la
>> capacité à terme de la base de données (par exemple 3 à 5 années
>> d'exploitation).
>>
>> A +
>>
>>> Merci pour toute aide.
>>>
>>
>> --
>> 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 ***********************
carjo12 a écrit :
> Si je comprends, bien, il est préférable que, lors de la création de la base
> de données, d'attribuer par exemple une taille de 500 Mo, sans croissance
> automatique, au lieu d'une taille de 27 Mo avec une croissance de 50 Mo ?
Chaque opération de croissance est une opération lourde qui
statistiquement toutes les chances de se produire au plus mauvais moment
(charge maximum) pénalisant encore plus les traitements et distandant
les temps de réponse et la durée des transaction.
Une opération de disque coute environ 10 000 à 100 000 fois le temps
d'une instruction CPU.
De plus avec une stratégie de croissance auto, les fichiers ont toutes
les chances d'être physiquement fragmentés... donc moins rapide en
accès. Cette fragmentation là n'étant pas "réparable" à chaud.
A +
>
> Merci.
>
> "SQLpro [MVP]" a écrit :
>
>> carjo12 a écrit :
>>> Bonjour
>>>
>>> Je souhaite maintenir une quantité de données stable dans ma base de données
>>> ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
>>> à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
>>> ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
>>> procédures suivantes :
>>>
>>> 1. SUPPRESSION d’un nombre déterminé de données ;
>>> 2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
>>> 3. DBCC SHRINKDATABASE (@nomBD);
>>> 4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
>>>
>>> Par la suite, le journal des transactions reprend l’espace disponible
>>> initial désiré.
>>>
>>> Par contre, l’espace disponible du fichier des données de semble pas
>>> changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
>>> données (la base de données devient saturée).
>>>
>>> Auriez-vous une solution à ce problème ?
>> D'abord il ne s'agit nullement d'un problème, du comportement sain d'un
>> SGBDR performant...
>>
>> Pour cela il faudrait défragmenter les différents index, ainsi que les
>> espaces morts relevant de colonnes supprimées par le DLL.
>>
>> DBCC INDEXDEFRAG, DBREINDEX...
>> DBCC CLEANTABLE
>> ....
>>
>> Mais j'attire votre attention sur le fait que restreindre, augmenter ou
>> diminuer la taille des fichiers de la base de données, nuit
>> considérablement aux performances, car cela créée de la fragmentation
>> physique des fichiers de données, outre le fait que cela n'a aucun
>> intérêt et qu'il vaut mieux, pour de très nombreuses raisons, créer des
>> fichiers de données de taille fixe, dont le volume doit être estimé à la
>> capacité à terme de la base de données (par exemple 3 à 5 années
>> d'exploitation).
>>
>> A +
>>
>>> Merci pour toute aide.
>>>
>>
>> --
>> 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 ***********************
carjo12 a écrit :
> Si je comprends, bien, il est préférable que, lors de la création de la base
> de données, d'attribuer par exemple une taille de 500 Mo, sans croissance
> automatique, au lieu d'une taille de 27 Mo avec une croissance de 50 Mo ?
Chaque opération de croissance est une opération lourde qui
statistiquement toutes les chances de se produire au plus mauvais moment
(charge maximum) pénalisant encore plus les traitements et distandant
les temps de réponse et la durée des transaction.
Une opération de disque coute environ 10 000 à 100 000 fois le temps
d'une instruction CPU.
De plus avec une stratégie de croissance auto, les fichiers ont toutes
les chances d'être physiquement fragmentés... donc moins rapide en
accès. Cette fragmentation là n'étant pas "réparable" à chaud.
A +
>
> Merci.
>
> "SQLpro [MVP]" a écrit :
>
>> carjo12 a écrit :
>>> Bonjour
>>>
>>> Je souhaite maintenir une quantité de données stable dans ma base de données
>>> ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
>>> à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
>>> ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
>>> procédures suivantes :
>>>
>>> 1. SUPPRESSION d’un nombre déterminé de données ;
>>> 2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
>>> 3. DBCC SHRINKDATABASE (@nomBD);
>>> 4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
>>>
>>> Par la suite, le journal des transactions reprend l’espace disponible
>>> initial désiré.
>>>
>>> Par contre, l’espace disponible du fichier des données de semble pas
>>> changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
>>> données (la base de données devient saturée).
>>>
>>> Auriez-vous une solution à ce problème ?
>> D'abord il ne s'agit nullement d'un problème, du comportement sain d'un
>> SGBDR performant...
>>
>> Pour cela il faudrait défragmenter les différents index, ainsi que les
>> espaces morts relevant de colonnes supprimées par le DLL.
>>
>> DBCC INDEXDEFRAG, DBREINDEX...
>> DBCC CLEANTABLE
>> ....
>>
>> Mais j'attire votre attention sur le fait que restreindre, augmenter ou
>> diminuer la taille des fichiers de la base de données, nuit
>> considérablement aux performances, car cela créée de la fragmentation
>> physique des fichiers de données, outre le fait que cela n'a aucun
>> intérêt et qu'il vaut mieux, pour de très nombreuses raisons, créer des
>> fichiers de données de taille fixe, dont le volume doit être estimé à la
>> capacité à terme de la base de données (par exemple 3 à 5 années
>> d'exploitation).
>>
>> A +
>>
>>> Merci pour toute aide.
>>>
>>
>> --
>> 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 pour l'information. J'ai refait le test, sans attribuer une croissance
auto au fichier de données, avec les paramètres que j'ai donné en exemple
dans ma dernière réponse. Malheureusement, ça n'a pas réglé le
SHRINKDATABASE: à un moment donnée, l'insertion n'est plus possible.
Dois-je expérimenter avev les commandes DBCC INDEXDEFRAG, DBREINDEX,
DBCC CLEANTABLE ?
Merci.
"SQLpro [MVP]" a écrit :carjo12 a écrit :Si je comprends, bien, il est préférable que, lors de la création de la base
de données, d'attribuer par exemple une taille de 500 Mo, sans croissance
automatique, au lieu d'une taille de 27 Mo avec une croissance de 50 Mo ?
Chaque opération de croissance est une opération lourde qui
statistiquement toutes les chances de se produire au plus mauvais moment
(charge maximum) pénalisant encore plus les traitements et distandant
les temps de réponse et la durée des transaction.
Une opération de disque coute environ 10 000 à 100 000 fois le temps
d'une instruction CPU.
De plus avec une stratégie de croissance auto, les fichiers ont toutes
les chances d'être physiquement fragmentés... donc moins rapide en
accès. Cette fragmentation là n'étant pas "réparable" à chaud.
A +Merci.
"SQLpro [MVP]" a écrit :carjo12 a écrit :Bonjour
Je souhaite maintenir une quantité de données stable dans ma base de données
ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
procédures suivantes :
1. SUPPRESSION d’un nombre déterminé de données ;
2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
3. DBCC SHRINKDATABASE (@nomBD);
4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
Par la suite, le journal des transactions reprend l’espace disponible
initial désiré.
Par contre, l’espace disponible du fichier des données de semble pas
changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
données (la base de données devient saturée).
Auriez-vous une solution à ce problème ?
D'abord il ne s'agit nullement d'un problème, du comportement sain d'un
SGBDR performant...
Pour cela il faudrait défragmenter les différents index, ainsi que les
espaces morts relevant de colonnes supprimées par le DLL.
DBCC INDEXDEFRAG, DBREINDEX...
DBCC CLEANTABLE
....
Mais j'attire votre attention sur le fait que restreindre, augmenter ou
diminuer la taille des fichiers de la base de données, nuit
considérablement aux performances, car cela créée de la fragmentation
physique des fichiers de données, outre le fait que cela n'a aucun
intérêt et qu'il vaut mieux, pour de très nombreuses raisons, créer des
fichiers de données de taille fixe, dont le volume doit être estimé à la
capacité à terme de la base de données (par exemple 3 à 5 années
d'exploitation).
A +Merci pour toute aide.
--
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 pour l'information. J'ai refait le test, sans attribuer une croissance
auto au fichier de données, avec les paramètres que j'ai donné en exemple
dans ma dernière réponse. Malheureusement, ça n'a pas réglé le
SHRINKDATABASE: à un moment donnée, l'insertion n'est plus possible.
Dois-je expérimenter avev les commandes DBCC INDEXDEFRAG, DBREINDEX,
DBCC CLEANTABLE ?
Merci.
"SQLpro [MVP]" a écrit :
carjo12 a écrit :
Si je comprends, bien, il est préférable que, lors de la création de la base
de données, d'attribuer par exemple une taille de 500 Mo, sans croissance
automatique, au lieu d'une taille de 27 Mo avec une croissance de 50 Mo ?
Chaque opération de croissance est une opération lourde qui
statistiquement toutes les chances de se produire au plus mauvais moment
(charge maximum) pénalisant encore plus les traitements et distandant
les temps de réponse et la durée des transaction.
Une opération de disque coute environ 10 000 à 100 000 fois le temps
d'une instruction CPU.
De plus avec une stratégie de croissance auto, les fichiers ont toutes
les chances d'être physiquement fragmentés... donc moins rapide en
accès. Cette fragmentation là n'étant pas "réparable" à chaud.
A +
Merci.
"SQLpro [MVP]" a écrit :
carjo12 a écrit :
Bonjour
Je souhaite maintenir une quantité de données stable dans ma base de données
ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
procédures suivantes :
1. SUPPRESSION d’un nombre déterminé de données ;
2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
3. DBCC SHRINKDATABASE (@nomBD);
4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
Par la suite, le journal des transactions reprend l’espace disponible
initial désiré.
Par contre, l’espace disponible du fichier des données de semble pas
changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
données (la base de données devient saturée).
Auriez-vous une solution à ce problème ?
D'abord il ne s'agit nullement d'un problème, du comportement sain d'un
SGBDR performant...
Pour cela il faudrait défragmenter les différents index, ainsi que les
espaces morts relevant de colonnes supprimées par le DLL.
DBCC INDEXDEFRAG, DBREINDEX...
DBCC CLEANTABLE
....
Mais j'attire votre attention sur le fait que restreindre, augmenter ou
diminuer la taille des fichiers de la base de données, nuit
considérablement aux performances, car cela créée de la fragmentation
physique des fichiers de données, outre le fait que cela n'a aucun
intérêt et qu'il vaut mieux, pour de très nombreuses raisons, créer des
fichiers de données de taille fixe, dont le volume doit être estimé à la
capacité à terme de la base de données (par exemple 3 à 5 années
d'exploitation).
A +
Merci pour toute aide.
--
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 pour l'information. J'ai refait le test, sans attribuer une croissance
auto au fichier de données, avec les paramètres que j'ai donné en exemple
dans ma dernière réponse. Malheureusement, ça n'a pas réglé le
SHRINKDATABASE: à un moment donnée, l'insertion n'est plus possible.
Dois-je expérimenter avev les commandes DBCC INDEXDEFRAG, DBREINDEX,
DBCC CLEANTABLE ?
Merci.
"SQLpro [MVP]" a écrit :carjo12 a écrit :Si je comprends, bien, il est préférable que, lors de la création de la base
de données, d'attribuer par exemple une taille de 500 Mo, sans croissance
automatique, au lieu d'une taille de 27 Mo avec une croissance de 50 Mo ?
Chaque opération de croissance est une opération lourde qui
statistiquement toutes les chances de se produire au plus mauvais moment
(charge maximum) pénalisant encore plus les traitements et distandant
les temps de réponse et la durée des transaction.
Une opération de disque coute environ 10 000 à 100 000 fois le temps
d'une instruction CPU.
De plus avec une stratégie de croissance auto, les fichiers ont toutes
les chances d'être physiquement fragmentés... donc moins rapide en
accès. Cette fragmentation là n'étant pas "réparable" à chaud.
A +Merci.
"SQLpro [MVP]" a écrit :carjo12 a écrit :Bonjour
Je souhaite maintenir une quantité de données stable dans ma base de données
ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
procédures suivantes :
1. SUPPRESSION d’un nombre déterminé de données ;
2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
3. DBCC SHRINKDATABASE (@nomBD);
4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
Par la suite, le journal des transactions reprend l’espace disponible
initial désiré.
Par contre, l’espace disponible du fichier des données de semble pas
changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
données (la base de données devient saturée).
Auriez-vous une solution à ce problème ?
D'abord il ne s'agit nullement d'un problème, du comportement sain d'un
SGBDR performant...
Pour cela il faudrait défragmenter les différents index, ainsi que les
espaces morts relevant de colonnes supprimées par le DLL.
DBCC INDEXDEFRAG, DBREINDEX...
DBCC CLEANTABLE
....
Mais j'attire votre attention sur le fait que restreindre, augmenter ou
diminuer la taille des fichiers de la base de données, nuit
considérablement aux performances, car cela créée de la fragmentation
physique des fichiers de données, outre le fait que cela n'a aucun
intérêt et qu'il vaut mieux, pour de très nombreuses raisons, créer des
fichiers de données de taille fixe, dont le volume doit être estimé à la
capacité à terme de la base de données (par exemple 3 à 5 années
d'exploitation).
A +Merci pour toute aide.
--
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 ***********************
carjo12 a écrit :
> Merci pour l'information. J'ai refait le test, sans attribuer une croissance
> auto au fichier de données, avec les paramètres que j'ai donné en exemple
> dans ma dernière réponse. Malheureusement, ça n'a pas réglé le
> SHRINKDATABASE: à un moment donnée, l'insertion n'est plus possible.
> Dois-je expérimenter avev les commandes DBCC INDEXDEFRAG, DBREINDEX,
> DBCC CLEANTABLE ?
Pour la base, prévoir la taille à terme et sruveiller régulièrement.
par exemple compta sur 5 ans, environ 60 Go
Pour le JT prévoir large (1/3 de la base à terme) par exemple 20 Go
Faire un SHRINKFILE après avoir sauvegardé le JT
Ne JAMAIS fair de SHRINKDATABASE
A +
>
> Merci.
>
> "SQLpro [MVP]" a écrit :
>
>> carjo12 a écrit :
>>> Si je comprends, bien, il est préférable que, lors de la création de la base
>>> de données, d'attribuer par exemple une taille de 500 Mo, sans croissance
>>> automatique, au lieu d'une taille de 27 Mo avec une croissance de 50 Mo ?
>> Chaque opération de croissance est une opération lourde qui
>> statistiquement toutes les chances de se produire au plus mauvais moment
>> (charge maximum) pénalisant encore plus les traitements et distandant
>> les temps de réponse et la durée des transaction.
>> Une opération de disque coute environ 10 000 à 100 000 fois le temps
>> d'une instruction CPU.
>> De plus avec une stratégie de croissance auto, les fichiers ont toutes
>> les chances d'être physiquement fragmentés... donc moins rapide en
>> accès. Cette fragmentation là n'étant pas "réparable" à chaud.
>>
>> A +
>>
>>
>>
>>> Merci.
>>>
>>> "SQLpro [MVP]" a écrit :
>>>
>>>> carjo12 a écrit :
>>>>> Bonjour
>>>>>
>>>>> Je souhaite maintenir une quantité de données stable dans ma base de données
>>>>> ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
>>>>> à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
>>>>> ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
>>>>> procédures suivantes :
>>>>>
>>>>> 1. SUPPRESSION d’un nombre déterminé de données ;
>>>>> 2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
>>>>> 3. DBCC SHRINKDATABASE (@nomBD);
>>>>> 4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
>>>>>
>>>>> Par la suite, le journal des transactions reprend l’espace disponible
>>>>> initial désiré.
>>>>>
>>>>> Par contre, l’espace disponible du fichier des données de semble pas
>>>>> changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
>>>>> données (la base de données devient saturée).
>>>>>
>>>>> Auriez-vous une solution à ce problème ?
>>>> D'abord il ne s'agit nullement d'un problème, du comportement sain d'un
>>>> SGBDR performant...
>>>>
>>>> Pour cela il faudrait défragmenter les différents index, ainsi que les
>>>> espaces morts relevant de colonnes supprimées par le DLL.
>>>>
>>>> DBCC INDEXDEFRAG, DBREINDEX...
>>>> DBCC CLEANTABLE
>>>> ....
>>>>
>>>> Mais j'attire votre attention sur le fait que restreindre, augmenter ou
>>>> diminuer la taille des fichiers de la base de données, nuit
>>>> considérablement aux performances, car cela créée de la fragmentation
>>>> physique des fichiers de données, outre le fait que cela n'a aucun
>>>> intérêt et qu'il vaut mieux, pour de très nombreuses raisons, créer des
>>>> fichiers de données de taille fixe, dont le volume doit être estimé à la
>>>> capacité à terme de la base de données (par exemple 3 à 5 années
>>>> d'exploitation).
>>>>
>>>> A +
>>>>
>>>>> Merci pour toute aide.
>>>>>
>>>> --
>>>> 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 ***********************
>>
--
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 ***********************
carjo12 a écrit :
> Merci pour l'information. J'ai refait le test, sans attribuer une croissance
> auto au fichier de données, avec les paramètres que j'ai donné en exemple
> dans ma dernière réponse. Malheureusement, ça n'a pas réglé le
> SHRINKDATABASE: à un moment donnée, l'insertion n'est plus possible.
> Dois-je expérimenter avev les commandes DBCC INDEXDEFRAG, DBREINDEX,
> DBCC CLEANTABLE ?
Pour la base, prévoir la taille à terme et sruveiller régulièrement.
par exemple compta sur 5 ans, environ 60 Go
Pour le JT prévoir large (1/3 de la base à terme) par exemple 20 Go
Faire un SHRINKFILE après avoir sauvegardé le JT
Ne JAMAIS fair de SHRINKDATABASE
A +
>
> Merci.
>
> "SQLpro [MVP]" a écrit :
>
>> carjo12 a écrit :
>>> Si je comprends, bien, il est préférable que, lors de la création de la base
>>> de données, d'attribuer par exemple une taille de 500 Mo, sans croissance
>>> automatique, au lieu d'une taille de 27 Mo avec une croissance de 50 Mo ?
>> Chaque opération de croissance est une opération lourde qui
>> statistiquement toutes les chances de se produire au plus mauvais moment
>> (charge maximum) pénalisant encore plus les traitements et distandant
>> les temps de réponse et la durée des transaction.
>> Une opération de disque coute environ 10 000 à 100 000 fois le temps
>> d'une instruction CPU.
>> De plus avec une stratégie de croissance auto, les fichiers ont toutes
>> les chances d'être physiquement fragmentés... donc moins rapide en
>> accès. Cette fragmentation là n'étant pas "réparable" à chaud.
>>
>> A +
>>
>>
>>
>>> Merci.
>>>
>>> "SQLpro [MVP]" a écrit :
>>>
>>>> carjo12 a écrit :
>>>>> Bonjour
>>>>>
>>>>> Je souhaite maintenir une quantité de données stable dans ma base de données
>>>>> ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
>>>>> à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
>>>>> ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
>>>>> procédures suivantes :
>>>>>
>>>>> 1. SUPPRESSION d’un nombre déterminé de données ;
>>>>> 2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
>>>>> 3. DBCC SHRINKDATABASE (@nomBD);
>>>>> 4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
>>>>>
>>>>> Par la suite, le journal des transactions reprend l’espace disponible
>>>>> initial désiré.
>>>>>
>>>>> Par contre, l’espace disponible du fichier des données de semble pas
>>>>> changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
>>>>> données (la base de données devient saturée).
>>>>>
>>>>> Auriez-vous une solution à ce problème ?
>>>> D'abord il ne s'agit nullement d'un problème, du comportement sain d'un
>>>> SGBDR performant...
>>>>
>>>> Pour cela il faudrait défragmenter les différents index, ainsi que les
>>>> espaces morts relevant de colonnes supprimées par le DLL.
>>>>
>>>> DBCC INDEXDEFRAG, DBREINDEX...
>>>> DBCC CLEANTABLE
>>>> ....
>>>>
>>>> Mais j'attire votre attention sur le fait que restreindre, augmenter ou
>>>> diminuer la taille des fichiers de la base de données, nuit
>>>> considérablement aux performances, car cela créée de la fragmentation
>>>> physique des fichiers de données, outre le fait que cela n'a aucun
>>>> intérêt et qu'il vaut mieux, pour de très nombreuses raisons, créer des
>>>> fichiers de données de taille fixe, dont le volume doit être estimé à la
>>>> capacité à terme de la base de données (par exemple 3 à 5 années
>>>> d'exploitation).
>>>>
>>>> A +
>>>>
>>>>> Merci pour toute aide.
>>>>>
>>>> --
>>>> 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 ***********************
>>
--
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 ***********************
carjo12 a écrit :
> Merci pour l'information. J'ai refait le test, sans attribuer une croissance
> auto au fichier de données, avec les paramètres que j'ai donné en exemple
> dans ma dernière réponse. Malheureusement, ça n'a pas réglé le
> SHRINKDATABASE: à un moment donnée, l'insertion n'est plus possible.
> Dois-je expérimenter avev les commandes DBCC INDEXDEFRAG, DBREINDEX,
> DBCC CLEANTABLE ?
Pour la base, prévoir la taille à terme et sruveiller régulièrement.
par exemple compta sur 5 ans, environ 60 Go
Pour le JT prévoir large (1/3 de la base à terme) par exemple 20 Go
Faire un SHRINKFILE après avoir sauvegardé le JT
Ne JAMAIS fair de SHRINKDATABASE
A +
>
> Merci.
>
> "SQLpro [MVP]" a écrit :
>
>> carjo12 a écrit :
>>> Si je comprends, bien, il est préférable que, lors de la création de la base
>>> de données, d'attribuer par exemple une taille de 500 Mo, sans croissance
>>> automatique, au lieu d'une taille de 27 Mo avec une croissance de 50 Mo ?
>> Chaque opération de croissance est une opération lourde qui
>> statistiquement toutes les chances de se produire au plus mauvais moment
>> (charge maximum) pénalisant encore plus les traitements et distandant
>> les temps de réponse et la durée des transaction.
>> Une opération de disque coute environ 10 000 à 100 000 fois le temps
>> d'une instruction CPU.
>> De plus avec une stratégie de croissance auto, les fichiers ont toutes
>> les chances d'être physiquement fragmentés... donc moins rapide en
>> accès. Cette fragmentation là n'étant pas "réparable" à chaud.
>>
>> A +
>>
>>
>>
>>> Merci.
>>>
>>> "SQLpro [MVP]" a écrit :
>>>
>>>> carjo12 a écrit :
>>>>> Bonjour
>>>>>
>>>>> Je souhaite maintenir une quantité de données stable dans ma base de données
>>>>> ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
>>>>> à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
>>>>> ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
>>>>> procédures suivantes :
>>>>>
>>>>> 1. SUPPRESSION d’un nombre déterminé de données ;
>>>>> 2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
>>>>> 3. DBCC SHRINKDATABASE (@nomBD);
>>>>> 4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
>>>>>
>>>>> Par la suite, le journal des transactions reprend l’espace disponible
>>>>> initial désiré.
>>>>>
>>>>> Par contre, l’espace disponible du fichier des données de semble pas
>>>>> changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
>>>>> données (la base de données devient saturée).
>>>>>
>>>>> Auriez-vous une solution à ce problème ?
>>>> D'abord il ne s'agit nullement d'un problème, du comportement sain d'un
>>>> SGBDR performant...
>>>>
>>>> Pour cela il faudrait défragmenter les différents index, ainsi que les
>>>> espaces morts relevant de colonnes supprimées par le DLL.
>>>>
>>>> DBCC INDEXDEFRAG, DBREINDEX...
>>>> DBCC CLEANTABLE
>>>> ....
>>>>
>>>> Mais j'attire votre attention sur le fait que restreindre, augmenter ou
>>>> diminuer la taille des fichiers de la base de données, nuit
>>>> considérablement aux performances, car cela créée de la fragmentation
>>>> physique des fichiers de données, outre le fait que cela n'a aucun
>>>> intérêt et qu'il vaut mieux, pour de très nombreuses raisons, créer des
>>>> fichiers de données de taille fixe, dont le volume doit être estimé à la
>>>> capacité à terme de la base de données (par exemple 3 à 5 années
>>>> d'exploitation).
>>>>
>>>> A +
>>>>
>>>>> Merci pour toute aide.
>>>>>
>>>> --
>>>> 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 ***********************
>>
--
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 beaucoup pour les informations, je crois que c’est sur la bonne voie.
Juste un détail :
Après une suppression, ou après une erreur 1105 (plus de place dans le
segment de données), j’ai implémenté :
• DBCC INDEXDEFRAG sur les index concernés;
• BACKUP LOG maBD WITH TRUNCATE_ONLY;
• DBCC SHRINKFILE (maBD_Log);
• FULL BACKUP formaté de maBD.
J’ai fait le test sur 2 postes différents, mas avec le même système
d’exploitation, même ServicePack, etc. La seule différence, c’est que
d’autres programmes roulent sur l’un des postes.
• Sur le premier poste, ça semble fonctionner parfaitement (jamais d’erreur
11105).
• Sur l’autre poste, après ces 4 opérations tout semble correct. Par la
suite, une seule nouvelle insertion semble grossir le fichier de données trop
rapidement (d’où l’erreur 1105), et ainsi de suite. Est-ce parce que
d’autres programmes roulent simultanément à l’insertion et s’accapare
l’espace disponible ?
Auriez-vous une idée de ce qui différencie ces 2 « comportements » ?
D’autre part, sur les deux postes, après l’opération de défragmentation, le
fichier log devient très grand, même avec SP4 de SQL SERVER2000, sensé
corriger ce bug. Je dois prévoir une troncature du fichier journal lors de
la défragmentation pour que celle-ci s’accomplisse, ou alors je dois
augmenter la taille de départ fixe du LOG…
Merci.
"SQLpro [MVP]" a écrit :carjo12 a écrit :Merci pour l'information. J'ai refait le test, sans attribuer une croissance
auto au fichier de données, avec les paramètres que j'ai donné en exemple
dans ma dernière réponse. Malheureusement, ça n'a pas réglé le
SHRINKDATABASE: à un moment donnée, l'insertion n'est plus possible.
Dois-je expérimenter avev les commandes DBCC INDEXDEFRAG, DBREINDEX,
DBCC CLEANTABLE ?
Pour la base, prévoir la taille à terme et sruveiller régulièrement.
par exemple compta sur 5 ans, environ 60 Go
Pour le JT prévoir large (1/3 de la base à terme) par exemple 20 Go
Faire un SHRINKFILE après avoir sauvegardé le JT
Ne JAMAIS fair de SHRINKDATABASE
A +Merci.
"SQLpro [MVP]" a écrit :carjo12 a écrit :Si je comprends, bien, il est préférable que, lors de la création de la base
de données, d'attribuer par exemple une taille de 500 Mo, sans croissance
automatique, au lieu d'une taille de 27 Mo avec une croissance de 50 Mo ?
Chaque opération de croissance est une opération lourde qui
statistiquement toutes les chances de se produire au plus mauvais moment
(charge maximum) pénalisant encore plus les traitements et distandant
les temps de réponse et la durée des transaction.
Une opération de disque coute environ 10 000 à 100 000 fois le temps
d'une instruction CPU.
De plus avec une stratégie de croissance auto, les fichiers ont toutes
les chances d'être physiquement fragmentés... donc moins rapide en
accès. Cette fragmentation là n'étant pas "réparable" à chaud.
A +Merci.
"SQLpro [MVP]" a écrit :carjo12 a écrit :Bonjour
Je souhaite maintenir une quantité de données stable dans ma base de données
ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
procédures suivantes :
1. SUPPRESSION d’un nombre déterminé de données ;
2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
3. DBCC SHRINKDATABASE (@nomBD);
4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
Par la suite, le journal des transactions reprend l’espace disponible
initial désiré.
Par contre, l’espace disponible du fichier des données de semble pas
changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
données (la base de données devient saturée).
Auriez-vous une solution à ce problème ?
D'abord il ne s'agit nullement d'un problème, du comportement sain d'un
SGBDR performant...
Pour cela il faudrait défragmenter les différents index, ainsi que les
espaces morts relevant de colonnes supprimées par le DLL.
DBCC INDEXDEFRAG, DBREINDEX...
DBCC CLEANTABLE
....
Mais j'attire votre attention sur le fait que restreindre, augmenter ou
diminuer la taille des fichiers de la base de données, nuit
considérablement aux performances, car cela créée de la fragmentation
physique des fichiers de données, outre le fait que cela n'a aucun
intérêt et qu'il vaut mieux, pour de très nombreuses raisons, créer des
fichiers de données de taille fixe, dont le volume doit être estimé à la
capacité à terme de la base de données (par exemple 3 à 5 années
d'exploitation).
A +Merci pour toute aide.
--
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 ***********************
--
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 beaucoup pour les informations, je crois que c’est sur la bonne voie.
Juste un détail :
Après une suppression, ou après une erreur 1105 (plus de place dans le
segment de données), j’ai implémenté :
• DBCC INDEXDEFRAG sur les index concernés;
• BACKUP LOG maBD WITH TRUNCATE_ONLY;
• DBCC SHRINKFILE (maBD_Log);
• FULL BACKUP formaté de maBD.
J’ai fait le test sur 2 postes différents, mas avec le même système
d’exploitation, même ServicePack, etc. La seule différence, c’est que
d’autres programmes roulent sur l’un des postes.
• Sur le premier poste, ça semble fonctionner parfaitement (jamais d’erreur
11105).
• Sur l’autre poste, après ces 4 opérations tout semble correct. Par la
suite, une seule nouvelle insertion semble grossir le fichier de données trop
rapidement (d’où l’erreur 1105), et ainsi de suite. Est-ce parce que
d’autres programmes roulent simultanément à l’insertion et s’accapare
l’espace disponible ?
Auriez-vous une idée de ce qui différencie ces 2 « comportements » ?
D’autre part, sur les deux postes, après l’opération de défragmentation, le
fichier log devient très grand, même avec SP4 de SQL SERVER2000, sensé
corriger ce bug. Je dois prévoir une troncature du fichier journal lors de
la défragmentation pour que celle-ci s’accomplisse, ou alors je dois
augmenter la taille de départ fixe du LOG…
Merci.
"SQLpro [MVP]" a écrit :
carjo12 a écrit :
Merci pour l'information. J'ai refait le test, sans attribuer une croissance
auto au fichier de données, avec les paramètres que j'ai donné en exemple
dans ma dernière réponse. Malheureusement, ça n'a pas réglé le
SHRINKDATABASE: à un moment donnée, l'insertion n'est plus possible.
Dois-je expérimenter avev les commandes DBCC INDEXDEFRAG, DBREINDEX,
DBCC CLEANTABLE ?
Pour la base, prévoir la taille à terme et sruveiller régulièrement.
par exemple compta sur 5 ans, environ 60 Go
Pour le JT prévoir large (1/3 de la base à terme) par exemple 20 Go
Faire un SHRINKFILE après avoir sauvegardé le JT
Ne JAMAIS fair de SHRINKDATABASE
A +
Merci.
"SQLpro [MVP]" a écrit :
carjo12 a écrit :
Si je comprends, bien, il est préférable que, lors de la création de la base
de données, d'attribuer par exemple une taille de 500 Mo, sans croissance
automatique, au lieu d'une taille de 27 Mo avec une croissance de 50 Mo ?
Chaque opération de croissance est une opération lourde qui
statistiquement toutes les chances de se produire au plus mauvais moment
(charge maximum) pénalisant encore plus les traitements et distandant
les temps de réponse et la durée des transaction.
Une opération de disque coute environ 10 000 à 100 000 fois le temps
d'une instruction CPU.
De plus avec une stratégie de croissance auto, les fichiers ont toutes
les chances d'être physiquement fragmentés... donc moins rapide en
accès. Cette fragmentation là n'étant pas "réparable" à chaud.
A +
Merci.
"SQLpro [MVP]" a écrit :
carjo12 a écrit :
Bonjour
Je souhaite maintenir une quantité de données stable dans ma base de données
ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
procédures suivantes :
1. SUPPRESSION d’un nombre déterminé de données ;
2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
3. DBCC SHRINKDATABASE (@nomBD);
4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
Par la suite, le journal des transactions reprend l’espace disponible
initial désiré.
Par contre, l’espace disponible du fichier des données de semble pas
changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
données (la base de données devient saturée).
Auriez-vous une solution à ce problème ?
D'abord il ne s'agit nullement d'un problème, du comportement sain d'un
SGBDR performant...
Pour cela il faudrait défragmenter les différents index, ainsi que les
espaces morts relevant de colonnes supprimées par le DLL.
DBCC INDEXDEFRAG, DBREINDEX...
DBCC CLEANTABLE
....
Mais j'attire votre attention sur le fait que restreindre, augmenter ou
diminuer la taille des fichiers de la base de données, nuit
considérablement aux performances, car cela créée de la fragmentation
physique des fichiers de données, outre le fait que cela n'a aucun
intérêt et qu'il vaut mieux, pour de très nombreuses raisons, créer des
fichiers de données de taille fixe, dont le volume doit être estimé à la
capacité à terme de la base de données (par exemple 3 à 5 années
d'exploitation).
A +
Merci pour toute aide.
--
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 ***********************
--
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 beaucoup pour les informations, je crois que c’est sur la bonne voie.
Juste un détail :
Après une suppression, ou après une erreur 1105 (plus de place dans le
segment de données), j’ai implémenté :
• DBCC INDEXDEFRAG sur les index concernés;
• BACKUP LOG maBD WITH TRUNCATE_ONLY;
• DBCC SHRINKFILE (maBD_Log);
• FULL BACKUP formaté de maBD.
J’ai fait le test sur 2 postes différents, mas avec le même système
d’exploitation, même ServicePack, etc. La seule différence, c’est que
d’autres programmes roulent sur l’un des postes.
• Sur le premier poste, ça semble fonctionner parfaitement (jamais d’erreur
11105).
• Sur l’autre poste, après ces 4 opérations tout semble correct. Par la
suite, une seule nouvelle insertion semble grossir le fichier de données trop
rapidement (d’où l’erreur 1105), et ainsi de suite. Est-ce parce que
d’autres programmes roulent simultanément à l’insertion et s’accapare
l’espace disponible ?
Auriez-vous une idée de ce qui différencie ces 2 « comportements » ?
D’autre part, sur les deux postes, après l’opération de défragmentation, le
fichier log devient très grand, même avec SP4 de SQL SERVER2000, sensé
corriger ce bug. Je dois prévoir une troncature du fichier journal lors de
la défragmentation pour que celle-ci s’accomplisse, ou alors je dois
augmenter la taille de départ fixe du LOG…
Merci.
"SQLpro [MVP]" a écrit :carjo12 a écrit :Merci pour l'information. J'ai refait le test, sans attribuer une croissance
auto au fichier de données, avec les paramètres que j'ai donné en exemple
dans ma dernière réponse. Malheureusement, ça n'a pas réglé le
SHRINKDATABASE: à un moment donnée, l'insertion n'est plus possible.
Dois-je expérimenter avev les commandes DBCC INDEXDEFRAG, DBREINDEX,
DBCC CLEANTABLE ?
Pour la base, prévoir la taille à terme et sruveiller régulièrement.
par exemple compta sur 5 ans, environ 60 Go
Pour le JT prévoir large (1/3 de la base à terme) par exemple 20 Go
Faire un SHRINKFILE après avoir sauvegardé le JT
Ne JAMAIS fair de SHRINKDATABASE
A +Merci.
"SQLpro [MVP]" a écrit :carjo12 a écrit :Si je comprends, bien, il est préférable que, lors de la création de la base
de données, d'attribuer par exemple une taille de 500 Mo, sans croissance
automatique, au lieu d'une taille de 27 Mo avec une croissance de 50 Mo ?
Chaque opération de croissance est une opération lourde qui
statistiquement toutes les chances de se produire au plus mauvais moment
(charge maximum) pénalisant encore plus les traitements et distandant
les temps de réponse et la durée des transaction.
Une opération de disque coute environ 10 000 à 100 000 fois le temps
d'une instruction CPU.
De plus avec une stratégie de croissance auto, les fichiers ont toutes
les chances d'être physiquement fragmentés... donc moins rapide en
accès. Cette fragmentation là n'étant pas "réparable" à chaud.
A +Merci.
"SQLpro [MVP]" a écrit :carjo12 a écrit :Bonjour
Je souhaite maintenir une quantité de données stable dans ma base de données
ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
procédures suivantes :
1. SUPPRESSION d’un nombre déterminé de données ;
2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
3. DBCC SHRINKDATABASE (@nomBD);
4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
Par la suite, le journal des transactions reprend l’espace disponible
initial désiré.
Par contre, l’espace disponible du fichier des données de semble pas
changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
données (la base de données devient saturée).
Auriez-vous une solution à ce problème ?
D'abord il ne s'agit nullement d'un problème, du comportement sain d'un
SGBDR performant...
Pour cela il faudrait défragmenter les différents index, ainsi que les
espaces morts relevant de colonnes supprimées par le DLL.
DBCC INDEXDEFRAG, DBREINDEX...
DBCC CLEANTABLE
....
Mais j'attire votre attention sur le fait que restreindre, augmenter ou
diminuer la taille des fichiers de la base de données, nuit
considérablement aux performances, car cela créée de la fragmentation
physique des fichiers de données, outre le fait que cela n'a aucun
intérêt et qu'il vaut mieux, pour de très nombreuses raisons, créer des
fichiers de données de taille fixe, dont le volume doit être estimé à la
capacité à terme de la base de données (par exemple 3 à 5 années
d'exploitation).
A +Merci pour toute aide.
--
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 ***********************
--
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 ***********************
carjo12 a écrit :
> Merci beaucoup pour les informations, je crois que c’est sur la bonne voie.
>
> Juste un détail :
>
> Après une suppression, ou après une erreur 1105 (plus de place dans le
> segment de données), j’ai implémenté :
>
> • DBCC INDEXDEFRAG sur les index concernés;
> • BACKUP LOG maBD WITH TRUNCATE_ONLY;
> • DBCC SHRINKFILE (maBD_Log);
> • FULL BACKUP formaté de maBD.
>
> J’ai fait le test sur 2 postes différents, mas avec le même système
> d’exploitation, même ServicePack, etc. La seule différence, c’est que
> d’autres programmes roulent sur l’un des postes.
>
> • Sur le premier poste, ça semble fonctionner parfaitement (jamais d’erreur
> 11105).
>
> • Sur l’autre poste, après ces 4 opérations tout semble correct. Par la
> suite, une seule nouvelle insertion semble grossir le fichier de données trop
> rapidement (d’où l’erreur 1105), et ainsi de suite. Est-ce parce que
> d’autres programmes roulent simultanément à l’insertion et s’accapare
> l’espace disponible ?
peut être, il faudrait auditer.
>
> Auriez-vous une idée de ce qui différencie ces 2 « comportements » ?
>
> D’autre part, sur les deux postes, après l’opération de défragmentation, le
> fichier log devient très grand, même avec SP4 de SQL SERVER2000, sensé
> corriger ce bug. Je dois prévoir une troncature du fichier journal lors de
> la défragmentation pour que celle-ci s’accomplisse, ou alors je dois
> augmenter la taille de départ fixe du LOG…
difficile de dire ce qui est le plus adéquat. mais un fichier de
transaction doit pouvoir s'allonger grandement.
Je prende en général 1/3 de la taille de la base à terme.
>
> Merci.
>
>
> "SQLpro [MVP]" a écrit :
>
>> carjo12 a écrit :
>>> Merci pour l'information. J'ai refait le test, sans attribuer une croissance
>>> auto au fichier de données, avec les paramètres que j'ai donné en exemple
>>> dans ma dernière réponse. Malheureusement, ça n'a pas réglé le
>>> SHRINKDATABASE: à un moment donnée, l'insertion n'est plus possible.
>>> Dois-je expérimenter avev les commandes DBCC INDEXDEFRAG, DBREINDEX,
>>> DBCC CLEANTABLE ?
>> Pour la base, prévoir la taille à terme et sruveiller régulièrement.
>> par exemple compta sur 5 ans, environ 60 Go
>>
>> Pour le JT prévoir large (1/3 de la base à terme) par exemple 20 Go
>> Faire un SHRINKFILE après avoir sauvegardé le JT
>>
>> Ne JAMAIS fair de SHRINKDATABASE
>>
>> A +
>>
>>
>>> Merci.
>>>
>>> "SQLpro [MVP]" a écrit :
>>>
>>>> carjo12 a écrit :
>>>>> Si je comprends, bien, il est préférable que, lors de la création de la base
>>>>> de données, d'attribuer par exemple une taille de 500 Mo, sans croissance
>>>>> automatique, au lieu d'une taille de 27 Mo avec une croissance de 50 Mo ?
>>>> Chaque opération de croissance est une opération lourde qui
>>>> statistiquement toutes les chances de se produire au plus mauvais moment
>>>> (charge maximum) pénalisant encore plus les traitements et distandant
>>>> les temps de réponse et la durée des transaction.
>>>> Une opération de disque coute environ 10 000 à 100 000 fois le temps
>>>> d'une instruction CPU.
>>>> De plus avec une stratégie de croissance auto, les fichiers ont toutes
>>>> les chances d'être physiquement fragmentés... donc moins rapide en
>>>> accès. Cette fragmentation là n'étant pas "réparable" à chaud.
>>>>
>>>> A +
>>>>
>>>>
>>>>
>>>>> Merci.
>>>>>
>>>>> "SQLpro [MVP]" a écrit :
>>>>>
>>>>>> carjo12 a écrit :
>>>>>>> Bonjour
>>>>>>>
>>>>>>> Je souhaite maintenir une quantité de données stable dans ma base de données
>>>>>>> ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
>>>>>>> à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
>>>>>>> ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
>>>>>>> procédures suivantes :
>>>>>>>
>>>>>>> 1. SUPPRESSION d’un nombre déterminé de données ;
>>>>>>> 2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
>>>>>>> 3. DBCC SHRINKDATABASE (@nomBD);
>>>>>>> 4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
>>>>>>>
>>>>>>> Par la suite, le journal des transactions reprend l’espace disponible
>>>>>>> initial désiré.
>>>>>>>
>>>>>>> Par contre, l’espace disponible du fichier des données de semble pas
>>>>>>> changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
>>>>>>> données (la base de données devient saturée).
>>>>>>>
>>>>>>> Auriez-vous une solution à ce problème ?
>>>>>> D'abord il ne s'agit nullement d'un problème, du comportement sain d'un
>>>>>> SGBDR performant...
>>>>>>
>>>>>> Pour cela il faudrait défragmenter les différents index, ainsi que les
>>>>>> espaces morts relevant de colonnes supprimées par le DLL.
>>>>>>
>>>>>> DBCC INDEXDEFRAG, DBREINDEX...
>>>>>> DBCC CLEANTABLE
>>>>>> ....
>>>>>>
>>>>>> Mais j'attire votre attention sur le fait que restreindre, augmenter ou
>>>>>> diminuer la taille des fichiers de la base de données, nuit
>>>>>> considérablement aux performances, car cela créée de la fragmentation
>>>>>> physique des fichiers de données, outre le fait que cela n'a aucun
>>>>>> intérêt et qu'il vaut mieux, pour de très nombreuses raisons, créer des
>>>>>> fichiers de données de taille fixe, dont le volume doit être estimé à la
>>>>>> capacité à terme de la base de données (par exemple 3 à 5 années
>>>>>> d'exploitation).
>>>>>>
>>>>>> A +
>>>>>>
>>>>>>> Merci pour toute aide.
>>>>>>>
>>>>>> --
>>>>>> 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 ***********************
>>>>
>>
>> --
>> 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 ***********************
carjo12 a écrit :
> Merci beaucoup pour les informations, je crois que c’est sur la bonne voie.
>
> Juste un détail :
>
> Après une suppression, ou après une erreur 1105 (plus de place dans le
> segment de données), j’ai implémenté :
>
> • DBCC INDEXDEFRAG sur les index concernés;
> • BACKUP LOG maBD WITH TRUNCATE_ONLY;
> • DBCC SHRINKFILE (maBD_Log);
> • FULL BACKUP formaté de maBD.
>
> J’ai fait le test sur 2 postes différents, mas avec le même système
> d’exploitation, même ServicePack, etc. La seule différence, c’est que
> d’autres programmes roulent sur l’un des postes.
>
> • Sur le premier poste, ça semble fonctionner parfaitement (jamais d’erreur
> 11105).
>
> • Sur l’autre poste, après ces 4 opérations tout semble correct. Par la
> suite, une seule nouvelle insertion semble grossir le fichier de données trop
> rapidement (d’où l’erreur 1105), et ainsi de suite. Est-ce parce que
> d’autres programmes roulent simultanément à l’insertion et s’accapare
> l’espace disponible ?
peut être, il faudrait auditer.
>
> Auriez-vous une idée de ce qui différencie ces 2 « comportements » ?
>
> D’autre part, sur les deux postes, après l’opération de défragmentation, le
> fichier log devient très grand, même avec SP4 de SQL SERVER2000, sensé
> corriger ce bug. Je dois prévoir une troncature du fichier journal lors de
> la défragmentation pour que celle-ci s’accomplisse, ou alors je dois
> augmenter la taille de départ fixe du LOG…
difficile de dire ce qui est le plus adéquat. mais un fichier de
transaction doit pouvoir s'allonger grandement.
Je prende en général 1/3 de la taille de la base à terme.
>
> Merci.
>
>
> "SQLpro [MVP]" a écrit :
>
>> carjo12 a écrit :
>>> Merci pour l'information. J'ai refait le test, sans attribuer une croissance
>>> auto au fichier de données, avec les paramètres que j'ai donné en exemple
>>> dans ma dernière réponse. Malheureusement, ça n'a pas réglé le
>>> SHRINKDATABASE: à un moment donnée, l'insertion n'est plus possible.
>>> Dois-je expérimenter avev les commandes DBCC INDEXDEFRAG, DBREINDEX,
>>> DBCC CLEANTABLE ?
>> Pour la base, prévoir la taille à terme et sruveiller régulièrement.
>> par exemple compta sur 5 ans, environ 60 Go
>>
>> Pour le JT prévoir large (1/3 de la base à terme) par exemple 20 Go
>> Faire un SHRINKFILE après avoir sauvegardé le JT
>>
>> Ne JAMAIS fair de SHRINKDATABASE
>>
>> A +
>>
>>
>>> Merci.
>>>
>>> "SQLpro [MVP]" a écrit :
>>>
>>>> carjo12 a écrit :
>>>>> Si je comprends, bien, il est préférable que, lors de la création de la base
>>>>> de données, d'attribuer par exemple une taille de 500 Mo, sans croissance
>>>>> automatique, au lieu d'une taille de 27 Mo avec une croissance de 50 Mo ?
>>>> Chaque opération de croissance est une opération lourde qui
>>>> statistiquement toutes les chances de se produire au plus mauvais moment
>>>> (charge maximum) pénalisant encore plus les traitements et distandant
>>>> les temps de réponse et la durée des transaction.
>>>> Une opération de disque coute environ 10 000 à 100 000 fois le temps
>>>> d'une instruction CPU.
>>>> De plus avec une stratégie de croissance auto, les fichiers ont toutes
>>>> les chances d'être physiquement fragmentés... donc moins rapide en
>>>> accès. Cette fragmentation là n'étant pas "réparable" à chaud.
>>>>
>>>> A +
>>>>
>>>>
>>>>
>>>>> Merci.
>>>>>
>>>>> "SQLpro [MVP]" a écrit :
>>>>>
>>>>>> carjo12 a écrit :
>>>>>>> Bonjour
>>>>>>>
>>>>>>> Je souhaite maintenir une quantité de données stable dans ma base de données
>>>>>>> ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
>>>>>>> à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
>>>>>>> ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
>>>>>>> procédures suivantes :
>>>>>>>
>>>>>>> 1. SUPPRESSION d’un nombre déterminé de données ;
>>>>>>> 2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
>>>>>>> 3. DBCC SHRINKDATABASE (@nomBD);
>>>>>>> 4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
>>>>>>>
>>>>>>> Par la suite, le journal des transactions reprend l’espace disponible
>>>>>>> initial désiré.
>>>>>>>
>>>>>>> Par contre, l’espace disponible du fichier des données de semble pas
>>>>>>> changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
>>>>>>> données (la base de données devient saturée).
>>>>>>>
>>>>>>> Auriez-vous une solution à ce problème ?
>>>>>> D'abord il ne s'agit nullement d'un problème, du comportement sain d'un
>>>>>> SGBDR performant...
>>>>>>
>>>>>> Pour cela il faudrait défragmenter les différents index, ainsi que les
>>>>>> espaces morts relevant de colonnes supprimées par le DLL.
>>>>>>
>>>>>> DBCC INDEXDEFRAG, DBREINDEX...
>>>>>> DBCC CLEANTABLE
>>>>>> ....
>>>>>>
>>>>>> Mais j'attire votre attention sur le fait que restreindre, augmenter ou
>>>>>> diminuer la taille des fichiers de la base de données, nuit
>>>>>> considérablement aux performances, car cela créée de la fragmentation
>>>>>> physique des fichiers de données, outre le fait que cela n'a aucun
>>>>>> intérêt et qu'il vaut mieux, pour de très nombreuses raisons, créer des
>>>>>> fichiers de données de taille fixe, dont le volume doit être estimé à la
>>>>>> capacité à terme de la base de données (par exemple 3 à 5 années
>>>>>> d'exploitation).
>>>>>>
>>>>>> A +
>>>>>>
>>>>>>> Merci pour toute aide.
>>>>>>>
>>>>>> --
>>>>>> 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 ***********************
>>>>
>>
>> --
>> 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 ***********************
carjo12 a écrit :
> Merci beaucoup pour les informations, je crois que c’est sur la bonne voie.
>
> Juste un détail :
>
> Après une suppression, ou après une erreur 1105 (plus de place dans le
> segment de données), j’ai implémenté :
>
> • DBCC INDEXDEFRAG sur les index concernés;
> • BACKUP LOG maBD WITH TRUNCATE_ONLY;
> • DBCC SHRINKFILE (maBD_Log);
> • FULL BACKUP formaté de maBD.
>
> J’ai fait le test sur 2 postes différents, mas avec le même système
> d’exploitation, même ServicePack, etc. La seule différence, c’est que
> d’autres programmes roulent sur l’un des postes.
>
> • Sur le premier poste, ça semble fonctionner parfaitement (jamais d’erreur
> 11105).
>
> • Sur l’autre poste, après ces 4 opérations tout semble correct. Par la
> suite, une seule nouvelle insertion semble grossir le fichier de données trop
> rapidement (d’où l’erreur 1105), et ainsi de suite. Est-ce parce que
> d’autres programmes roulent simultanément à l’insertion et s’accapare
> l’espace disponible ?
peut être, il faudrait auditer.
>
> Auriez-vous une idée de ce qui différencie ces 2 « comportements » ?
>
> D’autre part, sur les deux postes, après l’opération de défragmentation, le
> fichier log devient très grand, même avec SP4 de SQL SERVER2000, sensé
> corriger ce bug. Je dois prévoir une troncature du fichier journal lors de
> la défragmentation pour que celle-ci s’accomplisse, ou alors je dois
> augmenter la taille de départ fixe du LOG…
difficile de dire ce qui est le plus adéquat. mais un fichier de
transaction doit pouvoir s'allonger grandement.
Je prende en général 1/3 de la taille de la base à terme.
>
> Merci.
>
>
> "SQLpro [MVP]" a écrit :
>
>> carjo12 a écrit :
>>> Merci pour l'information. J'ai refait le test, sans attribuer une croissance
>>> auto au fichier de données, avec les paramètres que j'ai donné en exemple
>>> dans ma dernière réponse. Malheureusement, ça n'a pas réglé le
>>> SHRINKDATABASE: à un moment donnée, l'insertion n'est plus possible.
>>> Dois-je expérimenter avev les commandes DBCC INDEXDEFRAG, DBREINDEX,
>>> DBCC CLEANTABLE ?
>> Pour la base, prévoir la taille à terme et sruveiller régulièrement.
>> par exemple compta sur 5 ans, environ 60 Go
>>
>> Pour le JT prévoir large (1/3 de la base à terme) par exemple 20 Go
>> Faire un SHRINKFILE après avoir sauvegardé le JT
>>
>> Ne JAMAIS fair de SHRINKDATABASE
>>
>> A +
>>
>>
>>> Merci.
>>>
>>> "SQLpro [MVP]" a écrit :
>>>
>>>> carjo12 a écrit :
>>>>> Si je comprends, bien, il est préférable que, lors de la création de la base
>>>>> de données, d'attribuer par exemple une taille de 500 Mo, sans croissance
>>>>> automatique, au lieu d'une taille de 27 Mo avec une croissance de 50 Mo ?
>>>> Chaque opération de croissance est une opération lourde qui
>>>> statistiquement toutes les chances de se produire au plus mauvais moment
>>>> (charge maximum) pénalisant encore plus les traitements et distandant
>>>> les temps de réponse et la durée des transaction.
>>>> Une opération de disque coute environ 10 000 à 100 000 fois le temps
>>>> d'une instruction CPU.
>>>> De plus avec une stratégie de croissance auto, les fichiers ont toutes
>>>> les chances d'être physiquement fragmentés... donc moins rapide en
>>>> accès. Cette fragmentation là n'étant pas "réparable" à chaud.
>>>>
>>>> A +
>>>>
>>>>
>>>>
>>>>> Merci.
>>>>>
>>>>> "SQLpro [MVP]" a écrit :
>>>>>
>>>>>> carjo12 a écrit :
>>>>>>> Bonjour
>>>>>>>
>>>>>>> Je souhaite maintenir une quantité de données stable dans ma base de données
>>>>>>> ayant un fichier journal de 29 Mo min. et un fichier de données de 27 Mo min.
>>>>>>> à la création. Lorsque qu’elle atteint un nombre critique d'enregistrements,
>>>>>>> ce qui donne environ 25 Mo de données (quantité désirée), j’effectue les
>>>>>>> procédures suivantes :
>>>>>>>
>>>>>>> 1. SUPPRESSION d’un nombre déterminé de données ;
>>>>>>> 2. BACKUP LOG @nomBD WITH TRUNCATE_ONLY;
>>>>>>> 3. DBCC SHRINKDATABASE (@nomBD);
>>>>>>> 4. BACKUP COMPLET avec FORMAT des fichiers de données et journal.
>>>>>>>
>>>>>>> Par la suite, le journal des transactions reprend l’espace disponible
>>>>>>> initial désiré.
>>>>>>>
>>>>>>> Par contre, l’espace disponible du fichier des données de semble pas
>>>>>>> changer. À un moment donné, il n’est plus possible d’insérer de nouvelles
>>>>>>> données (la base de données devient saturée).
>>>>>>>
>>>>>>> Auriez-vous une solution à ce problème ?
>>>>>> D'abord il ne s'agit nullement d'un problème, du comportement sain d'un
>>>>>> SGBDR performant...
>>>>>>
>>>>>> Pour cela il faudrait défragmenter les différents index, ainsi que les
>>>>>> espaces morts relevant de colonnes supprimées par le DLL.
>>>>>>
>>>>>> DBCC INDEXDEFRAG, DBREINDEX...
>>>>>> DBCC CLEANTABLE
>>>>>> ....
>>>>>>
>>>>>> Mais j'attire votre attention sur le fait que restreindre, augmenter ou
>>>>>> diminuer la taille des fichiers de la base de données, nuit
>>>>>> considérablement aux performances, car cela créée de la fragmentation
>>>>>> physique des fichiers de données, outre le fait que cela n'a aucun
>>>>>> intérêt et qu'il vaut mieux, pour de très nombreuses raisons, créer des
>>>>>> fichiers de données de taille fixe, dont le volume doit être estimé à la
>>>>>> capacité à terme de la base de données (par exemple 3 à 5 années
>>>>>> d'exploitation).
>>>>>>
>>>>>> A +
>>>>>>
>>>>>>> Merci pour toute aide.
>>>>>>>
>>>>>> --
>>>>>> 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 ***********************
>>>>
>>
>> --
>> 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 ***********************