Archivage de données de tables

Le
Forum
Bonjour à toutes et à tous,

Soit des bases de données (SQL 2005 / SQL 2008) de plusieurs Go: on me
demande de faire de l'archivage de données de ces bases. Il s'agit de
factures depuis "x" années.

J'ai pensé faire cela avec des tables partitionnées en "range". Les
factures sont stockées directement dans les tables.

De 1990 à 1995 --> dans une table partitionnée "T1F"
De 1996 à 2000 --> dans une table partitionnée "T2F"

et ainsi de suite

Ces tables partitionnées étant stockées dans des ".NDF" positionnés sur
des espaces SAN via le réseau.

Est-ce une bonne solution ou une erreur ?
Merci pour vos avis.
Cordialement,
Forum
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Fred BROUARD
Le #21489832
Bonjour,

Forum a écrit :
Bonjour à toutes et à tous,

Soit des bases de données (SQL 2005 / SQL 2008) de plusieurs Go: on me
demande de faire de l'archivage de données de ces bases. Il s'agit de
factures depuis "x" années.

J'ai pensé faire cela avec des tables partitionnées en "range". Les
factures sont stockées directement dans les tables.

De 1990 à 1995 --> dans une table partitionnée "T1F"
De 1996 à 2000 --> dans une table partitionnée "T2F"



Vous mélangez deux concepts :
1) la table partitionnée qui est une seule et même table dont les lignes
sont stockées dans différents espaces de stockage (filegroups) suivant
des valeurs pivots;
2) la vue partitionnée qui consiste à assembler différentes tables de
différentes bases et/ou serveurs avec un UNION ALL.

Dans les deux cas vous obtiendrez un gain si les espaces de stockage
peuvent être :
a) pour certains en read only (donc pas de verrous de lecture)
b) si les espaces de stockage (file groups) sont positionnés sur des
axes physiques mécaniquement indépendant

et ainsi de suite

Ces tables partitionnées étant stockées dans des ".NDF" positionnés sur
des espaces SAN via le réseau.



L'utilisation d'un san sans discernement (avec un seul espace commun ou
bien des LUN qui ne sont pas alignés sur des disques physiques) ne
permettra pas d'obtenir la moindre performance, au contraire.
Il faut commencer par les aspects physique sui sont fortement impactabt
pour un SGBDR (un SGBDR C/S n'est pas un système de fichier !).

Ensuite, vous ne pouvez pas placer des espaces de stockage d'une base
(fichiers ou filegroups) sur des disques distant accessible par réseau.
Sachez cependant que c'est possible, à l'aide d'un déplombage du moteur
de stockage, mais dans ce cas les performances seront plus que
catastrophique. Votre serveur deviendra inexploitable !


Est-ce une bonne solution ou une erreur ?



Un petit cours d'administration BD ne serait sans doute pas de trop
visiblement !

Merci pour vos avis.
Cordialement,
Forum



A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
Enseignant aux Arts & Métiers PACA et à L'ISEN Toulon - Var Technologies
*********************** http://www.sqlspot.com *************************
Publicité
Poster une réponse
Anonyme