Si vous travaillez avec d’importants volumes de données, il se peut que le système n’accède que très lentement au niveau de l’objet (par exemple, pour affecter les données aux niveaux de compression). Puisque l’installation standard du système R/3 n’est pas optimisée pour le traitement de volumes élevés de données dans CO-PA, vous disposez de nombreuses options de mise au point si vous effectuez une répartition physique des données entre les disques durs disponibles.

Les informations suivantes s’appliquent aux versions 2.1 à 3.0B. Depuis la version 3.0C, vous pouvez utiliser les niveaux de compression pour qu’il ne soit pas toujours nécessaire d’accéder à la table d’objets et au niveau de l’objet dans les fonctions en ligne.

Toutefois, il est toujours nécessaire d’accéder à la table d’objets et au niveau de l’objet lorsque vous affectez les données aux niveaux de compression ou si vous utilisez des données de compression spécifiques à l’état comme dans la version 2.2.

Pour éviter d’accroître la complexité d’une installation R/3 standard, les tables CE3xxxx et CE4xxxx (où le périmètre de résultat = xxxx) sont toujours créées dans le tablespace PSAPBTABD. Les index correspondants figurent dans le tablespace PSAPBTABI.

Lorsque le système lit d’importants volumes de données depuis le niveau de l’objet, il accède plusieurs fois aux mêmes disques durs. Par conséquent, ces disques durs fonctionnent régulièrement aux limites de leur capacité de volume de travail et restreignent ainsi les performances globales de la procédure de lecture. Les processeurs impliqués prennent habituellement le statut « Idle » (temps mort) ou « Wait » (temps d’attente) pendant ce temps.

Si cette situation se produit, le système est dit « limité par la vitesse d’entrée/sortie » (I/O-bound). Si vous répartissez les données entre plusieurs disques durs, vous pouvez augmenter considérablement les performances globales du système.

Dans les installations standard, le système peut généralement lire environ 200 000 enregistrements par heure depuis le niveau de l’objet. Ces performances ne dépendent absolument pas du matériel utilisé.

Toutefois, si vous disposez de quatre tablespaces (par exemple, PSAPCE4D, PSAPCE4I, PSAPCE3D et PSAPCE3I) enregistrés sur quatre disques durs différents, vous pouvez répartir les données dans CO-PA comme suit :

• table CE4xxxx dans le tablespace PSAPCE4D ;

• index CE4xxxxn de la table CE4xxxx dans le tablespace PSAPCE4I ;

• table CE3xxxx dans le tablespace PSAPCE3D ;

• index primaire CE3xxxx0 de la table CE34xxxx dans le tablespace PSAPCE3I.

Si aucune donnée n’a encore été enregistrée dans l’Analyse du compte de résultat dans votre système, il vaut mieux redéfinir les paramètres de ces objets de base de données à l’aide de l’utilitaire de base de données (transaction SE14). Autrement, vous serez obligé d’exécuter le long processus de sauvegarde des données existantes avant la conversion et leur restitution successive.

Cette « mini-solution », facilement réalisable, permet habituellement d’augmenter la vitesse type à laquelle le système lit le niveau de l’objet à environ 500 000 enregistrements par heure.

Malgré l’augmentation des performances obtenue à l’aide de la distribution simple des données décrite ci-dessus, les systèmes munis de puissants processeurs risquent d’être toujours limités par la vitesse d’entrée/sortie. Dans ce cas, vous pouvez prendre des mesures supplémentaires afin de répartir le volume de travail d’entrée/sortie.

La rubrique suivante aborde uniquement l’agrégation par bandes (striping) au niveau du matériel, que le système de base de données prend en charge de manière transparente dans la plupart des cas.

Lors de l’agrégation par bandes, les fichiers sont créés au niveau du système d’exploitation et enregistrés (en petites parties) sur le plus de disques possible. Cette agrégation part du principe selon lequel le système lit plus rapidement au hasard dans ce type de fichier parce que le temps nécessaire au positionnement de la tête de lecture peut être éliminé ou que l’opération peut être exécutée plusieurs fois simultanément. Comme le fichier est enregistré sous forme de bandes (« stripe ») sur les différents disques, il s’agit d’agrégation par bandes (« striping »). Les disques impliqués sont appelés « agrégats par bandes » (« stripe sets »).

Les fichiers répartis sur les divers disques servent ensuite à créer un tablespace. Le système de base de données voit le tablespace comme une séquence consécutive de blocs, utilisés pour les EXTENTS d’une table. Le périmètre de résultat assure que les accès en mode lecture aléatoire s’effectuent le plus souvent possible sur des disques différents. La « largeur » d’une bande doit correspondre à la taille des blocs de la base de données (généralement 8 Ko).

Vu la façon dont le système accède aux données dans l’Analyse du compte de résultat, il vaut mieux enregistrer les tables CE3xxxx et CE4xxxx (ainsi que leurs index) dans plusieurs tablespaces différents afin de diriger les accès en mode lecture consécutifs de la recherche vers le maximum de disques physiques (et permettre ainsi une exécution simultanée).

En plus de l’agrégation par bandes, vous devez également vous assurer que les blocs physiques des tablespaces sont utilisés de manière optimale (pour ORACLE, par exemple, PCTFREE=1 et PCTUSED=99). En outre, les tables doivent contenir le moins d’EXTENTS possible. Il faut donc que le volume de données attendu soit analysé avec attention.

Lorsque vous utilisez les agrégats par bandes, vous devez tout particulièrement veiller à sauvegarder vos données. Rappelez-vous que si un seul disque dur contenant une partie d’un agrégat par bandes ne fonctionne plus, l’ensemble de l’agrégat par bandes ne peut généralement plus être utilisé et doit être restauré à partir d’une sauvegarde des données et du protocole d’archives correspondant.

Cette opération peut prendre beaucoup de temps, surtout si vous utilisez la solution « ad hoc » décrite ci-dessus (agrégation par bandes de tous les tablespaces sur tous les disques durs).

La réalisation technique de ces recommandations varie selon la base de données et les systèmes d’exploitation utilisés.