Taille limite SQL Server Express et purge données

Version imprimable

13/07/2009, 12h56
aliochk

Taille limite SQL Server Express et purge données

Bonjour,

Deux questions simples:

1/ Les 4Go maximum de la version express portent-ils sur le journal des transactions également?

2/ Le fait de supprimer des données régulièrement peut-ils m'éviter d'atteindre la limite de taille ou faut-il également effectuer des opérations de "shrink".

Merci pour vos réponses:lol::P
13/07/2009, 14h15
mikedavem

Bonjour,

Citation:

1/ Les 4Go maximum de la version express portent-ils sur le journal des transactions également?

Non, que sur les données.

Citation:

2/ Le fait de supprimer des données régulièrement peut-ils m'éviter d'atteindre la limite de taille ou faut-il également effectuer des opérations de "shrink".

L'opération SHRINK vous permettra seulement de réduire la taille de votre fichier si celui-ci contient de l'espace libre. Par conséquent il ne réduira pas la taille de vos données dans la base.

++
13/07/2009, 14h48
aliochk

Merci pour cette réponse si rapide :D:ccool:

Citation:

Envoyé par mikedavem

L'opération SHRINK vous permettra seulement de réduire la taille de votre fichier si celui-ci contient de l'espace libre. Par conséquent il ne réduira pas la taille de vos données dans la base.
++

La limitation porte donc bien sur les données et non pas leur place sur le disque ?

Enfin, pour revenir au problème de taille maximale la façon de procéder suivante est-elle efficace?

1/ Vérifier la place disponible (EXEC sp_spaceused)
2/ Si la taille est critique: supprimer les données les plus anciennes (archivées via un autre processus)

Ce qui m'inquiète c'est d'arriver à la taille limite du journal de transaction et donc de ne plus pouvoir effectuer d'opérations. D'ou la question du SHRINK?

Bonne journée et merci encore...
13/07/2009, 15h05
mikedavem

Citation:

La limitation porte donc bien sur les données et non pas leur place sur le disque ?

La limitation existe sur les fichiers de données de la base pour être plus précis.
Vous n'allez pas pouvoir créer un espace de fichier de données au déla de 4Go.

Citation:

Enfin, pour revenir au problème de taille maximale la façon de procéder suivante est-elle efficace?

1/ Vérifier la place disponible (EXEC sp_spaceused)
2/ Si la taille est critique: supprimer les données les plus anciennes (archivées via un autre processus)

Comme je vous l'ai dit le SHRINK réduira votre fichier s'il existe de l'espace libre. En aucun cas il ne supprimera vos données.

Effectivement vous allez devoir supprimer des données au fur et à mesure en vérifiant l'espace occupé par celles-ci. SQL Server Express n'est pas limité pour la taille du journal des transactions. Si vous êtes un mode de récupération FULL, vous pouvez par exemple passer en mode de récupération SIMPLE provisoirement lorsque vous supprimez vos données. (Bien sûr pensez à rebasculer en mode FULL + BACKUP)

Pensez également à dimensionner correctement vos journaux de transactions en fonction du volume de données supprimé.

++
13/07/2009, 16h07
aliochk

Ok, je commence a être largué :oops:

Pourquoi passer en mode récupération simple et ne pas y rester en permanence? Et ce d'autant plus qu'un backup/restore n'est pas une nécessité, les données étant archivées régulièrement sous un autre format.

Ensuite, je pensais avoir compris que:

1/ la limitation de 4Go ne porte que sur les donées. Pour limiter la taille de la BD je peux donc simplement supprimer des données au moyen de DELETE.

2/ pour éviter l'expansion du JT, je peux par exemple régulièrement effectuer:

Code:

DBCC SHRINKFILE(<Journal_Transaction>, 200)

ou éventuellement:

Code:

BACKUP LOG <MaBD> WITH TRUNCATE_ONLY

Cette dernière instruction n'étant nécessaire que si le mode de récupération de la base est "COMPLET / FULL " ou "JOURNALISE EN BLOC / BULK LOGGED", si j'en crois ce que j'ai pu lire ailleurs sur ce forum.

Suis-je encore loin du compte :?:roll: ?
13/07/2009, 16h16
mikedavem

Citation:

