Discussion :

[Jean-Philippe André]

Hello,

je rencontre une erreur pour laquell je n'arrive pas à trouver de solution :

je souhaite effectuer des sauvegardes complètes par tranche de 24h ainsi que des sauvegardes incrémentielles de façon plus fréquente.J'ai donc cherché à adapter les scripts proposés par fadace : http://fadace.developpez.com/mssql/sauve/

Mon script est actuellement le suivant :

Code :

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

1
2
backup database DB_OLYMPE_OLY to disk=N'D:\JPA\BDD\BACKUP\base.bak'
backup log DB_OLYMPE_OLY to disk=N'D:\JPA\BDD\BACKUP\log.bak'

La partie BACKUP DATABASE se déroule correctement

840 pages traitées pour la base de données 'DB_OLYMPE_OLY', fichier 'OLYMPE' dans le fichier 2.
1 pages traitées pour la base de données 'DB_OLYMPE_OLY', fichier 'OLYMPE_log' dans le fichier 2.
BACKUP DATABASE a traité avec succès 841 pages en 0.405*secondes (16.222*Mo/s).

par contre mon BACKUP LOG ne semble pas bien pris en compte.

L'instruction 'BACKUP LOG' n'est pas autorisée lorsque le modèle de récupération est SIMPLE. Faites appel à BACKUP DATABASE ou modifiez le modèle de récupération au moyen de ALTER DATABASE.

Dans l'interface SSMS, les propriétés de ma base m'indiquent dans la partie Fichier/Journal "OLYMPE_log" -> "Non applicable"

A quel niveau dois-je faire des modifications svp ?

Est-ce une case spécifique à cocher lors d'une installation ? ou bien un script SQL peut "activer" la génération de log ?

Merci d'avance

[Jean-Philippe André]

OK,
bon en fait c'est dans la partie Options des Propriétés, dans lae mode de récupération, à basculer à Complet semble-t-il

Après mise à jour dans SSMS cela fonctionne.

Reste la partie "lors de l'installation" et le script SQL possible pour basculer sur ce mode.

Le mode se met par script avec

Code :

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

1
2
ALTER DATABASE [DB_OLYMPE_OLY] SET RECOVERY FULL
GO

[SQLpro]

ATTENTION : vous confondes sauvegarde incrémentielles et sauvegardes des transactions. Rien à voir.

MS SQL Server propose 5 modes de sauvegardes :
1 complète
2 différentielle (depuis la dernière complète)
3 journal de transaction (depuis la dernière sauvegarde complète, différentielle ou JT)
4 fichier
5 groupe de fichier
Les 4 et 5 devant être combinées avec 1 et 2.

Seule la 3 nécessite une journalisation au niveau BULK LOADED ou mieux FULL.

En principe le mode dans lequel sont journalisées les transactions au moment de la création de la base dépend du positionnement de la base model qui sert d'"empreinte" à toute création de base.
Il suffit donc de basculer model en FULL (en principe elle y est lors de l'installation du serveur).

A +

A +

[Jean-Philippe André]

OK,
mais l'exemple de fadace en III-C correspond bien à une sauvegarde (tous les 1/4h par exemple), et une restauration en partant de la sauvegarde de la veille + "addition" des différentes transactions qui ont lieu depuis jusqu'à l'heure visée, non ?



je pensais qu'on arrivait à BDD J horaire X = BDD J-1 + transactions horaire X - 2 + transactions horaire X-1 come indiqué dans son exemple.

le différenciel n'est pas le contenu des transactions en fait ?

je pense que je m'y perds un peu

[SQLpro]

OUI, mais terminologiquement on ne peut pas parler de sauvegarde incrémentales.

En effet, il existait autrefois un mode de sauvegarde incrémentale basé sur les données de la base et non sur le JT. Ce mode a été supprimé.

A

[Jean-Philippe André]

OK, je comprends

merci bien, sujet clos

[kamuel]

Bonjour,

je suis débutant en SQLServer, actuellement je bosse sur sqlserver2005, j'ai bien suivie les forum et j'ai bien cherché sur d'autre forum, et mon problème concerne la diminution de la taille des logs .ldf, en executant ces requêtes :

select backup_start_date, backup_finish_date, type, recovery_model
from msdb.dbo.backupset where database_name = 'reduc_bdd'

ALTER DATABASE reduc_bdd SET RECOVERY SIMPLE
GO

select name from reduc_bdd.sys.database_files where Type_DESC='LOG'

dbcc auto_shrinkfile(' reduc_bdd_log ',50)

dbcc shrinkfile(' reduc_bdd_log ',50)


et ma question c'est que c'est vrai que j'arrive à reduire la taille des logs mais si un jours y aura un crache de server de base de données ,est il possible de réutiliser les derniers logs réduit pour revenir vers point souhaité.

et ma seconde question: est la diminution de la taille des logs=perte de l'information, si c'est le cas , pourqo=uoi je reduit la taille des logs


Cordialement