> Tech > Conclusions

Conclusions

Tech - Par iTPro - Publié le 24 juin 2010
email

Les entreprises qui opèrent dans des environnements contenant un mix d’index créés par SQL et de fichiers logiques indexés DDS, pourront souvent améliorer la performance en partageant judicieusement les chemins d’accès SQL. Le partage des chemins d’accès SQL se traduira par moins de maintenance des chemins d’accès.

Les entreprises

qui ont un grand nombre de fichiers logique indexés amélioreront souvent la performance par suite de la recréation des fichiers logiques après que des index SQL comparables aient été créés. La raison en est que certains fichiers logiques ont peut-être été créés dans le désordre (par exemple, le chemin d’accès K1, K2 étant créé après le chemin d’accès K1). La création des chemins d’accès en commençant par les colonnes de plus forte clé, peut se traduire par moins de chemins d’accès. En outre, la première application qui lira une page d’index bénéficiera aux autres applications qui auront besoin de référencer la même page d’index.

Les entreprises qui ont beaucoup de fichiers logiques indexés anciens encore définis en utilisant une taille de chemin d’accès de *MAX4GB constateront peut-être une amélioration des performances due à moins de conflits d’appropriation des chemins d’accès pendant la maintenance des index. Cela résulte de la maintenance simultanée que l’on peut employer quand les chemins d’accès sont créés à l’aide de la nouvelle taille de chemin d’accès *MAX1TB.

Côté inconvénient, les entreprises limitées en mémoire constateront parfois davantage de fautes à cause de la plus grande mémoire qu’exige le chemin d’accès à 64 K. Ces entreprises devront progresser de manière plus prudente, peut-être en recueillant des données de performance avant et après chaque changement de fichier logique.

Les applications qui utilisent les fichiers logiques select/omit constateront parfois une certaine dégradation des performances en ajoutant le motclé DYNSLT, car il peut y avoir alors un certain délai avant que les enregistrements ne soient renvoyés au programme applicatif. L’ajout de DYNSLT peut modifier sensiblement la performance des applications existantes et il ne faut le pratiquer qu’après avoir pesé les éventuelles conséquences. Si vous devez revenir au fichier logique initial pour des raisons de performances, le seul fait de supprimer le mot-clé DYN SLT et de recréer le mécanisme logique rétablira le chemin d’accès précédent et éliminera le délai.

Sachez que, dans le cadre de la modernisation de la base de données, si vous avez l’intention de remplacer vos méthodes d’accès au niveau d’enregistrement héritées par SQL, il vous faudra remplacer les techniques anciennes comme les fichiers logiques select/omit par des méthodes d’accès indexées plus efficaces. Les applications qui utilisent ces fichiers devraient être modernisées en priorité.

Téléchargez gratuitement cette ressource

Protection des Données : 10 Best Practices

Protection des Données : 10 Best Practices

Le TOP 10 des meilleures pratiques, processus et solutions de sécurité pour mettre en œuvre une protection efficace des données et limiter au maximum les répercutions d’une violation de données.

Tech - Par iTPro - Publié le 24 juin 2010