[Réglé] Fragmentation des tables de la base Nexus

[scp]

Bonjour,

Il apparaît que certaines des tables de la base de données Nexus font l'objet, après des mois d'exploitation, d'un taux de fragmentation plutôt important : plus de 15 000 fragments pour DETFACT.nx1, plus de 10 000 pour DETFACT.NXI ou STATS.nx1 !

Avez-vous prévu des dispositions pour corriger ce phénomène entropique, par exemple un processus s'appuyant sur une fonction discrète du moteur Nexus ?

Dans le cas contraire, quelles sont vos recommandations ?

D'avance merci.

[Alexandre]

faites vous référence à la fragmentation des blocs au sein du fichier de données (gestion interne du serveur Nexus) ou de la fragmentation du fichier par le système de fichier ?

Dans un cas comme dans l'autre rien n'est prévue de façon automatique.

Pour le premier cas, un pack (ou reindex) des tables depuis l'Enterprise Manager rééquilibre les blocs et les indexes. Il doit être fait hors production et nécessite l'arrêt des systèmes (hors NxServer bien sur)

Dans le second, une defragmentation du disque en utilisant les outils de votre OS suffisent

[scp]

Bonjour,

Désolé, vous avez raison, ma question souffrait d'imprécisions.

Il ne s'agissait pas de l'aspect "gestion interne des blocs" qui relève du fonctionnement interne de Nexus (l'exploitant n'a - a priori et sans recommandations de votre part - rien à y faire), mais puisque vous abordez cet aspect et qu'une fonction existe dans ce SGBD :
- en recommandez-vous l'usage et dans quelles circonstances ?
- dans l'affirmative, disposez-vous d'une note de procédure simple utilisable ?

En ce qui concerne le motif d'inquiétude ayant motivé la question d'origine, il s'agit bien de la fragmentation des fichiers de tables, du point de vue du système de fichiers.

Je vous remercie pour votre réponse sur ce point, simple et concise : nous ferons donc appel aux outils classiques de défragmentation, moteur Nexus à l'arrêt.

Cordialement

[scp]

Bonjour,

Comme indiqué supra, le nombre très élevé de fragments de certaines tables de la base Nexus commençait à générer une certaine inquiétude, de même que le taux de fragmentation du disque qui héberge ces données (+ de 81% !).

Suivant vos indications, une opération de défragmentation a permis de remettre de l'ordre, du point de vue du système de fichiers.

Du point de vue interne à Nexus, une documentation du processus de "pack" (ou "reindex") des tables depuis l'application nxEntrepriseManager est elle disponible ? Quelles sont les circonstances où ce processus doit être employé (sur quels critères) et par qui : le support ABM ou l'utilisateur ABM ?

Cordialement

[Romain]

Bonjour,

Il n'existe pas en ma connaissance de documentation sur cette fonctionnalité.

Elle est utilisée par notre service lorsque une ou plusieurs tables présentes des problèmes d'écritures.

Cordialement.

Le Support ABM.

[scp]

Merci pour la rapidité de votre réponse.

Nous en concluons qu'en l'absence actuelle de problèmes perceptibles sur ces tables, nous nous contentons de la défragmentation "fichiers" citée supra.

Cordialement

[scp]

Bonsoir,

