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 en récupération [2008]


Sujet :

Administration SQL Server

  1. #21
    Rédacteur
    Avatar de JauB
    Homme Profil pro
    Freelancer
    Inscrit en
    Octobre 2005
    Messages
    1 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Maroc

    Informations professionnelles :
    Activité : Freelancer
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2005
    Messages : 1 792
    Points : 2 914
    Points
    2 914
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Là c'est franchement d'une haute stupidité !
    Votre JT devrait avoir une taille d'environ 20 % de la taille des données effective de la base.
    Regardez la taille effective des données de la base à l'aide de la procédure sp_spaceused
    Prenez les 2 volumes data et index et additionnez les. Puis multiplié par 0,2

    A +
    Moi je n'ai fait que réduire (SHRINK) le fichier ldf, je ne l'ai pas limité à une taille quelconque.

    Quand tu dis :
    Citation Envoyé par SQLpro Voir le message
    Votre JT devrait avoir une taille d'environ 20 % de la taille des données effective de la base.
    Cela veut dire que je dois limiter quelque part sa taille maximale à 20 % de la taille des données effective de la base ? Ou bien au moment du SHRINK calculer les 20% et le shrinker à cette hauteur ?
    J'avoue que je ne suis pas l'expert en DBA mais je suivrai à la lettre vos recommandations si tout le monde est aligné sur le même principe
    Mes articles, Mon Blog

    Rubrique Jasper/iReport :
    ------- Forum Jasper --------
    ----- FAQ Jasper/iReport -----


  2. #22
    Modérateur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Janvier 2005
    Messages
    5 826
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2005
    Messages : 5 826
    Points : 12 371
    Points
    12 371
    Par défaut
    Citation Envoyé par SQLPro
    Là mon petit Nicolas je ne suis ABSOLUMENT PAS D'ACCORD !!!

    En effet, une opération de croissance du JT de 1 G0 mettre beaucoup de temps surtout s'il est sur un serveur base de gamme avec un RAID entrelacé...
    Il se peut alors qu'il obtienne des timeouts liés aux opérations de fichier et donc des requêtes annulées et des clients déconnectés !!!!
    => message 5144 : Autogrow of file '%.*ls' in database '%.*ls' was cancelled by user or timed out after %d milliseconds. Use ALTER DATABASE to set a smaller FILEGROWTH value for this file or to explicitly set a new file size.

    Raison pour laquelle je préconise de ne jamais dépasser 50 Mo !
    Citation Envoyé par Oishiiii
    Elsuket expliquait seulement comment faire grossir le fichier jusqu'à la taille cible (par exemple 15Go) pour limiter le nombre de VLF.
    Exact, je l'ai probablement mal exprimé.

    Donc, comme SQLPro le préconise et je suis complètement d'accord : d'habitude, je taille le fichier du journal des transactions entre 20 et 30% de la somme de la taille des fichiers de données.
    Disons que cela me donne 5Go. Je vais donc créer la base avec un fichier du journal des transactions à 1Go, puis le faire grossir juste ensuite à 2Go, puis à 3Go, puis à 4Go et enfin à 5Go.
    Ainsi donc j'ai 5 * 8 fichiers virtuels, au lieux de 16 si j'avais alloué 5Go directement.

    Citation Envoyé par JauB
    Cela veut dire que je dois limiter quelque part sa taille maximale à 20 % de la taille des données effective de la base ?
    Non, vous devriez l'allouer à 20% de la somme de la taille des fichiers de données.

    Citation Envoyé par JauB
    Ou bien au moment du SHRINK calculer les 20% et le shrinker à cette hauteur ?
    Rétrécissez au maximum, puis ré-allouez à 20-30% de la somme de la taille des fichiers de données.

    @++

  3. #23
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 716
    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 716
    Points : 52 380
    Points
    52 380
    Billets dans le blog
    4
    Par défaut
    Citation Envoyé par JauB Voir le message
    Moi je n'ai fait que réduire (SHRINK) le fichier ldf, je ne l'ai pas limité à une taille quelconque.
    C'est justement ça le problème !!!! Le SHRINK est une stupidité.
    Vous devez faire en sorte que votre Journal de Transaction soit d'une taille minimale de 20% du volume de la base de manière a éviter toute opération de croissance !!!

    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/ * * * * *

  4. #24
    Expert éminent sénior
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2005
    Messages
    5 450
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Distribution

    Informations forums :
    Inscription : Août 2005
    Messages : 5 450
    Points : 12 891
    Points
    12 891
    Par défaut
    Donc, comme SQLPro le préconise et je suis complètement d'accord : d'habitude, je taille le fichier du journal des transactions entre 20 et 30% de la somme de la taille des fichiers de données.
    En précisant peut être que si c'est une règle générique qui permet de répondre à la question combien je mets pour le journal des transactions à la base. C'est une bonne règle et je l'applique moi même également. Après dans la pratique il faut bien entendu continuer à prendre en compte le contexte car il se peut que cette taille ne convienne pas.

    Je prends un exemple d'un client qui reconstruisait ses index (ou plutôt un gros index qui équivalait à 90% de la taille globale de la base) en mode de récupération SIMPLE. Il a vu son journal grossir de 3 fois la taille de la base de données puisqu'il est passé en mode de reconstruction ONLINE et ce mode ne permet d'utiliser journalisation au minimum. Effectivement d'autres solutions existent pour réduire cette activité mais à l'instant T il a fallu lui prévoir de l'espace disque pour le journal pour répondre à son besoin.

    Un autre exemple plutôt classique, certains traitements de nuits qui viennent polluer le journal des transactions (même en mode simple) et qui font parfois exploser les tailles de journal à plus de 20% de la taille des données. Ok là encore il existe des solutions mais quelques fois nous n'avons pas la maitrise de l'application derrière et malheureusement l'espace disque sera également à prévoir dans ce cas.

    ++

  5. #25
    Modérateur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Janvier 2005
    Messages
    5 826
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2005
    Messages : 5 826
    Points : 12 371
    Points
    12 371
    Par défaut
    Même retour d'expérience que Mikedavem.

    @++

  6. #26
    Rédacteur
    Avatar de JauB
    Homme Profil pro
    Freelancer
    Inscrit en
    Octobre 2005
    Messages
    1 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Maroc

    Informations professionnelles :
    Activité : Freelancer
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2005
    Messages : 1 792
    Points : 2 914
    Points
    2 914
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    C'est justement ça le problème !!!! Le SHRINK est une stupidité.
    Vous devez faire en sorte que votre Journal de Transaction soit d'une taille minimale de 20% du volume de la base de manière a éviter toute opération de croissance !!!

    A +
    Je ne vois pas pourquoi le SHRINK serai une stupidité !!
    Comment faire pour configurer SQLServer (2008 R2) pour avoir un JT de taille minimale de 20% de la base ? Pourrez-vous m'indiquer un lien a suivre ?
    Mes articles, Mon Blog

    Rubrique Jasper/iReport :
    ------- Forum Jasper --------
    ----- FAQ Jasper/iReport -----


  7. #27
    Membre éclairé Avatar de Bernardos
    Homme Profil pro
    Consultant Senior dba sql server & Microsoft Business Intelligence
    Inscrit en
    Avril 2008
    Messages
    332
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant Senior dba sql server & Microsoft Business Intelligence
    Secteur : Conseil

    Informations forums :
    Inscription : Avril 2008
    Messages : 332
    Points : 723
    Points
    723
    Par défaut
    N'est stupide que la stupidité...et les shrink!
    surtout si tu as laissé le taux de croissance par défaut... bonjour la fragmentation.

    Si ton Log a eu besoin de monter à 60 Go il en aura encore potentiellement besoin. donc qu'elle utilité de réduire quelque chose qui va à nouveau grandir (mis à part la pelouse)

    ta base fait 145 Go donc ton log doit être au strict minimum à 29 Go(20%) mais 45 Go d'entrée de jeu n'est pas déconnant (43.5= 30%). Donc du coup un Log de 60 Go ne me choque à priori pas.
    il faut partir du principe que tes fichier de bases de données (mdf, ldf, ndf) ne devraient JAMAIS grandir et ne devraient JAMAIS rétrécir.
    Donc dans ton cas je fixerait la taille de ton log à 70 Go. Pour ta base, qu'elle est la croissance annuelle? tu fais ce nombre XX au minimum fois 3 et tu fixes la taille à 145 Go + XX
    et pour ce faire tu peux suivre la méthode décrite plus haut par Elsuket(1 Go par 1 Go)
    Cordialement,

    Loïc
    Loïc BERNARD
    Consultant Senior dba sql server & Microsoft Business Intelligence



    Il n'y a jamais de problèmes, il n'y a que des solutions!

  8. #28
    Rédacteur
    Avatar de JauB
    Homme Profil pro
    Freelancer
    Inscrit en
    Octobre 2005
    Messages
    1 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Maroc

    Informations professionnelles :
    Activité : Freelancer
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2005
    Messages : 1 792
    Points : 2 914
    Points
    2 914
    Par défaut
    Citation Envoyé par lbernard Voir le message
    N'est stupide que la stupidité...et les shrink!
    surtout si tu as laissé le taux de croissance par défaut... bonjour la fragmentation.

    Si ton Log a eu besoin de monter à 60 Go il en aura encore potentiellement besoin. donc qu'elle utilité de réduire quelque chose qui va à nouveau grandir (mis à part la pelouse)

    ta base fait 145 Go donc ton log doit être au strict minimum à 29 Go(20%) mais 45 Go d'entrée de jeu n'est pas déconnant (43.5= 30%). Donc du coup un Log de 60 Go ne me choque à priori pas.
    il faut partir du principe que tes fichier de bases de données (mdf, ldf, ndf) ne devraient JAMAIS grandir et ne devraient JAMAIS rétrécir.
    Donc dans ton cas je fixerait la taille de ton log à 70 Go. Pour ta base, qu'elle est la croissance annuelle? tu fais ce nombre XX au minimum fois 3 et tu fixes la taille à 145 Go + XX
    et pour ce faire tu peux suivre la méthode décrite plus haut par Elsuket(1 Go par 1 Go)
    Cordialement,

    Loïc
    Mais s'il y a des operations peu frequentes qui explosent mon ldf, dois-je laisser mon JT avec une taille assez grande qui ne fait qu'occuper mon espace disque ? (Exemple : lancer une fonction ERP d'archivage de mon module stock). La mon log peut faire une centaine de Go, cette fonction d'archivage ne sera lancée probablement qu'une seule fois chaque 10 ans ! Devrais-je garder un log ainsi pendant les 10 ans ?a moins qu'on me dise que je peux revenir en arriere en cas de besoin, chose tres tres peu probable !!
    Il y a aussi des fonction de copies de tables qui se lancent chasue jours (INSERT INTO #tmp....) pour les utiliser dans d'autres requetes. La aussi mon log se gonfle. Si je ne tronque pas, je vais me retrouver avec un log a plusieurs To, mon Serveur SQL s'entranglera au bout de quelques mois !
    Sinon des liens vers des documents seront les bienvenus. Je reviendrai aux beaux jours de lectures des tuto si besoin est
    Mes articles, Mon Blog

    Rubrique Jasper/iReport :
    ------- Forum Jasper --------
    ----- FAQ Jasper/iReport -----


  9. #29
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par JauB Voir le message
    Mais s'il y a des operations peu frequentes qui explosent mon ldf, dois-je laisser mon JT avec une taille assez grande qui ne fait qu'occuper mon espace disque ? (Exemple : lancer une fonction ERP d'archivage de mon module stock). La mon log peut faire une centaine de Go, cette fonction d'archivage ne sera lancée probablement qu'une seule fois chaque 10 ans ! Devrais-je garder un log ainsi pendant les 10 ans ?a moins qu'on me dise que je peux revenir en arriere en cas de besoin, chose tres tres peu probable !!
    Si tu as la place sur tes disques, je ne vois pas pourquoi ça gênerait de conserver ça gros.
    Vu le prix actuelle du To, ça ne devrait pas être un vrai problème, pour moi.
    Après, il faut savoir raison garder, réduire son fichier de journalisation une fois par an, ça ne va pas non plus provoqué le déluge, ni la colère de la Momie !

    Par exemple, j'ai une bd d'antivirus qui shrink sa bd automatiquement tous les jours... Les fichiers doivent être fragmentés comme pas permis mais je ne vais pas non plus négocier hypothétiquement pendant des jours avec l'éditeur pour faire changer ses méthodes de merdes.

  10. #30
    Modérateur

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Janvier 2005
    Messages
    5 826
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Haute Garonne (Midi Pyrénées)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2005
    Messages : 5 826
    Points : 12 371
    Points
    12 371
    Par défaut
    Il y a aussi des fonction de copies de tables qui se lancent chasue jours (INSERT INTO #tmp....) pour les utiliser dans d'autres requetes. La aussi mon log se gonfle. Si je ne tronque pas, je vais me retrouver avec un log a plusieurs To, mon Serveur SQL s'entranglera au bout de quelques mois !
    Mauvaise pioche : vous parlez de #tmp, c'est à dire une table temporaire, qui comme tout table doit être persistée.
    Dans le cas présent, cela implique l'utilisation de TempDB, qui est une base système très particulière, mais pour notre discussion, celle-ci est en mode de récupération SIMPLE.
    Le comportement de la ré-allocation de l'espace dédié aux transactions dans le fichier du journal y est donc différent.

    Ceci étant, quel que soit le mode de récupération, si vous avez des opérations de génération ou de nettoyage de données massives, il suffit, pour que le fichier du journal des transactions n'explose pas en taille, de procéder par lots de lignes. Supposons que nous avons à INSERT ou UPDATE ou DELETE 10 millions de lignes.

    Si l'on traite les 10 millions de lignes en une seule instruction, outre le fait que cela va largement diminuer la concurrence d'accès à ladite table du fait du verrouillage et de l'effet d'escalade, cela représente une quantité d'informations énorme à écrire dans le fichier du journal des transactions. L'espace qui sera alloué à ces informations ne pourra pas être marqué pour ré-allocation avant la fin de la transaction, et s'il y a d'autres transactions, elle participeront aussi du gonflement de la taille du fichier du journal des transactions.

    Si l'on subdivise ces 10 millions de lignes en lots plus petits, par exemple de 100000 ou même 10000 lignes, d'une part il y a peu de chances pour que le fichier du journal des transactions s'étende sur le volume qui le supporte, mais on diminue par là-même la charge de verrouillage.
    Dans ce second cas, avec une base de données en mode de récupération complet (FULL), la planification de sauvegardes du fichier du journal des transactions fréquente et régulière passe pendant l'exécution des lots, ce qui fait que le fichier du journal des transactions a de grandes chances de conserver sa taille originale.
    La mécanique est d'ailleurs similaire à la maintenance des index.

    @++

  11. #31
    Membre éclairé Avatar de Bernardos
    Homme Profil pro
    Consultant Senior dba sql server & Microsoft Business Intelligence
    Inscrit en
    Avril 2008
    Messages
    332
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant Senior dba sql server & Microsoft Business Intelligence
    Secteur : Conseil

    Informations forums :
    Inscription : Avril 2008
    Messages : 332
    Points : 723
    Points
    723
    Par défaut
    Mais s'il y a des operations peu frequentes qui explosent mon ldf, dois-je laisser mon JT avec une taille assez grande qui ne fait qu'occuper mon espace disque ?
    on parle de 100 Go ... ridicule de se poser la question. j'espère au passage que ton fichier ldf est isolé sur un disque.
    (Exemple : lancer une fonction ERP d'archivage de mon module stock). La mon log peut faire une centaine de Go, cette fonction d'archivage ne sera lancée probablement qu'une seule fois chaque 10 ans !
    Une opération prévue dans 10 ans? baah tu seras j'espère sur une nouveau serveur et même peut-être dans un nouvel ERP.
    Après, il faut savoir raison garder, réduire son fichier de journalisation une fois par an, ça ne va pas non plus provoqué le déluge, ni la colère de la Momie !
    tout dépend du contexte... mes conseils ne seront pas les mêmes pour une base qui sert à gérer les droits de 10 imprimantes que pour une base utilisée par un site internet avec des données volatiles et très requêtées.
    tout dépend aussi du contexte plus matériel... si tout tes fichiers de plein de bases sont sur une mème et instance et/ou un même disque avec en prime des tailles de secteur à 4 Ko. je te dirai laisse tomber l'optimisation...
    Donc pour répondre à la question, moi sur une base critique (comme un ERP) je ne me pose pas la question si un jour j'ai besoin de 100 Go, je met 100Go.
    Après l'optimisation des opérations effectuées est peut-être aussi une piste à étudier
    Cordialement,
    Loïc
    Loïc BERNARD
    Consultant Senior dba sql server & Microsoft Business Intelligence



    Il n'y a jamais de problèmes, il n'y a que des solutions!

  12. #32
    Membre éclairé Avatar de Bernardos
    Homme Profil pro
    Consultant Senior dba sql server & Microsoft Business Intelligence
    Inscrit en
    Avril 2008
    Messages
    332
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant Senior dba sql server & Microsoft Business Intelligence
    Secteur : Conseil

    Informations forums :
    Inscription : Avril 2008
    Messages : 332
    Points : 723
    Points
    723
    Par défaut
    Il y a aussi des fonction de copies de tables qui se lancent chasue jours (INSERT INTO #tmp....) pour les utiliser dans d'autres requetes. La aussi mon log se gonfle. Si je ne tronque pas, je vais me retrouver avec un log a plusieurs To, mon Serveur SQL s'entranglera au bout de quelques mois !
    Sinon des liens vers des documents seront les bienvenus. Je reviendrai aux beaux jours de lectures des tuto si besoin est
    ah oui j'avais pas été attentif à ça. pas bien ça. plusieurs To de Log pour une base de 145 Go? faire des tables temporaires?
    je vais faire mon @sql pro sur ce coup là mais je suis désolé, c'est de la merde en boite. pq ne pas passer par des vues? Pq ne pas faire des CTE.

    Ceci étant, quel que soit le mode de récupération, si vous avez des opérations de génération ou de nettoyage de données massives, il suffit, pour que le fichier du journal des transactions n'explose pas en taille, de procéder par lots de lignes.
    je plussoie

    Cordialement,

    Loïc
    Loïc BERNARD
    Consultant Senior dba sql server & Microsoft Business Intelligence



    Il n'y a jamais de problèmes, il n'y a que des solutions!

  13. #33
    Rédacteur
    Avatar de JauB
    Homme Profil pro
    Freelancer
    Inscrit en
    Octobre 2005
    Messages
    1 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Maroc

    Informations professionnelles :
    Activité : Freelancer
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2005
    Messages : 1 792
    Points : 2 914
    Points
    2 914
    Par défaut
    Je prends note de vos remarques.
    Deux questions alors :
    1. Le fait de laisser mon JT a une centaine de Go ne reduit pas l'optimisation de mes operations ? (Exemple : un INSERT qui est logé dans un log qui fait deja 100 Go mettra le meme temps que s'il est logé dans un log a 100 Mo ?).

    2. Mon serveur BD est repliqué sur un autre serveur sur le meme LAN (j'utilise VEEAM et je suis sous VMWare), et on est entrain de faire de la replication sur le WAN via ADSL (dont le debit theorique ne depasse pas les 20 Mbps). Croyez vous que la replication avec une telle taille de BD passera sans probleme ? (Peut etre que ma question doiy etre posée dans un autre forum, mais je risque de perdre vos lumieres ).

    J'attends toujours des liens vers des tuto qui pourront me guider dans la mise en place de vos conseils, car quand vous me dites par exemple faire un pas de 1Go pour le JT je ne vois pas comment faire ...
    Mes articles, Mon Blog

    Rubrique Jasper/iReport :
    ------- Forum Jasper --------
    ----- FAQ Jasper/iReport -----


  14. #34
    Membre éclairé Avatar de Bernardos
    Homme Profil pro
    Consultant Senior dba sql server & Microsoft Business Intelligence
    Inscrit en
    Avril 2008
    Messages
    332
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant Senior dba sql server & Microsoft Business Intelligence
    Secteur : Conseil

    Informations forums :
    Inscription : Avril 2008
    Messages : 332
    Points : 723
    Points
    723
    Par défaut
    Citation Envoyé par JauB Voir le message
    Je prends note de vos remarques.
    Deux questions alors :
    1. Le fait de laisser mon JT a une centaine de Go ne reduit pas l'optimisation de mes operations ? (Exemple : un INSERT qui est logé dans un log qui fait deja 100 Go mettra le meme temps que s'il est logé dans un log a 100 Mo ?).
    non que du contraire!

    Citation Envoyé par JauB Voir le message
    2. Mon serveur BD est repliqué sur un autre serveur sur le meme LAN (j'utilise VEEAM et je suis sous VMWare), et on est entrain de faire de la replication sur le WAN via ADSL (dont le debit theorique ne depasse pas les 20 Mbps). Croyez vous que la replication avec une telle taille de BD passera sans probleme ? (Peut etre que ma question doiy etre posée dans un autre forum, mais je risque de perdre vos lumieres ).
    qu'utilises tu comme mécanisme de réplication? et au final la seule et vrai question est tu dans un système synchrone ou asynchrone?

    J'attends toujours des liens vers des tuto qui pourront me guider dans la mise en place de vos conseils, car quand vous me dites par exemple faire un pas de 1Go pour le JT je ne vois pas comment faire ...
    heuh un tuto pour modifier la taille de ton fichier log?
    soit tu le fais par script
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    USE master;
    GO
    ALTER DATABASE MaBase
    MODIFY FILE
        (NAME = MaBase_log,
        SIZE = 1 GB);
    GO
    PRINT'ok'
    GO
    ALTER DATABASE MaBase
    MODIFY FILE
        (NAME = MaBase_log,
        SIZE = 2 GB);
     
    GO
    PRINT('ok2')
    GO
    soit tu le fais avec tes mains et des clics clic droit sur ta base --> propriété--> fichiers--> là tu change la taille de ton fichier Log,tu commences à 1024 ou le multiple de 1024 au dessus de ta taille réduite(exemple si t'es à 1200 tu monte à 2048). tu fais ok. puis tu recommences 100 fois

    Cordialement,
    Loïc
    Loïc BERNARD
    Consultant Senior dba sql server & Microsoft Business Intelligence



    Il n'y a jamais de problèmes, il n'y a que des solutions!

  15. #35
    Expert éminent sénior
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2005
    Messages
    5 450
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Distribution

    Informations forums :
    Inscription : Août 2005
    Messages : 5 450
    Points : 12 891
    Points
    12 891
    Par défaut
    Citation Envoyé par JauB Voir le message
    1. Le fait de laisser mon JT a une centaine de Go ne reduit pas l'optimisation de mes operations ? (Exemple : un INSERT qui est logé dans un log qui fait deja 100 Go mettra le meme temps que s'il est logé dans un log a 100 Mo ?).
    C'est la fragmentation du journal liée au nombre de VLFs qui est important. La taille beaucoup moins.

    Citation Envoyé par JauB Voir le message
    2. Mon serveur BD est repliqué sur un autre serveur sur le meme LAN (j'utilise VEEAM et je suis sous VMWare), et on est entrain de faire de la replication sur le WAN via ADSL (dont le debit theorique ne depasse pas les 20 Mbps). Croyez vous que la replication avec une telle taille de BD passera sans probleme ? (Peut etre que ma question doiy etre posée dans un autre forum, mais je risque de perdre vos lumieres ).
    Encore une fois la taille importe peu car la réplication se fait au niveau bloc avec une réplication des blocs qui changent au fil du temps. Je suppose que tu es en réplication asynchrone dans ton cas?

    ++

  16. #36
    Rédacteur
    Avatar de JauB
    Homme Profil pro
    Freelancer
    Inscrit en
    Octobre 2005
    Messages
    1 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Maroc

    Informations professionnelles :
    Activité : Freelancer
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2005
    Messages : 1 792
    Points : 2 914
    Points
    2 914
    Par défaut
    Citation Envoyé par lbernard Voir le message
    non que du contraire!


    qu'utilises tu comme mécanisme de réplication? et au final la seule et vrai question est tu dans un système synchrone ou asynchrone?


    heuh un tuto pour modifier la taille de ton fichier log?
    soit tu le fais par script
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    USE master;
    GO
    ALTER DATABASE MaBase
    MODIFY FILE
        (NAME = MaBase_log,
        SIZE = 1 GB);
    GO
    PRINT'ok'
    GO
    ALTER DATABASE MaBase
    MODIFY FILE
        (NAME = MaBase_log,
        SIZE = 2 GB);
     
    GO
    PRINT('ok2')
    GO
    soit tu le fais avec tes mains et des clics clic droit sur ta base --> propriété--> fichiers--> là tu change la taille de ton fichier Log,tu commences à 1024 ou le multiple de 1024 au dessus de ta taille réduite(exemple si t'es à 1200 tu monte à 2048). tu fais ok. puis tu recommences 100 fois

    Cordialement,
    Loïc
    Operation a faire 100 fois successivement ou la faire au besoin (en fonction de la taille de mon log ou autre chose) ?

    Sinon, cette question de fragmentation du log en fonction du nombre des VLFs, je ne vois pas trop a quoi ca correspond ! Ni l'action a faire ? Et en fonction de quoi l'entreprendre ?
    J'apprends donc j'existe
    Mes articles, Mon Blog

    Rubrique Jasper/iReport :
    ------- Forum Jasper --------
    ----- FAQ Jasper/iReport -----


  17. #37
    Membre éclairé Avatar de Bernardos
    Homme Profil pro
    Consultant Senior dba sql server & Microsoft Business Intelligence
    Inscrit en
    Avril 2008
    Messages
    332
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant Senior dba sql server & Microsoft Business Intelligence
    Secteur : Conseil

    Informations forums :
    Inscription : Avril 2008
    Messages : 332
    Points : 723
    Points
    723
    Par défaut
    Operation à faire 100 fois successivement. du coup dans ton cas peut être automatiser avec un programme, un script
    pour les fichiers de log voici un petit article de elsuket
    http://blog.developpez.com/elsuket/p...rs_journaux_vi

    l'opération de faire 100 fois un Go pour l'augmentation va te générer un nombre "raisonable" de VLFs
    Cordialement,

    Loïc
    Loïc BERNARD
    Consultant Senior dba sql server & Microsoft Business Intelligence



    Il n'y a jamais de problèmes, il n'y a que des solutions!

  18. #38
    Expert éminent sénior
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    Août 2005
    Messages
    5 450
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : France, Ain (Rhône Alpes)

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Distribution

    Informations forums :
    Inscription : Août 2005
    Messages : 5 450
    Points : 12 891
    Points
    12 891
    Par défaut
    Citation Envoyé par JauB Voir le message
    Operation a faire 100 fois successivement ou la faire au besoin (en fonction de la taille de mon log ou autre chose) ?

    Sinon, cette question de fragmentation du log en fonction du nombre des VLFs, je ne vois pas trop a quoi ca correspond ! Ni l'action a faire ? Et en fonction de quoi l'entreprendre ?
    J'apprends donc j'existe
    Pas de souci j'en apprends tous les jours aussi donc ..

    Je vais essayer de partir sur une explication simple. Ton journal des transactions est divisé logiquement en tronçons logiques (Virtual Log Files). Plus tu as de tronçons logiques à gérer, plus ta performance est impactée.
    Tu en as vu toi même un effet direct avec un temps de récupération très long.

    Comment ça se gère tout ca?

    Lorsque ton journal grossit il va le faire en fonction de la taille d'incrément (autogrow) que tu lui as fixé et c'est taille va aussi fixé le nombre de VLF.

    L'algorithme est le suivant dans ton cas (il a peu changé depuis 2014).

    < 64MB et jusqu'à 64MB = 4 VLFs
    > 64MB et jusqu'à 1GB = 8 VLFs
    > 1GB = 16 VLFs

    Si on prend un cas où tu as un journal à 100MB et que tu laisses ensuite grossir ton journal avec une taille de 100MB jusqu'à 60GB (je prends un cas extrême ici) tu auras :

    8 VLFs (au départ) + (60GB - 100MB ) / 100 MB (autogrow) * (8 VLFS par autogrow) = 4915 VLFs.

    Dans ce cas on va dire que ton journal des transactions est très fragmenté et qu'il risque d'impacter la performance de ta base de données (par exemple un recovery long comme tu as pu le voir chez toi).

    Le but c'est de pouvoir maintenir ce nombre de VLFS raisonnable en adoptant une stratégie plus intelligente. Si tu sais que ton journal devra faire 60GB tu peux effectivement les faire grossir par incrément de 1GB donc répéter l'opération 100 fois ce qui te donnerait cette fois ci

    100 * (8 VLFS par incrément de 1GB) = 800 VLFs . Ce qui donne un nombre beaucoup plus raisonnable. Après tu verras beaucoup de littérature sur le sujet et certaines recommandations sur le nombre de VLFs à ne pas dépasser. Un KB microsoft existe et recommande de ne pas dépasser les 1000 VLFs (ce n'est pas une règle absolue bien sûr). Moi j'aurais une préférence pour une taille de 100GB de choisir des tailles d'expansions plus importantes pour tailler le journal au départ (quelque chose comme 4GB ... peut être plus) ce qui donnerait environ 123 VLFs mais la proposition de 100 fois 1GB est tout aussi valable .. à toi de voir en fonction de ton contexte ...

    Cependant il faut veiller à ne pas choisir un nombre trop petit de VLFs car tu pourrais être embêté dans certains cas pour les vider.
    Prenons un cas où tu as un fichier log de 100GB que tu as créé en une seule fois. Il sera donc constitué de 16VLFs avec une taille par VLF de 6GB environ. Tu peux te retrouver dans un cas où ton VLF de 6GB ne pourra pas être vidé s'il contient au moins un enregistrement de journal qui est nécessaire à SQL Server (transaction ouverte, réplication active etc ...)

    Tu auras compris qu'il faudra trouver un compromis entre le pas assez et trop

    ++

  19. #39
    Membre éclairé Avatar de Bernardos
    Homme Profil pro
    Consultant Senior dba sql server & Microsoft Business Intelligence
    Inscrit en
    Avril 2008
    Messages
    332
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 45
    Localisation : Belgique

    Informations professionnelles :
    Activité : Consultant Senior dba sql server & Microsoft Business Intelligence
    Secteur : Conseil

    Informations forums :
    Inscription : Avril 2008
    Messages : 332
    Points : 723
    Points
    723
    Par défaut
    du coup dans ton cas peut être automatiser avec un programme, un script
    Allez hop je vais être bon prince.
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    DECLARE @CPT BIGINT = 1
    DECLARE @SQL NVARCHAR (255)
    WHILE @CPT <= 100
    BEGIN
        SET @SQL = 'ALTER DATABASE MaBase MODIFY FILE (NAME = MaBase_log,SIZE = ' + CAST (@CPT AS NvarCHAR) + 'GB)' 
    	PRINT @SQL
    	EXEC sp_executesql @SQL
    	SET @CPT = @CPT + 1
    END
    il suffit d'adapter l’initialisation de ton compteur @CPT. si ton Log réduit fait 1,5 go tu démarres à 2 ou à 3

    EDIT: faut changer le nom logique 'Mabase_log' avec le nom logique de ton fichier log
    fait ça en dehors de toutes activités !

    Cordialement,

    Loïc
    Loïc BERNARD
    Consultant Senior dba sql server & Microsoft Business Intelligence



    Il n'y a jamais de problèmes, il n'y a que des solutions!

  20. #40
    Rédacteur
    Avatar de JauB
    Homme Profil pro
    Freelancer
    Inscrit en
    Octobre 2005
    Messages
    1 792
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    Localisation : Maroc

    Informations professionnelles :
    Activité : Freelancer
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Octobre 2005
    Messages : 1 792
    Points : 2 914
    Points
    2 914
    Par défaut
    Merci encore une fois pour vos reponses.
    Question et surement pas la derniere : Est ce que vos propositions de tailler le log et changer les parametrages par defaut (autogrow...) sont aussi valables pour une base de donnees deja existante ? Ou bien c'est valable pour les nouvelles creations de BD ?
    A cet instant meme, une de mes bases fait 370 Go (mdf) , mon ldf fait 20 Mo (car hier soir a été SHRINKé via un job automatique qui s'execute juste avant la sauvegarde full, et 60 VLFs). Dans ce cas, pour tailler mon log est ce que je dois attendre une certaine periode pour evaluer la taille de mon log pour la fixer au niveau du ALTER ? Ou bien je peux des maintenant la fixer a 1Go et la faire evoluer de 1Go pendant 100 fois (en executant le script du prince )?

    PS: j'ai bien compris que le SHRINK est stupide donc je l'enleve demain de mon job.
    Mes articles, Mon Blog

    Rubrique Jasper/iReport :
    ------- Forum Jasper --------
    ----- FAQ Jasper/iReport -----


+ Répondre à la discussion
Cette discussion est résolue.
Page 2 sur 3 PremièrePremière 123 DernièreDernière

Discussions similaires

  1. Réponses: 3
    Dernier message: 18/04/2011, 14h43
  2. Récupération du type d'une colonne dans une base de données
    Par Astartee dans le forum Accès aux données
    Réponses: 2
    Dernier message: 07/05/2007, 14h03
  3. [MySQL] Récupération de code php dans une base de données
    Par kitana dans le forum PHP & Base de données
    Réponses: 4
    Dernier message: 21/03/2006, 01h25
  4. [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

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