Petites Questions sur SqlServer

Version imprimable

20/01/2010, 11h32
ApprentiOracle

Petites Questions sur SqlServer

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
20/01/2010, 11h53
SQLpro

Citation:

Envoyé par 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 ?

SELECT compatibility_level FROM sys.databases

Citation:

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.

Citation:

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/

Citation:

Merci beaucoup pour vos réponses.

ApprentiOracle

A +
20/01/2010, 13h48
ApprentiOracle

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

Par contre la requete que vous m'avez donné ne me sort aucun resultat.
20/01/2010, 13h58
mikedavem

Citation:

Envoyé par ApprentiOracle

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 ?

++
20/01/2010, 14h05
ApprentiOracle

Citation:

Envoyé par mikedavem

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
20/01/2010, 14h16
mikedavem

Essayez ceci plutôt pour le moment :

Code:

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

Que vous donne ce résultat ?

++
20/01/2010, 14h31
ApprentiOracle

Citation:

Envoyé par mikedavem

Essayez ceci plutôt pour le moment :

Code:

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.
20/01/2010, 14h55
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:

SELECT SERVERPROPERTY('ProductLevel')

++
20/01/2010, 15h03
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.
20/01/2010, 15h06
Ptit_Dje

Citation:

Envoyé par 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:

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 !
20/01/2010, 15h12
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.
20/01/2010, 15h19
Ptit_Dje

Un backup du transaction log et ensuite un shrinkfile devrait à priori faire l'affaire...
20/01/2010, 15h58
ApprentiOracle

Citation:

Envoyé par Ptit_Dje

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.
20/01/2010, 16h15
mikedavem

Citation:

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 ?

++
20/01/2010, 16h19
ApprentiOracle

Citation:

Envoyé par mikedavem

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 ?
20/01/2010, 16h39
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...)
20/01/2010, 16h41
mikedavem

Citation:

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.

++
20/01/2010, 17h41
ApprentiOracle

Citation:

Envoyé par 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...)

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 ?
21/01/2010, 03h14
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 ;)

Citation:

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 ;)

@++ ;)
21/01/2010, 09h42
SQLpro

Ou bien passer en mode de journalisation simple !

A +
21/01/2010, 10h27
ApprentiOracle

Je vous tiens au courant pour la sauvegarde du log à 13h.
21/01/2010, 10h31
Ptit_Dje

Citation:

Envoyé par SQLpro

Ou bien passer en mode de journalisation simple !

A +

C'est effectivement une des possibilités que vous avez.
Afin de determiner si ce choix est judicieux, poser vous la question:
Quelle quantité de données (en terme de temps) peut on se permettre de perdre ?

Si la réponse est 1 jour, alors un full backup quotidien suffit et le mode de recovery peut être fixé à simple.

Si la réponse est inférieure à 1 jour, le temps de perte de donnée acceptable (1h, 3h, 6h...) sera la fréquence à laquelle vous devrez scheduler vos log backups. Dans ce cas, la base de données doit rester en full recovery model.

Pour ce qui est de la taille de votre log et son taux de remplissage, cela dépend de l'activité et des opérations effectuées sur votre base de données. Cependant, si le système à été laissé "à l'abandon" depuis un certain laps de temps et que le fichier est monté à 34GB, ne vous attendez pas à ce qu'il regrossisse autant en 1 jour...

Bonne journée
21/01/2010, 14h13
ApprentiOracle

La sauvegarde de mon fichier de log fait 236 ko...

Autrement dit l'activité de la base sur 1 journée ne me semble pas vraiment énorme ! :mrgreen:
22/01/2010, 11h15
SQLpro

Attention, car si vous rajoutez la défragmentation des index cela peut vite devenir énorme !

A +
25/01/2010, 11h39
elsuket

Et à ce moment là vous pouvez songer au mode de récupération BULK_LOGGED, qui minimalise la journalisation des opérations telles que la défragmentation d'indexes, le chargement de données, ...
Mais attention néanmoins, car sous ce mode, vous ne pourrez pas récupérer jusqu'à une date et heure précises.

@++ ;)