Discussion :

[ariesnojf]

Bonjour à tous,

J'ai une db assez volumineuse, dont la principale cause est le stockage de document (doc texte, pdf, image, ... de tout en fait).
J'ai deux questions :
1) Si je rajoute un groupe de fichier dans la DB lié à un nouvel "ndf" en isolant la table qui stocke ces documents, est ce judicieux ou non pour le futur ? (sachant qu'actuellement on ne rencontre pas trop de soucis, mais cette base a grossi de 25 Go en 6 mois ... et si j'extrapole ...)
2) J'ai réussi (depuis une base de test et grâce aux différents blogs et posts de ce site ) à déplacer une table (qui au passage est la même chose qu'un index cluster sur le PK, j'ai bien compris ? car ça, je l'ignorais) en utilisant la méthode :

Code :

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

1
2
CREATE UNIQUE CLUSTERED INDEX PK_col_nomtable1 ON dbo.nomtable1 (col)  
   WITH DROP_EXISTING ON ESCLAVE ;

Par contre je me suis aperçu que le reste des clés étaient toujours dans l'ancien groupe de fichiers. Je les ai donc déplacés. La question : comment être sûr que la table (et toutes ses dépendances) que je veux déplacer soit dans le bon groupe de fichier ? Comment je peux procèder pour faire cette vérification ?

Merci pour vos réponses.

SQL 2008 sur WS 2008R2.

[SQLpro]

Pensez aussi à mettre les BLOBs dans un autres groupe de fichier utilisant un fichier situé sur un autre disque physique et en utilisant l'option TEXTIMAGE ON pour la table.

Pour voir ou est stockée la table :

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
18
19
20
21
22
23
SELECT s.name AS SCHEMA_NAME, o.name AS OBJECT_NAME, o.type_desc AS OBJECT_TYPE,
       ds.name AS STORAGE, dbf.physical_name AS FILENAME, ds.type_desc AS STORAGE_TYPE,
       i.name AS index_name, i.index_id, i.type_desc AS index_type, 
       p.partition_id, p.partition_number as pnum, p.rows as partition_rows,
       a.allocation_unit_id as alloc_unit_id, a.type_desc as page_type_desc, a.total_pages as pages,
       internals.total_pages, internals.used_pages, internals.data_pages, 
       first_page, root_page, first_iam_page
FROM  sys.objects AS o
      INNER JOIN sys.schemas AS s
            ON o.schema_id = s.schema_id
      INNER JOIN  sys.indexes AS i
            ON o.object_id = i.object_id
      INNER JOIN sys.partitions p
            ON p.object_id = i.object_id
               AND p.index_id = i.index_id
      INNER JOIN sys.allocation_units a
            ON a.container_id = p.partition_id
      INNER JOIN sys.data_spaces ds
            ON ds.data_space_id = a.data_space_id
      LEFT OUTER JOIN sys.database_files dbf
            ON dbf.data_space_id = ds.data_space_id
      inner join sys.system_internals_allocation_units internals 
            on internals.container_id = a.container_id

A +

[ariesnojf]

Bonjour,

merci pour ta réponse.

