Discussion :

[boisdin]

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

[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

[nuke_y]

Pourquoi ne pas partitionner l'index ?

[orafrance]

c'est moins performant

[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 ?

[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?

[boisdin]

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 ?