Datapump import/export full et génération de stats

Amis DBA, bonjour,

Chez un client on exécute une procédure d'export/import datapump full de la base.
Après cela, il y a recalcul des stats de toute la base, des fixed_objects, du dictionnaire de données... : cela est long, TRES long et je me demandais si c'était obligatoire.

J'avais lu que quand Oracle crée un index il calcule automatiquement les stats.
Mais quid des tables? Alors bien sur, sauf pour un CTAS, pas besoin de générer des stats quand on créé la table car elle est créée vide mais, dans le cas d'un import datapump, on crée une table avec des données donc est-ce que les stats sont générées en même temps?
J'aimerai bien votre avis sur la question :D

A+

Bonjour,

Il y a un recalcul des stats, mais dans l'import elles ont été exclues? C'est un import d'un schéma où de toute une base?


Depuis la 12.1 Oracle calcule automatiquement les statistiques pour des chargement en masse de données (Online Statistics Gathering for Bulk Loads) :

https://docs.oracle.com/database/121...n.htm#TGSQL344

Ce n'est que pour les tables, pas les index. Tu pourras toujours le faire après coup avec DBMS_STATS.GATHER_SCHEMA_STATS / DBMS_STATS.GATHER_DATABASE_STATS) et l'option GATHER AUTO.
Depuis la 12.1, tu peux également calculer les stats sur plusieurs table en même temps avec la nouvelle préférence de stat CONCURRENT:

https://docs.oracle.com/database/121...E-16B46B78EFA9

Enfin, tu peux aussi désactiver la génération de redo depuis la 12.1 quand tu fais un import:
https://oracle-base.com/articles/12c...logging-option

Bonjour,

1) Personnellement, je n'ai jamais été un grand fan de l'export FULL. Je le trouve dangereux, car il embarque des objets de SYS et de SYSTEM. Je préfère largement travailler au niveau SCHEMAS.


2) Datapump est un outil qui prend en compte les statistiques en les transportant. Lors de l'export Datapump, les statistiques des tables et index figurent dans le fichier Dump. Et lors de l'import, ces statistiques sont rechargées dans le catalogue Oracle.

Pour moi, et à moins que la base de données source soit complètement fragmentée et désorganisée, cela ne sert à rien de calculer des statistiques après import.


3) Sinon oui, lorsque l'on crée un index, les statistiques sont automatiquement calculées. Cela est logique, car la création d'un index (sur une ou plusieurs colonnes d'une table) implique que l'on balaye entièrement la table (Full Scan de table) afin de lire les données des colonnes de la table, données qui vont constituer les clés de l'index.

Du coup, en lisant les données des colonnes, on peut mémoriser en même temps les valeurs MIN et MAX par colonne, le nombre de NULL, etc, etc, ce qui fait que l'on a implicitement les statistiques de l'index.



4) Quid des tables ?

Et bien, mise à part les nouveautés (comme celles citées par vanagreg) qui apparaissent au fur et à mesure des versions, pour les tables, si on ne fait rien, il faut attendre la nuit !

Je m'explique : en cours de journée, on peut très bien créer une table. Que l'on laisse cette table vide, qu'on la remplisse un peu ou beaucoup, cette table n'a aucune statistique (je mets de côté la nouveauté du calcul de stats suite à un chargement massif).

De même, on peut prendre une table existante (qui contient des données et qui a des statistiques à jour, donc propres) et s'amuser à la truncater ou la purger, lui insérer des nouvelles données. Bref, au final, on se retrouve avec une table dont les données ont varié, et les statistiques de cette table ne sont plus bonnes (Stale Statistics), car plus conformes à la réalité des nouvelles données.

La Best Practice, c'est de lancer soit-même un calcul des statistiques dans la foulée. Mais cela, peu de gens le font.

Du coup, si on ne fait rien, c'est durant la nuit qu'Oracle va prendre en charge le calcul des statistiques sur les tables qui en ont besoin.

