Discussion :

[aliochk]

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

[mikedavem]

Bonjour,

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

Non, que sur les données.

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.

++

[aliochk]

Merci pour cette réponse si rapide

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...

[mikedavem]

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.

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é.

++

[aliochk]

Ok, je commence a être largué

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

DBCC SHRINKFILE(<Journal_Transaction>, 200)

ou éventuellement:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

[mikedavem]

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 .

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:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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.

++

[aliochk]

Parfait, merci pour ces réponses

Je marque le sujet comme résolu

++

[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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 +

[aliochk]

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

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

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 ) avec mon SHRINKFILE... Existe-t-il à ce propos une commande de défragmentation ?

++ ++

[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 +

[Zabriskir]

Bonjour,

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