Je me permets de rouvrir ce fil, car je suis toujours perplexe devant la possible fragmentation interne des tables de la base de données Nexus (le degré élevé de fragmentation des fichiers des tables - au sens du système de fichiers - me porte à croire que l'organisation interne des données souffre de maux sinon identiques, du moins similaires).

Si - a priori - il ne semble pas que les performances doivent baisser au fur et à mesure que les tables grossissent (Cf. http://www.nexusdb.com/forums), l'espace disque consommé doit cependant être directement proportionnel à l'âge des tables (plusieurs années d'activité dans notre cas).

D'après vos réponses, vous ne pratiquez d'ordinaire qu'un traitement curatif de type "packing/reindexing" "lorsque les tables présentent des problèmes d'écriture", mais ne serait-il pas pertinent / judicieux / efficace d'appliquer un traitement similaire de manière préventive ?

Quel est votre avis sur cette question ?

Cordialement.

[Romain]

Bonjour,

Cela ne pose bien évidement aucun souci d'ordre technique d'effectuer ces manipulations à des fins préventives.

Sur des tables importantes en termes de taille, je pense à STATS, DETFACT, PABX... Vous pouvez faire un Recover Records (il copie les données vers une table neuve*) suivi d'une réindexation (ou pack).
Ceci les applications éteinte (sauf NexusDB) comme dit par Alexandre.




*Il crée 2 table:
- Une table se terminant par Failed, contenant les enregistrements qui n'ont pas pu être copiés. Vous pouvez la supprimée.
-Une autre table se terminant par recovered, qui est la nouvelle table. Renommer l'ancienne par le suffixe Old (par exemple). Et la nouvelle par son nom habituelle.

Puis la réindex (ou pack) peut être faite.

[scp]

Bonjour,

Merci d'avoir si rapidement approuvé notre démarche et de nous avoir donné la démarche générale du processus.
D'un point de vue plus "terre à terre", quelles sont les manipulations exactes à réaliser, et avec quels outils/logiciels, dans quel ordre et en veillant à quels détails ?
Pour vous, "faire un Recover Records" est probablement une manipulation anodine, de même qu'une réindexation, mais c'est pour nous bien plus extraordinaire...
Nous ne sommes pas des spécialistes des BDD et nous craignons les fausses manœuvres du fait de notre manque de maîtrise.
Merci d'avance pour ces précisions indispensables.

Cordialement.

[Romain]

PROCEDURE DE REPARATION DE TABLES NEXUS
(Vous ne devez pas faire ces manipulations sans l'accord de l'équipe technique)

NIVEAU: EXPERT




- Fermer TOUT les applicatifs ABM (sauf le serveur Nexus). Vous devez avoir dans la partie statistics > Server engine, le nombre de sessions égale a "0".

- Ensuite dirigez vous dans le répertoire ABM2000, où vous trouverez l’outil NxEnterpriseManager, exécuté le.

- Sélectionner CONTACT > Table. Vous avez alors la liste de toutes vos tables.

- Cliquez droit sur la table a réparée, puis sélectionnez l'option Recover Records.

- Une fois l'opération finie vous disposez alors de 2 tables supplémentaires, MaTable_failed et MaTable_Recovered.-

- Ouvrez la table MaTable_failed et vérifier que vous n'avez rien dedans (99% de chance que ce soit le cas), si vous avez des enregistrements dedans, c'est qu'ils n'ont pas pu être copiés.

- Supprimer cette table si rien n'est présent dedans. Par un clique droit dessus puis "Delete Table".

- Il vous reste donc 2 Tables, celle d'origine et MaTable_Recovered.

- Pour terminer la réparation, il ne vous reste plus qu'a réindexer la nouvelle table (MaTable_Recovered).

- Cliquez droit sur votre nouvelle table (MaTable_Recovered) puis choisissez l'option "Reindex", sélectionnez la première option dans la liste et valider.
- Ouvrez MaTable_Recovered puis sélectionnez dans les menus du haut, "Table View" et "Show Record count" afin d'afficher le nombre d'enregistrement.

- En bas de la fenêtre des données vous avez le nombre d'enregistrement. Garder le en tête. Puis répéter la même opération pour MaTable.

- Vous devez avoir le même nombre d'enregistrements. Si tel n'est pas le cas c'est que des enregistrements n'ont pas pu être copiés. Si la différence est trop importante, arrêtez là et prenez contact avec nous. Cela n’entrave pas le bon fonctionnement de votre base de données.

- Renommer ensuite MaTable par MaTableOld.

- Renommer ensuite MaTable_Recovered par MaTable. (Ex: AGENDA_Recovered -> AGENDA).

- Vous avez alors une nouvelle table.

- L’opération est finie, vous pouvez relancer l’ensemble des applications.