Discussion :

[alassanediakite]

Salut
Je voudrais savoir l'utilité de définir plus d'un fichier dans un groupe de fichiers si on ne peut utiliser que le groupe de fichier dans la définition d'une table ou d'un indexe?
merci d'avance.

[mikedavem]

Bonjour,

Le groupe de fichiers permet d'organiser l'allocation de vos tables, index etc ..
C'est par lui que vous devez passer lorsque vous crééer vos tables.

Vous pouvez par exemple organiser votre base avec un groupe de fichiers pour vos index, un pour vos datas etc..

Maintenant vous pouvez également avoir plusieurs fichiers par groupe pour augmenter les performances IO lors de vos accès IO si vous possédez plusieurs axes physiques concernant vos données. (ceci n'est pas valable pour les fichiers concernant le JT)

++

[alassanediakite]

Salut et merci pour la réponse
Dois-je comprendre par là, que je peut définir un fichier (dans un groupe) sans pouvoir y faire référence lors de la création d'un objet, et que c'est sqlserver qui juge de l'opportunité d'un fichier dans une action donnée?
Comprenez que je suis un débutant avec sqlserver.

[mikedavem]

Bonsoir,

Disons qu'il faut faire le distinguo entre le niveau logique (structures de données) et le niveau physique des données (Fichiers)

- Vos tables sont gérées au niveau logique (Groupe de fichiers = conteneur logique).
- La répartion des fichiers dans ces groupes de fichiers se fait quant à elle, au niveau physique.

Ceci respecte parfaitement la règle 8 de Codd : L'indépendance physique des données. Un changement à ce niveau ne doit pas avoir d'impact sur le niveau logique.

++

[alassanediakite]

Salut et merci pour la reponse
Permettez moi d'insister...
Voici un exemple pratique

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
24
25
26
27
28
 
--(livre de sqlpro page 61)
CREATE DATABASE B_FORUM
ON PRIMARY
(NAME=F_CATALOG,
FILENAME='D:\DATASQL\FORUM\F_CATALOG.D0',
SIZE =10 GB
FILEGROWTH=100 MB)
FILEGROUP FG_DATA1
(NAME=F_DATA1
FILENAME='E:\DATASQL\FORUM\F_DATA1.D1',
SIZE =80 GB
MAXSIZE =160 GB
FILEGROWTH=250 MB)
(NAME=F_DATA2
FILENAME='E:\DATASQL\FORUM\F_DATA2.D2',
SIZE =80 GB
MAXSIZE =160 GB
FILEGROWTH=250 MB)
FILEGROUP FG_INDEX1
(NAME='F:\DATASQL\FORUM\F_INDEX1.I1',
SIZE =80 GB
MAXSIZE =160 GB
FILEGROWTH=250 MB)
LOG ON 
(NAME='F_LOG'
FILENAME='G:\LOGSQL\FORUM\F_LOG1.L1',
SIZE =100 GB)

Là on voie deux fichiers dans FG_DATA1.
supposons je crée une table...

Code :

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

1
2
3
4
CREATE TABLE matable
(id INTEGER NOT NULL PRIMARY KEY,
nom CHAR(20) NOT NULL) 
ON FG_DATA1

en plaçant cette table dans "FG_DATA1", dans lequel des fichiers (F_DATA2 ou F_DATA1) sera-t-elle placée?
Quelle est alors l'importance de créer plusieurs fichiers dans un groupe si lors de la création de ma table je ne pas indiquer directement le fichier qui le prendra?
Merci et @+

[SQLpro]

Dans les deux fichiers....

En effet, il y a équipartition, c'est à dire que SQL Server cherche à optimiser tout ce qu'il peut et s'il voit que l'espace de stockage comporte deux fichiers alors il va mettre la moitié des lignes de la table dans l'un des fichiers et l'autre moitié dans l'autre.
Cela permet de diviser par deux les temps physiques d'insertion des données, comme de remontée des données en RAM lors des lectures physiques, sachant que ce qui prends le plus de temps est justement les lectures et écriture des disque (10 000 fois plus lent que la RAM environ).

ATTENTION cependant, car cela n'est valable que si les storages sont physiquement indépendant, ce que n'est pas le cas dans cet exemple car les deux fichiers du filegroup FG_DATA1 pointent sur le même lecteur E. Il aurait été plus sage de faire pointer l'un des fichiers sur un autre lecteur, à condition que la machine qui héberge cette base en soit doté d'un nombre suffisant !

A +

PS : je suis l'auteur du livre.... et il m'arrive de mettre quelques pièges dans mes exemples afin de voire la sagacité de mes lecteurs !

[alassanediakite]

Salut
Merci beaucoup pour la réponse.
Et @+