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 :

SQL 2008R2 + Datafiles


Sujet :

Administration SQL Server

  1. #1
    Membre actif
    Inscrit en
    novembre 2004
    Messages
    312
    Détails du profil
    Informations forums :
    Inscription : novembre 2004
    Messages : 312
    Points : 202
    Points
    202
    Par défaut SQL 2008R2 + Datafiles
    Bonjour,

    J'ai une base qui est composé de 2 group files : PRIMARY et INDEX.
    Chaque group file est composé d'un datafile.

    J'ai ajouté 1 datafile supplémentaire à chaque groupfile et relancer un job de recréation des indexs en pensant que mes data allaient être dispatchées entre mes différents datafiles.
    Mon 1er datafile du groupe PRIMARY fait 500Go environ. Après le job de recréation d'index mon second datafile ne fait que 2Go.

    Comment faire pour que le dispatch de mes datas se fassent de manière sensiblement identique entre mes différents datafiles?

    Merci pour votre aide.

  2. #2
    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 : 40
    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 348
    Points
    12 348
    Par défaut
    Bonjour,

    Je ne suis pas sûr qu'en reconstruisant vos index vous parveniez à répartir les données dans les fichiers de données qui composent votre groupe de fichiers.

    La règle c'est qu'il faut que les fichiers fassent très exactement la même taille pour que les données soient réparties de façon à peu près équitable en terme de volume dans les fichiers qui composent le groupe de fichiers.

    Il vous faut donc tailler le fichier à la même taille que l'actuel.

    @++

  3. #3
    Membre actif
    Inscrit en
    novembre 2004
    Messages
    312
    Détails du profil
    Informations forums :
    Inscription : novembre 2004
    Messages : 312
    Points : 202
    Points
    202
    Par défaut
    Y a t il un moyen alors de découper ma base de 500Go en 3 datafiles de 200Go chacun pour mon groupe PRIMARY et en faisant la même chose pour mon groupe INDEX ?

    Merci.

  4. #4
    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 : 40
    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 348
    Points
    12 348
    Par défaut
    Je ne pense pas que cela soit possible pour le groupe de fichiers PRIMARY, s'il ne contient aucun index.
    En effet, à la reconstruction d'un index cluster, qui vous aurait permis de déplacer les tables d'un groupe de fichiers à l'autre, on ne peut pas spécifier de fichier : on spécifie seulement le nom du groupe de fichiers, et le moteur de stockage fait le reste ...

    En revanche pour le groupe de fichiers INDEX, je pense effectivement qu'ajouter des fichiers de taille identique sera la bonne, mais il vous faudra reconstruire les index pour que cela se fasse.

    Je suppose que tous vos fichiers sont sur des axes physiques différents.
    Pour connaître la taille occupée par les données dans chacun de vos fichiers, vous pouvez utiliser cette requête.

    @++

  5. #5
    Membre actif
    Inscrit en
    novembre 2004
    Messages
    312
    Détails du profil
    Informations forums :
    Inscription : novembre 2004
    Messages : 312
    Points : 202
    Points
    202
    Par défaut
    Les index cluster se trouvent dans le groupe Primary.
    Dans ce groupe j'ai aujourd'hui un datafile de 500Go.

  6. #6
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    mai 2002
    Messages
    20 897
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

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

    Informations forums :
    Inscription : mai 2002
    Messages : 20 897
    Points : 49 645
    Points
    49 645
    Billets dans le blog
    1
    Par défaut
    Le plus simple est de créer un autre base à côté et de migrer les données dedans.

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

  7. #7
    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 : 40
    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 348
    Points
    12 348
    Par défaut
    Oui mais c'est un peu brutal

    Reconstruire les index cluster dans le filegroup INDEX après lui avoir ajouté un second fichier devrait aider

    @++

  8. #8
    Expert éminent sénior
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    août 2005
    Messages
    5 424
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    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 424
    Points : 12 775
    Points
    12 775
    Par défaut
    Brutal pas tant que cela

    En fait il faudra jouer au jeu des vases communiquants pour que les données soient réparties correctement. Le fait de reconstruire l'index dans le même groupe de fichiers en ajoutant un fichier ne changera pas grand chose. Les données sont déjà dans le vase et elles y resteront.

    Pour pouvoir bénéficier de l'algorithme de répartition de SQL Server il faudra à chaque fois créer un nouveau groupe de fichiers avec les fichiers désirés ayant la même taille, la même valeur d'expansion et reconstruire les index dans ce nouveau groupe. Ceci est valable pour les données des tables + index non clusters.

    Solution un peu moins brutale que celle proposée par SQLPro mais finalement l'idée reste bien la même.

    ++

  9. #9
    Membre expérimenté

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    août 2007
    Messages
    1 216
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Suisse

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : août 2007
    Messages : 1 216
    Points : 1 725
    Points
    1 725
    Par défaut
    Bonjour,

    Vous pouvez essayer le DBCC shrinkfile (filename, EMPTYFILE).

    depuis BOL:
    Migrates all data from the specified file to other files in the same filegroup. Because the Database Engine no longer allows data to be placed in the empty file, the file can be removed by using the ALTER DATABASE statement.
    http://msdn.microsoft.com/en-us/library/ms189493.aspx

    Si vous avez de nouveaux fichiers proprement tailles, vos datas devraient bouger toutes seules ou il faut et vous permettre d'enlever le fichier en question.

    Preferez un test avant de lancer ca en prod, j'ai jamais essaye encore...

  10. #10
    Expert éminent sénior
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    août 2005
    Messages
    5 424
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    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 424
    Points : 12 775
    Points
    12 775
    Par défaut
    Cela ne fonctionnera pas pour le groupe PRIMARY car toutes les données du premier fichier ne pourront pas être déplacés notamment les données concernant les tables systèmes.

    De plus vider un fichier via cette méthode ne permet pas de répartir de façon équitable les données dans les fichiers (il faut le savoir )

    ++

  11. #11
    Membre expérimenté

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    août 2007
    Messages
    1 216
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Suisse

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : août 2007
    Messages : 1 216
    Points : 1 725
    Points
    1 725
    Par défaut
    Ca pourrait permettre de reduire au maximum le fichier, ensuite de le verouiller (verouiller l'autogrow) et avoir la repartition des donnees plus ou moins egale dans les autres fichiers.

    Ou bien alors le shrinker a 200MB comme les autres, ce qui devrait engendrer un mouvement de donnees aussi.

    A tester

  12. #12
    Membre expérimenté

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    août 2007
    Messages
    1 216
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Suisse

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : août 2007
    Messages : 1 216
    Points : 1 725
    Points
    1 725
    Par défaut
    Citation Envoyé par mikedavem Voir le message
    De plus vider un fichier via cette méthode ne permet pas de répartir de façon équitable les données dans les fichiers (il faut le savoir )
    Ah bon ?

    Quelle est la methode de repartition des donnees dans les fichiers d'un meme filegroup lorsque DBCC shrinkfile est utilise ?
    Est ce qu'il y a une doc quelque part ? Ca m'interesserait de lire ca.

  13. #13
    Expert éminent sénior
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    août 2005
    Messages
    5 424
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    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 424
    Points : 12 775
    Points
    12 775
    Par défaut
    En fait on ne contrôle pas dans ce cas le remplissage des fichiers.
    Pour avoir déjà tester, il n'est pas forcé d'avoir un 1er fichier rempli puis le second avec le reste des données ...

    Mais personnellement je trouve beaucoup plus simple dans ce cas de créer des FILEGROUP à côté avec les fichiers correctement dimensionnés et transférer les données d'un FILEGROUP à un autre en reconstruisant les index. Cette méthode est je trouve plus propre car elle permet en même temps d'avoir des index non fragmentés. La méthode SHRINKFILE ne garantit pas cela

    ++

  14. #14
    Membre expérimenté

    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    août 2007
    Messages
    1 216
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Suisse

    Informations professionnelles :
    Activité : Administrateur de base de données
    Secteur : Industrie Pharmaceutique

    Informations forums :
    Inscription : août 2007
    Messages : 1 216
    Points : 1 725
    Points
    1 725
    Par défaut
    Citation Envoyé par mikedavem Voir le message
    Mais personnellement je trouve beaucoup plus simple dans ce cas de créer des FILEGROUP à côté avec les fichiers correctement dimensionnés et transférer les données d'un FILEGROUP à un autre en reconstruisant les index. Cette méthode est je trouve plus propre car elle permet en même temps d'avoir des index non fragmentés. La méthode SHRINKFILE ne garantit pas cela
    ++
    Plus simple je sais pas - une seule commande pour shrinker c'est plus simple.

    Plus propre et maitrise oui, je suis d'accord

  15. #15
    Membre chevronné Avatar de Jinroh77
    Homme Profil pro
    Consultant en Business Intelligence
    Inscrit en
    février 2006
    Messages
    1 964
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Consultant en Business Intelligence

    Informations forums :
    Inscription : février 2006
    Messages : 1 964
    Points : 2 145
    Points
    2 145
    Par défaut
    D'après tout cela, si l'on souhaite répartir certains objets sur des axes physique distinct, le mieux est alors, non pas de créer plusieurs DataFiles dans un même group, mais plutôt de créer plusieurs GrouFiles (autant que d'axes) et de ne créer qu'un seul DataFile dans chacun ?
    On pourrait alors attribuer soit-même la répartition des objets sur les GroupFiles ?
    Alexandre Chemla - Consultant MS BI chez Masao

  16. #16
    Expert éminent sénior
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    août 2005
    Messages
    5 424
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    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 424
    Points : 12 775
    Points
    12 775
    Par défaut
    L'attribution des objets se fait au niveau du groupefile et pas au niveau des fichiers directement. La réponse est donc oui. Pour contrôler l'attribution des objets il faut créer un FILEGROUP distinct sur chaque axe physique.

    Cela peut être utile sur des tables concernés par des "grosses" jointures par exemple. Cela permet de paralléliser l'accès à ces tables et d'augmenter les temps de traitement.

    ++

  17. #17
    Membre chevronné Avatar de Jinroh77
    Homme Profil pro
    Consultant en Business Intelligence
    Inscrit en
    février 2006
    Messages
    1 964
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 37
    Localisation : France, Seine et Marne (Île de France)

    Informations professionnelles :
    Activité : Consultant en Business Intelligence

    Informations forums :
    Inscription : février 2006
    Messages : 1 964
    Points : 2 145
    Points
    2 145
    Par défaut
    Merci pour la précision. Je continue donc un peu Désolé si je reprends des lieux communs. Davy ne m'en voudra pas de squatter un peu son topic

    Si l'on affecte un GroupFile particulier, qui ne possède qu'un unique DataFile, à une table, c'est donc toute la table qui se retrouve sur un axe ?
    Lors d'une requête utilisant une "grosse" jointure, les accès seront donc plutôt séquentiel ?

    Par contre si la table est affectée à un GroupFile possédant plusieurs DataFiles, à force d'utilisation dans de "grosses jointures", est-ce que les données de la table se trouveront réparties entre les différents DataFiles afin de gérer un accès parallélisé aux données ?
    Alexandre Chemla - Consultant MS BI chez Masao

  18. #18
    Expert éminent sénior
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    août 2005
    Messages
    5 424
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    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 424
    Points : 12 775
    Points
    12 775
    Par défaut
    Citation Envoyé par Jinroh77 Voir le message
    Si l'on affecte un GroupFile particulier, qui ne possède qu'un unique DataFile, à une table, c'est donc toute la table qui se retrouve sur un axe ?
    Oui

    Citation Envoyé par Jinroh77 Voir le message
    Lors d'une requête utilisant une "grosse" jointure, les accès seront donc plutôt séquentiel ? Par contre si la table est affectée à un GroupFile possédant plusieurs DataFiles, à force d'utilisation dans de "grosses jointures", est-ce que les données de la table se trouveront réparties entre les différents DataFiles afin de gérer un accès parallélisé aux données ?
    Disons que si une table est répartie sur plusieurs fichiers l'accès à ses données pourront être parallélisés (plusieurs têtes de lectures pouvant en même temps récupérer les données) à condition bien sûr d'avoir un axe physique pour chaque fichier.

    ++

  19. #19
    Expert éminent sénior
    Avatar de mikedavem
    Homme Profil pro
    Administrateur de base de données
    Inscrit en
    août 2005
    Messages
    5 424
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 43
    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 424
    Points : 12 775
    Points
    12 775
    Par défaut
    Un petit bémole à ce que j'ai pu poster sur le sujet.

    La réindexation répartit plus ou moins bien les données à partir du moment où il ne concerne pas le premier fichier du groupe PRIMARY (ajout de 2 fichiers supplémentaires). Il faut bien penser par contre à dimmensionner correctement les fichiers cibles.

    Cf billet

    ++

  20. #20
    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 : 40
    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 348
    Points
    12 348
    Par défaut
    Merci pour le billet, très clair et concis

    @++

Discussions similaires

  1. [2008R2] Server SQL 2008R2 FR sus un server Windows English
    Par dari68 dans le forum Administration
    Réponses: 1
    Dernier message: 21/06/2015, 12h50
  2. [2008R2] Serveurs Liés entre sql 2008R2 et Sql 2005
    Par cris40 dans le forum MS SQL Server
    Réponses: 0
    Dernier message: 01/04/2015, 11h34
  3. [2008R2] Installation de sql 2008R2 sous seven Pro n’aboutit pas
    Par Doume974 dans le forum MS SQL Server
    Réponses: 10
    Dernier message: 03/06/2014, 18h24
  4. [2008R2] Comment faire un fichier plat longueur fixe avec SQL 2008R2
    Par Goofy95 dans le forum Outils
    Réponses: 0
    Dernier message: 06/10/2013, 17h17
  5. [SQL 2008R2] Trigger de suppression sur une table récursive
    Par sebRD dans le forum MS SQL Server
    Réponses: 7
    Dernier message: 11/05/2011, 14h44

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