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
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fred BROUARD
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 *************************
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 *************************
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 *************************
