Discussion :

[ApprentiOracle]

Bonjour,

Je viens de reprendre l'administration de base SQLserver qui étaient en stand-by dans ma société.

J'ai donc plusieurs questions à vous poser ( après me les avoir posé moi-même )

1) Comment savoir dans quelle version de SQLServer sont mes bases ? 2000, 2005 ? Versions avant ?
2) Dans les plans de maintenances, les bases sont uniquement sauvegardées en total, à priori les sauvegardes du journal de transaction n' a pas lieu...
Cela veut t'il dire que si plantage d'une base se fait à 17h et que les sauvegardes ont lieu à 21h tous les soirs, on perdra les données entre 21h et 17h ?
3) J'ai des bases de données model,master et msdb. Faut il aussi les sauvegarder ? ET à quoi servent elles ?

Merci beaucoup pour vos réponses.

ApprentiOracle

[SQLpro]

Bonjour,

Je viens de reprendre l'administration de base SQLserver qui étaient en stand-by dans ma société.

J'ai donc plusieurs questions à vous poser ( après me les avoir posé moi-même )

1) Comment savoir dans quelle version de SQLServer sont mes bases ? 2000, 2005 ? Versions avant ?

SELECT compatibility_level FROM sys.databases

2) Dans les plans de maintenances, les bases sont uniquement sauvegardées en total, à priori les sauvegardes du journal de transaction n' a pas lieu...
Cela veut t'il dire que si plantage d'une base se fait à 17h et que les sauvegardes ont lieu à 21h tous les soirs, on perdra les données entre 21h et 17h ?

Pas forcément cela dépend de la nature du plantage et du mode de journalisaton de la base.

3) J'ai des bases de données model,master et msdb. Faut il aussi les sauvegarder ? ET à quoi servent elles ?

Ce sont les bases systèmes. Oui, il faut les sauvegarder (sauf model). Lisez les articles que j'ai écrit :
http://blog.developpez.com/sqlpro/p7...-ms-sql-serve/
http://blog.developpez.com/sqlpro/p7...ec-sql-server/
http://blog.developpez.com/sqlpro/p8...re-sauvegarde/

Merci beaucoup pour vos réponses.

ApprentiOracle

A +

[ApprentiOracle]

ok. A priori c'est l'outils osql.

Par contre la requete que vous m'avez donné ne me sort aucun resultat.

[mikedavem]

ok. A priori c'est l'outils osql.

Par contre la requete que vous m'avez donné ne me sort aucun resultat.

C'est à dire ? Sur quelle version de SQL Server êtes vous ?

++

[ApprentiOracle]

C'est à dire ? Sur quelle version de SQL Server êtes vous ?

++

Justement j'en sais rien, c'est ce que j'essaie d'obtenir.

A priori c'est un SQLserver avant 2005, car ospl fonctionne mais pas sqlcmd...

C'est pour cela que j'essaie de faire un osql -U user -p mdp -q "SELECT compatibility_level FROM sys.databases;"

La reponse du serveur c'est : Msg 208 Niveau 1-, Etat 1, serveur XXXX, ligne 1

[mikedavem]

Essayez ceci plutôt pour le moment :

Code :

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

osql -U user -P mdp -S serveur -q "SELECT @@version"

Que vous donne ce résultat ?

++

[ApprentiOracle]

Essayez ceci plutôt pour le moment :

Code :

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

osql -U user -P mdp -S serveur -q "SELECT @@version"

Que vous donne ce résultat ?

++

Merci MikeDavem

Microsoft SQL Server 2000 - 8.00.760 (Intel X86)
Dec 17 2002 14:22:05
Copy
right (c) 1988-2003 Microsoft Corporation
Standard Edition on Windows N
T 5.0 (Build 2195: Service Pack 4)

A priori il est donc possible de migrer ce serveur vers un sqlserver 2005, non ?

J'ai trouvé aussi comment lancé une requete, il faut mettre go après la requete.


merci beaucoup.

[mikedavem]

Oui c'est tout à fait possible.

Attention cependant : Il faut que vous soyez au moins en SP3 pour pouvoir migrer avec votre version en 2000.

Pour voir la le SP :

Code :

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

SELECT SERVERPROPERTY('ProductLevel')

++

[ApprentiOracle]

Il m'affiche bien le SP3. J'ai également vu qu il existait un conseillé de mise à niveau vers 2005, que j'ai téléchargé et que je compte lancer d'ici peu !

Si je jetais un oeil à tout ca, c'est parce que j'ai un fichier de logs qui fait 34 Go pour une base de 800 Mo... Et que mon disque arrive à saturation.

[Ptit_Dje]

Oui c'est tout à fait possible.

Attention cependant : Il faut que vous soyez au moins en SP3 pour pouvoir migrer avec votre version en 2000.

Pour voir la le SP :

Code :

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

SELECT SERVERPROPERTY('ProductLevel')

++

Ce site vous permet aussi de vérifier votre version grace au build:
http://www.sqlsecurity.com/FAQs/SQLS...3/Default.aspx

Concenant la votre: 8.00.760 c'est bien une SP3 !

[ApprentiOracle]

Ok, merci Ptit_Dje.

Il faut maintenant que je vois comment faire pour diminuer ce fichier ldf qui fait 34 Go ! C'est ma priorité avant de passer les multiples bases sous sqlserver 2005.

[Ptit_Dje]