Concernant le conseil, je prends, mais moi un peu boulet , je ne sais pas comment faire. Ta méthode permet d'isoler la colonne BLOBs dans un autre groupe de fichier autre que le reste de la table, méthode applicable à chaque table ou sur la DB en général ?
J'ai fouiné un peu, trouvé un groupe de fichier de type "FILESTREAM", mais si j'ai bien compris, ce type utilise un stockage sur système et non pas sur DB. (J'espère ne pas dire de bêtises). As tu un lien pour m'aiguiller sur ton conseil ?

Merci d'avance

@+

[elsuket]

Bonjour,

J'ai fouiné un peu, trouvé un groupe de fichier de type "FILESTREAM", mais si j'ai bien compris, ce type utilise un stockage sur système et non pas sur DB

En fait FileStream est une méthode de stockage, comme vous le verrez dans le tutoriel de Mikedavem.
Il s'agit de ne pas stocker les fichiers dans la base de données mais directement, comme vous le dites, sur le système de fichiers.
Cela ne change en revanche rien à vos backups, et vous pouvez profiter d'une amélioration des performances en utilisant cette fonctionnalité.

Je pense que le tutoriel de Mikedavem répond à ce que vous propose SQLPro.

qui au passage est la même chose qu'un index cluster sur le PK, j'ai bien compris ?

Quelques précisions : quand vous ajoutez une contrainte de clé primaire à une table, SQL Server crée un index cluster par défaut sur cette colonne.
Il en va de même lorsque vous ajoutez une contrainte d'unicité, mais dans ce cas l'index est non-cluster par défaut.
Tout index cluster pointant sur les pages de données de la table, si on déplace l'index cluster de groupe de fichiers comme vous l'avez fait, alors la table est également déplacée dans ce groupe de fichiers : l'index cluster, c'est la table
J'en ai mis un peu plus là-dessus ici

@++

[ariesnojf]

Merci à vous 2,

J'ai parcouru rapidement le tutoriel, (car pas trop de temps aujourd'hui sur ce sujet, on a quelque soucis au boulot...), juste deux questions malgré tout:
1) au niveau sauvegarde, il est stipulé que rien ne change, mais si le disque qui supporte les fichier crashe, ou un incendie ou autre catatrosphe à la sauce hollywoodienne..., les sauvegardes (SQL je parle) seront capable de remonter ces fichiers ou faut il en plus de la sauvegarde SQL, une sauvegarde de type Windows classique ? (en fait j'aimerai être sûr de ce que j'ai compris)

2) au niveau IHM depuis appli web, actuellement, il suffit à l'utilisateur de cliquer sur le doc pour qu'il apparaisse et d'en faire ce qu'il veut (imprimer, dl, ...). Le comportement de l'appli sera t il à modifier si on met en place le Filestream ? Idem pour l'upload ?

En fait 3 questions :
3) Peut on imaginer de stocker les docs sur autre serveur que SQL, par exemple IIS où l'appli web est maintenu ? Seulement, il y a risque de perte au niveau perf ? (IIS requete table document sur SQL, qui lui va interroger IIS pour les docs, qui va renvoyer à SQL qui renverra le résultat de la requete vers IIS, )


Merci encore pour les liens.

@+

[SQLpro]

1) au niveau sauvegarde, il est stipulé que rien ne change, mais si le disque qui supporte les fichier crashe, ou un incendie ou autre catatrosphe à la sauce hollywoodienne..., les sauvegardes (SQL je parle) seront capable de remonter ces fichiers ou faut il en plus de la sauvegarde SQL, une sauvegarde de type Windows classique ? (en fait j'aimerai être sûr de ce que j'ai compris)

Une base est une seule unité de données et se sauvegarde par defaut de façon monolithique FILESTREAM compris.
Mais rein ne vous empêche de faire des sauvegardes partielles par groupe de fichiers (or un FILESTREAM c'est au moins 1 groupe de fichiers, vois plusieurs).

2) au niveau IHM depuis appli web, actuellement, il suffit à l'utilisateur de cliquer sur le doc pour qu'il apparaisse et d'en faire ce qu'il veut (imprimer, dl, ...). Le comportement de l'appli sera t il à modifier si on met en place le Filestream ? Idem pour l'upload ?

Il y a deux méthodes d'accès : soit par le flux SQL dans le dataset (donc idem que si incorporé dans une colonne BLOB de la table), ou alors en accès fichier (via un UNC logique fournit par le serveur) et là dans .net c'est comme si vous étiez directement sur le fichier. Tout dépend du niveau de sécurité que vous exigez (aucun accès direct au fichiers par exemple) et aussi des performances que vous exigez.

En fait 3 questions :
3) Peut on imaginer de stocker les docs sur autre serveur que SQL, par exemple IIS où l'appli web est maintenu ? Seulement, il y a risque de perte au niveau perf ? (IIS requete table document sur SQL, qui lui va interroger IIS pour les docs, qui va renvoyer à SQL qui renverra le résultat de la requete vers IIS, )

Vous avez tout compris : de multiples AR réseau inutile en sus du fait qu'un SGBDR est optimisé pur servir des données alors que ce n'est pas le cas d'un serveur Web.

Pensez cependant à dédier un agrégat RAID (1 ou 0+1 ou 10) à l'espace de stockage du FILETREAM !

A +