Pourquoi passer en mode récupération simple et ne pas y rester en permanence? Et ce d'autant plus qu'un backup/restore n'est pas une nécessité, les données étant archivées régulièrement sous un autre format.

Effectivement si vous n'avez aucune nécessité ou de contraintes de sauvegarde ou de reprise de données, restez en mode SIMPLE :).

Citation:

1/ la limitation de 4Go ne porte que sur les donées. Pour limiter la taille de la BD je peux donc simplement supprimer des données au moyen de DELETE.

Oui ou si vous supprimez toutes les données d'une table utilisez TRUNCATE TABLE qui est plus rapide et utilise moins de ressources du journal des transactions (à utiliser avec partimonie si vos tables sont référencés par d'autres tables et si vous avez des colonnes de type IDENTITY)

[QUOTE]2/ pour éviter l'expansion du JT, je peux par exemple régulièrement effectuer:

Citation:

Code:

DBCC SHRINKFILE(<Journal_Transaction>, 200)

Ceci est peu conseillé pour des questions de performance. Vous allez engendrer de la fragmentation au niveau de vos disques avec cet effet "Yoyo". Le journal grossit, je le réduis , le journal grossit à nouveau, je le réduis à nouveau, le journal ..... Au bout du compte, votre journal grossira tout le temps non ?

Il vaut mieux prévoir la place nécessaire pour votre journal et de laisser cette opération de SHRINKFILE pour des cas exceptionnels.

Citation:

Code:

BACKUP LOG <MaBD> WITH TRUNCATE_ONLY

Pourquoi pas si vous êtes en mode FULL ou BULK LOGGED mais comme vous l'avez dit vous n'avez pas d'impératif concernant vos sauvegardes.

En mode SIMPLE votre journal sera automatiquement tronqué. Cette commande n'est pas nécessaire.

++
14/07/2009, 09h22
aliochk

Parfait, merci pour ces réponses :ccool:

Je marque le sujet comme résolu

++
15/07/2009, 05h57
SQLpro
Une façon de procéder pour aller au dela de la taille de 4 Go est d'utiliser plusieurs bases. En effet, rien ne vous empêche d'avoir 100 bases de 4 Go.
De plus, vous pouvez faire des vues SQL qui font des UNION interbases. Exemple :
Code:

1 2 3 4 5 6 7 8 CREATE VIEW V_MaTable AS SELECT * FROM MaBase1..MaTable UNION ALL SELECT * FROM MaBase2..MaTable ...
Enfin, pour les mises à jour, rien ne vous empêche de faire des triggers INSTEAD OF sur les vues et rerouter les INSERT/UPDATE/DELETE vers la bonne base. Dans ce cas, il faut introduire un critère de partitionnement de vos vues, par exemple sur une colonne d'horodatage !

A +
15/07/2009, 12h12
aliochk

Merci pour cette dernière info... c'est effectivement une option à envisager

Je reviens cependant à ce qui a été dit plus haut:

Citation:

Envoyé par mikedavem

En mode SIMPLE votre journal sera automatiquement tronqué. Cette commande n'est pas nécessaire.
++

D'après les essais que j'ai pu faire, la taille du JT ne fait que s'étendre.
La troncature serait-elle effectuée de manière périodique ou sur seuil?

En outre, si la taille du JT est limitée j'obtiens:

Le journal des transactions de la base de données 'BD_TEST_SIZE' est plein. Pour savoir pourquoi il est impossible de réutiliser de l'espace dans le journal, consultez la colonne log_reuse_wait_desc dans sys.databases.

et l'opération n'est pas effectuée.
Je reviens donc (encore et toujours :lol: ) avec mon SHRINKFILE... Existe-t-il à ce propos une commande de défragmentation ?

++ ++
17/07/2009, 14h50
SQLpro

1) pour placer votre base de données en mode simple, faites :
ALTER DATABASE MaBase SET RECOVERY SIMPLE;

2) lire : http://sqlpro.developpez.com/cours/sqlserver/log/

A +
20/07/2009, 13h52
Zabriskir

Bonjour,

Citation:

D'après les essais que j'ai pu faire, la taille du JT ne fait que s'étendre.
La troncature serait-elle effectuée de manière périodique ou sur seuil?

Regardez l'option AUTO_SHRINK de votre base de données. Elle est à FAUX par défaut.

Zabriskir