Un backup du transaction log et ensuite un shrinkfile devrait à priori faire l'affaire...

[ApprentiOracle]

Un backup du transaction log et ensuite un shrinkfile devrait à priori faire l'affaire...

Le probleme c'est qu'il me reste très peu de place sur le disque dur.

Si je fais un backup de la log, va t'il me prendre la même place que la log en elle-meme ? car la le disque risque de saturer.

Pour info, je suis en mode complet avec sauvegarde totale chaque jour à 21h. Concernant la sauvegarde du journal des transactions, j'ai rien du tout.

[mikedavem]

Pour info, je suis en mode complet avec sauvegarde totale chaque jour à 21h. Concernant la sauvegarde du journal des transactions, j'ai rien du tout.

Vous n'implémentez pas de sauvegarde du journal à intervalle régulier ?

++

[ApprentiOracle]

Vous n'implémentez pas de sauvegarde du journal à intervalle régulier ?

++

Bas non ! Les bases ont vécues leur vie toutes seules jusqu'à que j'arrive.
Je fais un tour justement pour voir ce qui est problématique ! Et comme je suis débutant sous sqlserver ... Voila.

Résultat je viens de faire un backup des log avec truncate_only puis un dbcc shrinkfile...


Est ce que d'implémenter la sauvegarde journal diminue sa taille ?

[Ptit_Dje]

Non, ca ne diminuera pas sa taille.
Ca libere l'espace virtuellement pour de nouvelles écritures, à savoir que la portion du log qui aura été sauvée sera ré-écrite. Cependant ca ne libère pas l'espace physiquement sur le disque afin de limiter le nombre des appels système pour demander de l'espace disque ainsi que réduire la fragmentation du fichier.

Il est recommandé de ne pas réduire la taille physique du log pour les raisons ci-dessus. Un backup régulier permettant de libéré de l'espace au sein de ce fichier et permet de garder le fichier à une taille raisonnable.

Dans votre situation, j'aurai tendance à dire de passer les DB en single recovery mode de shrinker puis de remettre le mode full recovery... Cependant ce n'est pas la manière la plus propre et la moins risquée de procéder car s'il survient un incident, vous perdez vos données et le transaction log... Et devez revenir au précédent full backup.
Donc si vous trouvez un espace ou poser le log backup (qui risque effectivement d'etre gros!), procédez par un log backup puis un shrink, sinon vous avez une autre solution proposée, à utiliser avec précaution dans des cas bien particuliers (certains diront jamais...)

[mikedavem]

Est ce que d'implémenter la sauvegarde journal diminue sa taille ?

Non il ne le diminue pas mais il l'empêche de grossir indéfiniment .. si vous êtes en mode de récupération FULL ou BULKED LOGGED.
Dans ces 2 modes les transactions sont enregistrées au fur et à mesure. Le seul moyen de vider le journal pour que celui-ci puisse être réutilisé sans demander d'expansion est la sauvegarde de celui-ci à intervalle régulier. La fréquence dépend en général de la criticité que possède l'application hébergée sur le serveur SQL.

En mode simple le journal est automatiquement tronqué à intervalle régulier. C'est le seul mode où vous n'avez pas besoin d'implémenter une sauvegarde du journal.

++

[ApprentiOracle]

Non, ca ne diminuera pas sa taille.
Ca libere l'espace virtuellement pour de nouvelles écritures, à savoir que la portion du log qui aura été sauvée sera ré-écrite. Cependant ca ne libère pas l'espace physiquement sur le disque afin de limiter le nombre des appels système pour demander de l'espace disque ainsi que réduire la fragmentation du fichier.

Il est recommandé de ne pas réduire la taille physique du log pour les raisons ci-dessus. Un backup régulier permettant de libéré de l'espace au sein de ce fichier et permet de garder le fichier à une taille raisonnable.

Dans votre situation, j'aurai tendance à dire de passer les DB en single recovery mode de shrinker puis de remettre le mode full recovery... Cependant ce n'est pas la manière la plus propre et la moins risquée de procéder car s'il survient un incident, vous perdez vos données et le transaction log... Et devez revenir au précédent full backup.
Donc si vous trouvez un espace ou poser le log backup (qui risque effectivement d'etre gros!), procédez par un log backup puis un shrink, sinon vous avez une autre solution proposée, à utiliser avec précaution dans des cas bien particuliers (certains diront jamais...)

C'est trop tard j'ai fait mon backup log avec le truncate only puis le shrinkfile.

Bizarre, sous windows, il voit bien maintenant que le fichier fait 500 Mo (donc 13 Mo d'occupé) et que la partition a plus de 34 Go de libre.
J'ai implémenté une sauvegarde totale à 21h et une sauvegarde du journal à 13h.

Qu'en pensez-vous ? Vous pensez que demain 13h, la sauvegarde du log fera 33 Go ?

[elsuket]

Bonjour,

Un coup d'œil par ici vous aurait aidé
D'autre part SQLCMD est le remplaçant d'OSQL, et il a été introduit avec SQL Server 2005

Qu'en pensez-vous ? Vous pensez que demain 13h, la sauvegarde du log fera 33 Go ?

A vous de nous le dire, et si tel est le cas, envisagez des sauvegardes de votre journal plus fréquentes, et peut-être aussi l'utilisation de sauvegardes différentielles

@++

[SQLpro]

Ou bien passer en mode de journalisation simple !

A +