Depuis au moins la version 11g, Oracle dispose de ce qu'on appelle les Auto Tasks. Ce sont des tâches d'administration déclenchées par le Scheduler Oracle, tâches qui sont planifiées dans une fenêtre de maintenance du Scheduler.

Parmi ces tâches figure l'Automatic Optimizer Statistics Collection.

Cette tâche va s'appuyer sur la vue DBA_TAB_MODIFICATIONS pour détecter les modifications de données sur une table depuis son dernier calcul de statistiques. Si ces modifications dépassent le seuil par défaut de 10 %, alors les statistiques sont recalculées.




Sinon une question STP Ikebukuro : pourquoi cette procédure d'export / import full chez ton client ?
Pour reconstruire une base de données existante ?
Pour rafraichir une base d'un autre environnement ?

Je vous remercie pour vos réponses :D

Alors oui, lors de l'export chez le client, il y avait un EXCLUDE=AUDIT, STATISTICS donc il fallait bien régénérer les stats après coup.
D'où une autre question : est-ce une bonne pratique pour vous de garder les stats lors d'un export? Perso je les exclurais systématiquement car à cause de la fragmentation sur la base source, on peut avoir des stats fausses sur les nb de blocs de la table, en plus je ne sais aps ce que ces stats comportent (stats de tables? d'index? du dictionnaire de données etc etc).

Ah, dernier point, quand je lis "je n'ai jamais été un grand fan de l'export FULL. Je le trouve dangereux, car il embarque des objets de SYS et de SYSTEM. Je préfère largement travailler au niveau SCHEMAS" ça me parle car j'ai eu des infos contradictoires; certains DBA m'ont dit que SYS était exporté, d'autres que non car on ne va pas, lors de l'import, écraser le schéma SYS avec les données système d'une autre base... J'ai donc fais mes test, à lire ici si cela vous intéresse : http://dbaoraclesql.canalblog.com/ar.../38415892.html
En résumé : seuls quelques objets de SYS sont exportés mais certainement pas le schéma en entier.

Ah, ultime dernier point : depuis la 12, il existe une colonne ORACLE_MAINTAINED dans DBA_USERS, elle permet d'isoler les users Oracle de ceux applicatifs; voir si on peut mettre SCHEMAS=select username from dba_users where ORACLE_MAINTAINED='N' pour récupérer que les users applicatifs sans avoir à les taper à la main...

Je pense que la meilleure réponse est là:

Citation:

---

Envoyé par rouardg

Sinon une question STP Ikebukuro : pourquoi cette procédure d'export / import full chez ton client ?
Pour reconstruire une base de données existante ?
Pour rafraichir une base d'un autre environnement ?

---

Suivant la raison de l'export/import on peut vouloir soit des nouvelles stats (pour refléter les tables actuelles) soit les anciennes (pour être plus proche de la source)
Et peut-être voir une autre méthode de copie de base

Sinon, c'est très dangereux de ne pas importer les stats et de les recalculer avec le method_opt par défaut qui est ALL COLUMNS SIZE AUTO car il n'y aura plus d'histogrammes du fait que l'historique des prédicats utilisés est perdu.
Une histoire vécue: https://blog.dbi-services.com/a-migr...umn-size-auto/

La situation est simple : le client a un datawarehouse et il veut l'alimenter avec les données de la prod, d'où un export full de la base de prod.

Au fait, quand on exclue les stats lors de l'export, on est d'accord pour dire que lors de la régénération des stats suite à l'import, on perd les stats étendues sur plusieurs colonnes? J'avais compris que ces stats étendues étaient générées automatiquement par Oracle MAIS pour cela il détecte sur N jours qu'il y a plusieurs requêtes avec ces colonnes, donc il y a la notion d'historique qui joue; donc faire une régénération des stats suite à l'import ne va pas recréer ces stats et, par voie de conséquence, le CBO peut donner un mauvais plan d'exécution. On est d'accord?

Citation:

---

La situation est simple : le client a un datawarehouse et il veut l'alimenter avec les données de la prod, d'où un export full de la base de prod.

---

De ma petite expérience, je n'avais encore jamais vu un client faire un export full de sa base de prod pour alimenter un Datawarehouse.

L'approche traditionnelle est plutôt d'utiliser un ETL (comme Powercenter de l'éditeur Informatica) pour aller puiser les données dont on a besoin depuis des sources de données hétérogènes (ici la base de prod du client serait une source de données), pour alimenter en final le Datawarehouse.

Souvent, la base du Datawarehouse se divise en 3 grandes parties : Staging, Dataware et Datamarts.


Mais ok, supposons que le client préfère alimenter son Datawarehouse cible avec un export de sa base de prod, en utilisant donc Datapump comme outil plutôt qu'un ETL. Et supposons aussi qu'il fasse un export full pour avoir sous le coude toutes les données de sa base dans le dump, des fois qu'il en manquerait.

Il en fait quoi ensuite de son Dump ?

Supposons malgré tout que le Dump soit importé (en partie ou en totalité) dans le Datawarehouse, en tant que données de Staging. Ces données dites de staging servent en général à alimenter la partie purement datawarehouse de la base.

C'est-à-dire que l'on va prendre les données sources, les qualifier, les vérifier, les enrichir, les retraduire, les mettre en forme et les harmoniser avec d'autres données ou d'autres référentiels pour alimenter les tables du Datawarehouse, tables volumineuses qui ont pour vocation à stocker sur de très longues durées les données.

Du coup, les index et statistiques étendues présents sur les tables importées de la base source ne sont pas forcément les meilleurs candidats pour alimenter les tables du Datawarehouse ?

Comme je le disais, je suis vraiment dubitatif sur cette façon de procéder.

Pour info mon client travaille à l'ancienne : pas de sauvegarde RMAN mais, tous les soirs, un expdp full puis il ferme la base et utilise NetBackup pour faire une copie des fichiers Unix de la base, pas de Diagnostic pack ou Tuning pack sur toutes les bases, un Cloud Control plus plus que bancal et difficilement exploitable etc etc; et je ne parle pas des versions Standard d'Oracle qui sont installées plutôt que Entreprise...

Bref, je ne suis pas en contact direct avec ce client donc sa façon de travailler ne changera pas : expdp full de la prod puis impdp full dans le dw; après, comment il retraite les données importées... aucune idée.

Merci pour la réponse.

Oui j'ai connu ce genre de client qui travaille effectivement à l'ancienne.

En 2010, j'avais le même genre de client qui considérait qu'un export de base constituait une bonne sauvegarde. Il faisait aussi la nuit des sauvegardes à froid de ses bases sensibles (Peoplesoft Finances et RH notamment), via Netbackup.

Comme les sauvegardes sur bande mettaient plusieurs heures, pour ne pas interrompre le service pendant tout ce temps, il avait contourner le pb en créant un Snapshot de ses FS. Puis il redémarrait ses bases pendant que Netbackup faisait une sauvegarde des fichiers, non pas sur les FS, mais sur les Snapshots des FS.

Cette possibilité de Snapshot était une fonctionnalité de ses baies de disque de l'époque (baies HP EVA).

Lorsqu'on lui a parlé de faire des sauvegardes à chaud avec RMAN, il était enthousiaste. Mais son enthousiasme s'est tout de suite arrêté lorsqu'il a appris qu'il devait payer pour l'agent RMAN de Netbackup. Du coup, on n'a jamais mis en place RMAN chez ce client.


Pour terminer, je ne peux répondre à ta question concernant les statistiques étendues, car je ne l'ai utilisée qu'une seule fois, il y a fort longtemps.

Et surtout, cela fait presque 3 ans que je ne fais plus d'Oracle, depuis que je suis passé dans le monde merveilleux du Big Data :ptdr: