IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration SQL Server Discussion :

Base de données trop grosse / disque dur plein


Sujet :

Administration SQL Server

  1. #21
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    Octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Singapour

    Informations forums :
    Inscription : Octobre 2005
    Messages : 2 785
    Points : 9 716
    Points
    9 716
    Par défaut
    Citation Envoyé par aieeeuuuuu Voir le message
    1/
    Si aucune sauvegarde n'a jamais été effectuée sur cette base, et si vous ne vous souciez aucunement de la pérennité de vos données, si risquer de perdre l'ensemble vos données ne vous pose aucun souci particulier (et seulement dans ce cas), alors ...
    Quitte à faire ce que tu préconises, autant directement passer le Recovery Model à "Simple" (comme ça, plus de logs), et faire un SHRINK (pour réduire la taille du fichier ldf).

    Mais bon, c'est pas sans conséquences (et s'il ne comprend pas ce que cela implique, il vaut mieux éviter de lui conseiller cette approche).

    EDIT:
    D'ailleurs, ton DBCC SHRINKFILE essayera juste de récupérer de l'espace libre dans le fichier.

    Ce que tu décris, c'est plutôt :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    BACKUP LOG databasename WITH TRUNCATE_ONLY


    Citation Envoyé par haffey2 Voir le message
    Si tu ne veux pas m'aider, pas de problème, ne m'aide pas.
    Oui, je crois qu'on s'est mal compris : j'ai pas envie que tu te tires une balle dans le pied.

    Encore une fois : si tu ne sais pas à quoi servent les fichiers ldf et mdf (et pourquoi on te parle de faire des backups), alors ne touche à rien.

    Citation Envoyé par haffey2 Voir le message
    Mais garde ton arrogance pour toi. Quant à tes menaces ... j'en rigole dans ma barbe
    C'est surtout que tu donnes l'impression de vouloir une solution toute prête, sans comprendre ce que cela implique.

    Maintenant si au passage tu fais une connerie, je pense que tu rigoleras moins...
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  2. #22
    Modérateur

    Profil pro
    dba
    Inscrit en
    Janvier 2010
    Messages
    5 643
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : dba

    Informations forums :
    Inscription : Janvier 2010
    Messages : 5 643
    Points : 13 092
    Points
    13 092
    Par défaut
    Citation Envoyé par pcaboche Voir le message
    Quitte à faire ce que tu préconises, autant directement passer le Recovery Model à "Simple" (comme ça, plus de logs), et faire un SHRINK (pour réduire la taille du fichier ldf).

    Mais bon, c'est pas sans conséquences (et s'il ne comprend pas ce que cela implique, il vaut mieux éviter de lui conseiller cette approche).
    Je suis d'accord avec toi (et oui, j'ai oublié, passer en mode SIMPLE, tant qu'a faire...)
    Cependant, j'ai proposé cette solution (en précisant bien qu'elle n'était pas sans risque) car elle me parait contextuelle :
    1/ il n'y a pas de DBA --> leur BDD ne leur semble pas vitale
    2/ il n'y a pas de sauvegarde --> leurs données ne leur semblent pas vitale
    3/ on demande a quelqu'un qui ne connait pas de résoudre un problème d'espace disque --> comprendre l'utilité et le fonctionnement d'un SGBD sera sûrement très instructif, mais je ne sais pas s'il dispose du temps nécessaire pour le faire correctement.

    On demande visiblement à un plombier de réparer l’électricité. Je lui propose de mettre le fil rouge sur le bouton rouge, mais uniquement parce qu'il nous a plus ou moins fait comprendre que si ça prend feu ensuite, ce n'est pas un problème. Bien sûr, si en amont il y a une inversion de phase, ça va un peu piquer les doigts.

    Bien entendu, loi de murphy oblige, il y a de grandes chances que l'on voir revenir haffey2 dans peu de temps, en nous indiquant qu'il a eu un problème avec sa base de données et qu'il a tout perdu.
    Alors, à sa question :
    Citation Envoyé par haffey2 Voir le message
    Que dans mon cas, puisque je n'ai jamais fait de backup, il est trop tard pour faire quoique ce soit ?
    On ne pourra malheureusement plus que lui répondre... oui.

  3. #23
    Nouveau Candidat au Club
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Novembre 2014
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Technicien maintenance

    Informations forums :
    Inscription : Novembre 2014
    Messages : 18
    Points : 0
    Points
    0
    Par défaut
    L'image du plombier qui doit faire l'électricité est plutôt réaliste ... J'espère juste pouvoir résoudre ce problème (ou faire résoudre ce problème) et par la suite, être capable de maintenir mon système dans un état stable en y faisant des choses simples.
    Jusqu'à maintenant, personne dans notre entreprise ne s'était intéressé à la maintenance d'une base de données. Comme Aieeeuuuuu l'a dit, nos données ne sont surement pas vitale. Mais j'aimerais pouvoir en être certains.

    J'ai donc essayer de faire ce que SQLpro m'a conseillé, c'est à dire de faire dans un 1er temps le backup de ma BDD. Mais étant donné que je n'ai plus d'espace disque disponible, impossible de lancer cette opération. Impossible aussi de brancher un disque dur externe sur le serveur, celui-ci n'est pas reconnu (probablement à cause de l'absence de ressource). Je cherche donc une autre solution mais il est possible que je sois coincé.

  4. #24
    Membre expérimenté
    Homme Profil pro
    DBA SQL Server
    Inscrit en
    Octobre 2012
    Messages
    862
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : DBA SQL Server
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Octobre 2012
    Messages : 862
    Points : 1 736
    Points
    1 736
    Par défaut
    Tu ne sais vraiment pas le faire sur un autre disque sur le serveur ? Il n'y a qu'un disque sur ce serveur ?
    Ce que nous avons fait pour nous-même meurt avec nous, ce que nous avons fait pour les autres et le monde est immortel. Albert Pike

    http://www.datacrossroad.be

  5. #25
    Nouveau Candidat au Club
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Novembre 2014
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Technicien maintenance

    Informations forums :
    Inscription : Novembre 2014
    Messages : 18
    Points : 0
    Points
    0
    Par défaut
    Il y a un disque logique mais deux disques physiques en configuration RAID 1.

  6. #26
    Modérateur

    Profil pro
    dba
    Inscrit en
    Janvier 2010
    Messages
    5 643
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : dba

    Informations forums :
    Inscription : Janvier 2010
    Messages : 5 643
    Points : 13 092
    Points
    13 092
    Par défaut
    Citation Envoyé par haffey2 Voir le message
    par la suite, être capable de maintenir mon système dans un état stable
    C'est la première fois que vous évoquez cette problématique...

    Citation Envoyé par haffey2 Voir le message
    nos données ne sont surement pas vitale. Mais j'aimerais pouvoir en être certains.
    C'est sûrement la première question à se poser...
    Car si elles le sont, vous avez effectivement un gros problème !


    Citation Envoyé par haffey2 Voir le message
    Mais étant donné que je n'ai plus d'espace disque disponible, impossible de lancer cette opération.
    Ce n'est pas conseillé dans un plan de maintenance (que, j'en suis certains, vous mettrez en place très prochainement ), cependant, vous pouvez effectuer une sauvegarde sur le réseau, en spécifiant un chemin UNC (\\Serveur\Repertoire\monBackup.bak).
    Il faut que le compte de service de l'agent SQL ait les droits suffisants sur ce répertoire.

  7. #27
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    Octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Singapour

    Informations forums :
    Inscription : Octobre 2005
    Messages : 2 785
    Points : 9 716
    Points
    9 716
    Par défaut
    Citation Envoyé par aieeeuuuuu Voir le message
    2/ il n'y a pas de sauvegarde --> leurs données ne leur semblent pas vitale
    Je pense surtout que le premier serveur a un backup (ce qui expliquerait que le fichier de logs soit plus petit), mais pas le second.

    Le second serveur est vraisemblablement un serveur de secours.

    Tant que le premier serveur tourne, il y a un backup de fait sur celui-ci. Le problème, c'est que si le premier serveur tombe en panne, celui-ci n'a plus de backup.

    Le DBA n'a pas pris ce scénario en compte (ou il n'a pas eu le temps, ou il s'est barré en voyant l'organisation m*rdique de la boite...), et personne dans la boite n'est en charge des données.

    On dit au un technicien de maintenance, "hé, y'a un problème sur le deuxième serveur, démerde-toi !".

    Désepéré, il va sur un forum où un fou furieux lui dit "si tu ne comprends pas ce que tu fais, tu ne touches pas !"

    Pour couronner le tout, même s'il le voulait, il ne peut pas mettre en place de backup sur le serveur numéro 2... (même pas un lecteur réseau ? )

    Et maintenant, le technicien de maintenance vient d'être promu DBA malgré lui...
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  8. #28
    Modérateur

    Profil pro
    dba
    Inscrit en
    Janvier 2010
    Messages
    5 643
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : dba

    Informations forums :
    Inscription : Janvier 2010
    Messages : 5 643
    Points : 13 092
    Points
    13 092
    Par défaut
    Citation Envoyé par pcaboche Voir le message
    Je pense surtout que le premier serveur a un backup (ce qui expliquerait que le fichier de logs soit plus petit), mais pas le second.

    Le second serveur est vraisemblablement un serveur de secours.
    C'est marrant, j'avais imaginé un autre scénario :
    Le serveur qui rencontre le problème est actif.
    L'autre dors dans un coin depuis deux ans, avec des données d'il y a deux ans et aucune activité, ce qui explique que le fichier de log ne grossisse pas...

    comme quoi, tout est possible

  9. #29
    Nouveau Candidat au Club
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Novembre 2014
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Technicien maintenance

    Informations forums :
    Inscription : Novembre 2014
    Messages : 18
    Points : 0
    Points
    0
    Par défaut
    Citation Envoyé par aieeeuuuuu Voir le message

    C'est sûrement la première question à se poser...
    Car si elles le sont, vous avez effectivement un gros problème !
    Ce qui me fait penser que ces données ne sont pas vitales, c'est qu'aujourd'hui, mon serveur " plein " est déconnecté du réseau, avec toutes ses applications fermées. Donc en ce moment même, mon système tourne uniquement grâce à mon 2em serveur (celui où le fichier historian.ldf ne fait que 102Mo).

  10. #30
    Nouveau Candidat au Club
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Novembre 2014
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Technicien maintenance

    Informations forums :
    Inscription : Novembre 2014
    Messages : 18
    Points : 0
    Points
    0
    Par défaut
    J'ai donc essayé de faire des backups de différente manière, mais étant donné que mon espace disque était de 0 byte, je ne pouvais rien faire. Même MS SQL ne voulait plus se lancer à la fin.

    J'ai donc opter pour la commande DBCC SHRKINKFILE. Ca n'a malheureusement libérer que très peu d'espace (d'après ce que j'ai compris, étant donné que je n'ai pas fait de backup sur cette base, c'est normal que cette requête ne libère que peu d'espace).

    Finalement, j'ai résolu mon problème de la manière suivante :

    Dans SQL, j'ai sélectionné ma BDD -> Tasks -> Detach -> OK
    J'ai ensuite renommé mon fichier historian.Idf
    Dans SQL, j'ai sélectionné ma BDD -> Attach -> Add -> j'ai sélectionné historian.mdf
    Puis j'ai supprimé mon ancien fichier de 50Go

    Bon je suis conscient de la barbarie de cette manip, mais je pense que je n'avais pas le choix.

    Par contre, j'aimerais faire les choses correctement maintenant. J'aimerai maintenir mes BDD dans un état stable.

    Si vous avez des conseils, ou des contenus à partager sur ce sujet là, je suis vraiment preneur. Je vais commencer par faire des backup full et backup log régulièrement comme SQLpro m'a conseillé au début du topic.

  11. #31
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    Octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Singapour

    Informations forums :
    Inscription : Octobre 2005
    Messages : 2 785
    Points : 9 716
    Points
    9 716
    Par défaut
    Citation Envoyé par haffey2 Voir le message
    J'ai donc opter pour la commande DBCC SHRKINKFILE. Ca n'a malheureusement libérer que très peu d'espace (d'après ce que j'ai compris, étant donné que je n'ai pas fait de backup sur cette base, c'est normal que cette requête ne libère que peu d'espace).
    C'est exact.

    Citation Envoyé par haffey2 Voir le message
    Bon je suis conscient de la barbarie de cette manip, mais je pense que je n'avais pas le choix.
    Si :
    - passage au Recovery Model "Simple" (normalement, le fichier .ldf reste de la même taille, mais est constitué principalement d'espace "vide")
    - puis SHRINKFILE (pour libérer l'espace)

    On en avait parlé précédemment.

    Citation Envoyé par haffey2 Voir le message
    Par contre, j'aimerais faire les choses correctement maintenant. J'aimerai maintenir mes BDD dans un état stable.
    Pour cela, il faut faire ça :

    Citation Envoyé par haffey2 Voir le message
    Je vais commencer par faire des backup full et backup log régulièrement comme SQLpro m'a conseillé au début du topic.
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  12. #32
    Membre expérimenté
    Homme Profil pro
    DBA SQL Server
    Inscrit en
    Octobre 2012
    Messages
    862
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : DBA SQL Server
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Octobre 2012
    Messages : 862
    Points : 1 736
    Points
    1 736
    Par défaut
    Je ne me souviens plus exactement du contenu, mais si tu veux :

    Ce que nous avons fait pour nous-même meurt avec nous, ce que nous avons fait pour les autres et le monde est immortel. Albert Pike

    http://www.datacrossroad.be

  13. #33
    Nouveau Candidat au Club
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Novembre 2014
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Technicien maintenance

    Informations forums :
    Inscription : Novembre 2014
    Messages : 18
    Points : 0
    Points
    0
    Par défaut
    Bonjour,

    J'ai donc tenter de réaliser mes backups sur mes BDD.

    Cependant, j'ai remarqué que mon recovery model était en mode SIMPLE maintenant sur mon SRV 1 (probablement à cause de ma manip barbare).

    Sur mon 2em serveur, je suis toujours en mode FULL. J'ai donc réalisé un back full et un backup log. Je ne sais pas si c'est OK, mais les deux backup semblent être sur le même fichier. Mais quand je visualise le contenu, je vois bien deux lignes : une ligne full et une ligne log. C'est bon ça ?

    Du coup ça m'embête un peu d'avoir modifier le mode de recovery, je me dis que si c'était en mode full à l'origine, c'est qu'il y avait une raison. Et ça m'embête d'avoir une configuration différente sur mes deux serveurs.

    Qu'en pensez vous ?

  14. #34
    Membre expérimenté
    Homme Profil pro
    DBA SQL Server
    Inscrit en
    Octobre 2012
    Messages
    862
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Belgique

    Informations professionnelles :
    Activité : DBA SQL Server
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : Octobre 2012
    Messages : 862
    Points : 1 736
    Points
    1 736
    Par défaut
    Tu peux passer ta DB en mode FULL si tu veux vraiment.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    USE master;
    ALTER DATABASE lenomdetadb SET RECOVERY FULL;
    Ce que nous avons fait pour nous-même meurt avec nous, ce que nous avons fait pour les autres et le monde est immortel. Albert Pike

    http://www.datacrossroad.be

  15. #35
    Rédacteur
    Avatar de pcaboche
    Homme Profil pro
    Inscrit en
    Octobre 2005
    Messages
    2 785
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Singapour

    Informations forums :
    Inscription : Octobre 2005
    Messages : 2 785
    Points : 9 716
    Points
    9 716
    Par défaut
    Citation Envoyé par haffey2 Voir le message
    je me dis que si c'était en mode full à l'origine, c'est qu'il y avait une raison.
    Deux cas de figure :
    1. c'est parfaitement réfléchi
    2. parce que c'est le mode par défaut

    Quand c'est réfléchi, alors il y a des backups de planifiés.

    Mais comme ce n'est pas le cas, alors réponse 2.

    Souvent, ce qui arrive : sur une machine de développement/test, on ne pense pas à faire des backup (parce que pas besoin), le mode par défaut est "Full", on fait beaucoup de tests de charge, ça remplit les logs, ça remplit le disque dur...
    Et après, le dev se demande : "mais pourquoi mon disque dur est plein ?"
    "On en a vu poser les armes avant de se tirer une balle dans le pied..."
    -- pydévelop

    Derniers articles:

    (SQL Server) Introduction à la gestion des droits
    (UML) Souplesse et modularité grâce aux Design Patterns
    (UML) Le Pattern Etat
    Autres articles...

  16. #36
    Nouveau Candidat au Club
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Novembre 2014
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Technicien maintenance

    Informations forums :
    Inscription : Novembre 2014
    Messages : 18
    Points : 0
    Points
    0
    Par défaut
    Bonjour,

    J'aimerais mettre en place des backups automatique à fréquence régulière. J'ai trouvé ce petit tuto qui me parait pas mal :
    http://support.microsoft.com/kb/930615/fr

    Qu'en pensez vous ? Je peux mettre ça en place ?

    Parmis mes installations, j'ai un serveur qui gère de la vidéosurveillance, il y a une petite base de données dessus. J'ai fais des recherches et j'ai vu qu'il y a avait des backup full et backup log de planifier. Le backup full se fait toutes les 24h, le backup log se fait toutes les heures. Que pensez vous de ces fréquences ?

  17. #37
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 741
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 741
    Points : 52 454
    Points
    52 454
    Billets dans le blog
    5
    Par défaut
    Oui, c'est pas mal.

    Si vous êtes sous Express, ceci est à planifier via le planificateur de tâche de Windows en commande SQL en ligne via SQLcmd.
    Pour toute autre édition, utilisez l'Agent SQL

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  18. #38
    Nouveau Candidat au Club
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Novembre 2014
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Technicien maintenance

    Informations forums :
    Inscription : Novembre 2014
    Messages : 18
    Points : 0
    Points
    0
    Par défaut
    Je ne crois pas être sous Express (cf : voir mes premiers posts)

    Microsoft SQL Server 2005 - 9.00.2047.00 (Intel X86) Apr 14 2006 01:12:25 Copyright (c) 1988-2005 Microsoft Corporation Standard Edition on Windows NT 5.2 (Build 3790: Service Pack 2)

  19. #39
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 741
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 741
    Points : 52 454
    Points
    52 454
    Billets dans le blog
    5
    Par défaut
    Donc planification via l'Agent SQL.
    Pensez à mettre en place une alerte par mail au cas ou les sauvegardes ne s'effectuent pas.
    Pensez aussi à mettre en place un opérateur de prévention de la défaillance au cas ou la base msdb qui héberge les tâches de l'Agent soit non opérationnelle.

    Au mieux, lisez le chapitre consacré à l'Agent SQL dans mon livre sur SQL Server, vous y trouverez toutes les explications... http://www.amazon.fr/SQL-Server-2014...server+brouard

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  20. #40
    Nouveau Candidat au Club
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Novembre 2014
    Messages
    18
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Technicien maintenance

    Informations forums :
    Inscription : Novembre 2014
    Messages : 18
    Points : 0
    Points
    0
    Par défaut
    Alors voilà, je pense avoir réussi à mettre en place mes backup planifiés :

    - dans l'Agent SQL, j'ai bien mes deux JOBS (un pour le backup full et un pour le backup log)
    - Quand je visualise le contenu de mon fichier de backup, je vois bien mon backup full ainsi que mes backups log à chaque heure fixe

    Par contre, je me demande comment va évoluer mon fichier de backup ? Est ce que mon futur backup full va venir écraser mon ancien ? Ou est ce que je vais me retrouvé avec un fichier de backup énorme dans une semaine ? (je n'ai rien configuré de particulier, j'espère que ça va s'écraser au fur et à mesure).

    Au pire, je verrais demain à 12h00, heure de mon prochain backupfull ...

Discussions similaires

  1. Base de données trop grosse pour sql
    Par creale10 dans le forum Oracle
    Réponses: 2
    Dernier message: 08/12/2006, 11h25
  2. Base de donnée très grosse 1 gig et sans raison
    Par kissmytoe dans le forum Access
    Réponses: 5
    Dernier message: 29/03/2006, 08h31
  3. [Récupération]Base de données après problème disque
    Par Cyborg289 dans le forum MS SQL Server
    Réponses: 4
    Dernier message: 15/02/2006, 16h08
  4. Ecrire la base de données dans le disque dure
    Par kherfi2006 dans le forum Bases de données
    Réponses: 3
    Dernier message: 25/12/2005, 15h45
  5. Données perdues sur disque dur esclave ?
    Par maadadi dans le forum Composants
    Réponses: 11
    Dernier message: 18/10/2005, 21h51

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo