Partition ou base répartie

Version imprimable

03/05/2006, 16h29
boisdin

Partition ou base répartie
Bonjour
J'ai une table d'archivage à gérer qui contiendra à terme 1200 millions de lignes.
- Ces lignes sont indéxées sur une date d'émission
- La durée de conservation est de 10 ans
- Les lectures se font à 99% sur les 18 derniers mois.
- Les écritures se feront uniquement sur le mois en cours, après reprise des données existentes
qu'est-ce qui est le plus efficace
Une partition des index par mois ?
Une base de données répartie, une active sur les 18 derniers mois (99% des accès) et un lien sur une base contenant le reste des infos (1% des accès) ?
Ou un mixe des deux ?

Merci de m'éclairer
04/05/2006, 10h41
orafrance

une table (ou base) à part me parait plus judicieux. En effet, les données anciennes n'ont pas besoin d'alourdir le traitement des données des 18 derniers mois. Par ailleurs, une partition par mois paraît intéressante mais une partition par mois et années peut être plus intéressante encore (pour ne pas alourdir les données des 6 derniers mois avec celles de plus d'un an). En revanche, je te conseille de partitionner la table et non l'index :)
04/05/2006, 14h56
nuke_y

Pourquoi ne pas partitionner l'index ?
04/05/2006, 15h11
orafrance

c'est moins performant ;)
04/05/2006, 16h55
nuke_y

Mais si on partitionne les données par Année par exemple, et que l'index est aussi partitionné par année, on gagnera du temps non ?
05/05/2006, 00h18
plabrevo

1.200.000.000 lignes, ca peux necessiter de 20Gb as 20Tb, ou plus. Le volume devrait-il pas faire partie de la discussion ainsi que la strategie de sauvegarde/restauration actuellement suivie?
05/05/2006, 15h30
boisdin

données supplémentaires

Mes tables sont des tables d'archivage, elles contiennent des références à des documents archivés qu'il faut garder légalement pendant 10 ans; ce ne sont pas des doc actifs qui deviennent archivés ensuite.

Pour la partition j'ai manqué de précision, c'est effectivement par mois et années qu'elle devrait se faire.

Les lignes de la tables ont une longueur max de 160 c; au total avec les index, on devrait arriver à 450 Go.

Pour la stratégie de sauvegarde, vu que l'on écrit que sur la partition du mois en cours, je pense que ce sera la sauvegarde de la partition (au max 4 Go) à chaque alimentation (1 fois / semaine).

Par contre je suis surprise des réponses de Fred_d sur la partition des index, parce qu'on m'a dit le contraire !!
De plus pour la sauvegarde, ce serait mieux non ? on n'aurait que la partition d'index du mois en cours à sauvegarder
05/05/2006, 16h03
Nick_Holmes

J'aurai tendance à dire "à froid" :
table partitionnée => index partitionnés pour ne pas avoir de problème lors des mises à jour, reconstruction d'index, ...

Par contre pour un archivage règlementaire ou juridique, il vaut mieux sortir les données de la base et mettre tout à plat dans un format lisible perenne (ASCII). Une base ORACLE n'est pas considéré comme un produit stable dans le temps surtout sur une échelle de 10 ans.

@+,
NicK.
05/05/2006, 16h45
orafrance

Citation:

Envoyé par boisdin

Par contre je suis surprise des réponses de Fred_d sur la partition des index, parce qu'on m'a dit le contraire !!
De plus pour la sauvegarde, ce serait mieux non ? on n'aurait que la partition d'index du mois en cours à sauvegarder

J'ai déjà constasté des gains de perf en partitionnant un index mais l'architecture même d'un index ne devrait pas le nécessiter. C'est donc intéressant quand l'index devient très volumineux et dans ce cas, je ne vois pas l'intérêt de partitionner aussi la table, l'index permettant de trouver la ligne via le ROWID le partitionnement n'apporte rien :?
05/05/2006, 16h46
boisdin

en fait la base oracle sert à gérer l'accès à des documents qui sont stockés dans une baie Centera, matériel spécialisé dans l'archivage.
05/05/2006, 16h49
boisdin

Citation:

Envoyé par Fred_D

C'est donc intéressant quand l'index devient très volumineux et dans ce cas, je ne vois pas l'intérêt de partitionner aussi la table, l'index permettant de trouver la ligne via le ROWID le partitionnement n'apporte rien :?

L'interêt de partitionner la table et l'index est de réduire les sauvegardes à la partition du mois courant d'une part et ensuite de pouvoir supprimer les documents à la fin de la période légale par un drop de la partition.
05/05/2006, 17h53
plabrevo

Citation:

Envoyé par Nick_Holmes

...., il vaut mieux sortir les données de la base et mettre tout à plat dans un format lisible perenne (ASCII). Une base ORACLE n'est pas considéré comme un produit stable dans le temps surtout sur une échelle de 10 ans.

L'OS sur lequel serait stocke ces fichiers subit exactement les meme contraintes en maintenance et en support que le SGBD. Qui aujourd'hui travaille sur le meme OS qu'il y a dix ans? Les deux necessitent, pour etre supportes, leur mise a jour reguliere, si leur support est estime necessaire, car il est bien entendu qu'une oraclev6 tournera tout aussi bien aujourd'hui qu'il y a dix ans sur un Sequent/ptx depoussiere.
05/05/2006, 18h40
orafrance

Citation:

Envoyé par boisdin

L'interêt de partitionner la table et l'index est de réduire les sauvegardes à la partition du mois courant d'une part et ensuite de pouvoir supprimer les documents à la fin de la période légale par un drop de la partition.

après drop tu rebuild l'index et voila... aucun intérêt à le partitionner ;)
09/05/2006, 09h32
boisdin

Citation:

Envoyé par Fred_D

après drop tu rebuild l'index et voila... aucun intérêt à le partitionner ;)

Une des conditions imposée par l'administration du système est qu'il n'y ait pas de rebuild d'index parce que la base est censée être disponible 24h/24 7j/7, et que sur le nombre d'enregistrements, ça risque de prendre du temps.:(
09/05/2006, 09h35
LeoAnderson

Dans la version ENTERPRISE, les indexes peuvent être rebuildés ONLINE ! ;)
09/05/2006, 13h11
Nick_Holmes

Citation:

Envoyé par plabrevo

L'OS sur lequel serait stocke ces fichiers subit exactement les meme contraintes en maintenance et en support que le SGBD. Qui aujourd'hui travaille sur le meme OS qu'il y a dix ans? Les deux necessitent, pour etre supportes, leur mise a jour reguliere, si leur support est estime necessaire, car il est bien entendu qu'une oraclev6 tournera tout aussi bien aujourd'hui qu'il y a dix ans sur un Sequent/ptx depoussiere.

Le but n'est pas de laisser les fichiers de données sur un OS particulier mais bien de pouvoir les transporter d'un OS ou d'une machine à un autre. Pour les grosses entreprises, il y a même des systèmes de robot d'archivage avec des serveurs "tampons" qui réceptionnent les fichiers avant traitement d'archivage proprement dit. On peut alors compresser, chiffrer les données, ...
Ces systèmes sont prévus pour être les plus souples possibles en terme de récupération de tes données.

@+,
NicK.
10/05/2006, 10h52
boisdin

Citation:

Envoyé par Fred_D

une table (ou base) à part me parait plus judicieux. En effet, les données anciennes n'ont pas besoin d'alourdir le traitement des données des 18 derniers mois. Par ailleurs, une partition par mois paraît intéressante mais une partition par mois et années peut être plus intéressante encore (pour ne pas alourdir les données des 6 derniers mois avec celles de plus d'un an). En revanche, je te conseille de partitionner la table et non l'index :)

N'étant pas toujours maître des décisions qui sont prises, et alors que j'étais plutôt favorable à cette solution de base répartie, je me vois imposer par le client une seule base partitionnée au niveau des données ET de l'index sur l'année et le mois.
Les données imposées sont un tablespace pour toutes les data, un tablespace pour tous les index;
Je me pose d'abord une question, est-ce judicieux de partitionner la table pour mettre toutes les partitions data dans le même tablespace et toutes les partitions index dans le même tablespace ?

Le problème que j'ai ensuite c'est de déterminer les tailles initiales et des extends pour ces tablespaces
Par exemple le tablespace data sur les 10 dernières années (en Go)

année 1 : cumulé 19 /mois 1.61
année 2 : cumulé 40 /mois 1.69
année 3 : cumulé 61 /mois 1.78
année 4 : cumulé 83 /mois 1.86
année 5 : cumulé 106 /mois 1.96
année 6 : cumulé 131 /mois 2.06
année 7 : cumulé 157 /mois 2.16
année 8 : cumulé 184 /mois 2.27
année 9 : cumulé 213 /mois 2.38
année 10 : cumulé 245 /mois 2.50

Faut-il prévoir un tablespace qui va contenir à peu-prêt tout en allocation primaire c'est à dire 250 Go et des extends de 100Mo ou faut-il prévoir une allocation primaire qui correspond à la taille d'une partition (entre 1.5 go et 2.5Go) et des extends similaires ?
11/05/2006, 00h25
plabrevo

Desole pour le leapfrog :).

Citation:

Envoyé par Nick_Holmes

Le but n'est pas de laisser les fichiers de données sur un OS particulier mais bien de pouvoir les transporter d'un OS ou d'une machine à un autre. Pour les grosses entreprises, il y a même des systèmes de robot d'archivage avec des serveurs "tampons" qui réceptionnent les fichiers avant traitement d'archivage proprement dit. On peut alors compresser, chiffrer les données, ...
Ces systèmes sont prévus pour être les plus souples possibles en terme de récupération de tes données.

Soit. Mais les contraintes sont les meme pour le logiciel d'archivage. Un logiciel d'archivage, non mis a jour depuis 15ans, ne serait capable de supporter aujourd'hui que des cartouches 150Mb.
11/05/2006, 11h53
Nick_Holmes

Exact. Mais si tu as plusieurs applications qui archivent des données que tu concentres en un seul système d'archivage, tu n'as "que" ce système à maintenir et mettre à jour. C'est plus simple et plus réaliste en terme de maintenance, de coût, ... Rappel : le but premier est quand même de maintenir au maximum une inter-opérabilité avec tous les systèmes possibles (ce qui reste un voeu pieux dans l'absolu) pour pouvoir lire & exploiter tes données. Il faut donc être le plus indépendant possible des logiciels et du système. Aucune solution à ma connaissance n'est parfaite. :)

@+,
NicK.
11/05/2006, 19h47
plabrevo

Le cout est sans doute un parametre. Je voulais surtout intervenir sur la notion de stabilite a long terme.

Softa-Conseil fournit justement une de ces solutions d'archivage generique et a moindre cout: http://www.softa-conseil.com/prod.htm