Discussion :

[atporfi]

Bonjour!

Je travaille sur une base oracle 9.2.0.3 et oracle application 11i ERP(E_Business Suite)
Je voudrai bien faire le suivi de l'augmentation de nombres d'enregistrements (lignes) pour chaque table mais sans avoir à préciser leur nom individualement comme dans la rquête suivante :
select count(*) from NomDeMatble
En fait ,je voudrai bien généraliser cette requête pour toutes les tables (car ma base contient enormément de tables ) et ça sera trop si je dois saisir par nom pour avoir le nombre total des ligne ?
Si vous avez une idée oû un script qui pourra m'aider à réaliser cela ,pour ensuite pouvoir mettre cette reqûete ou script en tâche planifiée !

Merci pour votre aide !

[LeoAnderson]

Si les stats sont à jours (ce qui est le cas normal sur une base), il vous suffit de faire :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select table_name ,num_rows from dba_tables;

Attention : le résultat ne sera pas super précis (date du dernier calcul) mais fourni un bon ordre d'idée.

[Pomalaix]

En fait ,je voudrai bien généraliser cette requête pour toutes les tables (car ma base contient enormément de tables ) et ça sera trop si je dois saisir par nom pour avoir le nombre total des ligne ?

Bonjour

Le problème n'est pas du tout de devoir citer toutes les tables, mais le temps que ça prendrait d'effectuer physiquement le count(*) sur toutes vos tables.

Vous pourriez exécuter le résultat de cette requête :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT 'SELECT COUNT(*) FROM ' || TABLE_NAME || ';' FROM DBA_TABLES WHERE OWNER='&NOM_SCHEMA';

mais pour des raisons de performances, ça n'est pas recommandé, et la proposition de Leo est bien plus adaptée.

[Invité]

Je confirme, j'avais fait une fonction avec une vue associée pour faire la même chose et ce n'est pas vraiment optimum.
Dans un cadre temporaire de développement, ça dépanne, surtout quand tu cherches à avoir des infos toutes les 10 minutes.

Pour info, ça donnait ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
CREATE OR REPLACE FUNCTION F_COUNT(TABLE_NAME IN VARCHAR2) RETURN NUMBER AS
request VARCHAR2(300);
nb_lines NUMBER;
BEGIN
  request := 'SELECT COUNT(*) FROM ' || TABLE_NAME;
  EXECUTE IMMEDIATE request
  INTO nb_lines;
  RETURN nb_lines;
 
EXCEPTION
WHEN others THEN
  RETURN NULL;
END F_COUNT;
 
CREATE OR REPLACE force VIEW F_COUNT_ALL(TABLE_NAME,   nb_lines_reel,   nb_lines_stat,   last_analyzed) AS
SELECT ut.TABLE_NAME,
  F_COUNT(ut.TABLE_NAME) nb_lines_reel,
  ut.num_rows nb_lines_stat,
  ut.last_analyzed
FROM user_tables ut
ORDER BY ut.TABLE_NAME;

Pour une approche intelligente, autant lancer le calcul des stats puis piocher les infos dans la vue USER_TABLES (ou assimilées).

[orafrance]

et surtout faut se poser la question de l'exploitation du résultat... parce que plus de 40000 tables, j'vois pas bien l'intérêt d'avoir une info si excaustive. Tu peux déjà te limiter au 10 ou 20 tables les plus grosses or APPLSYS (ou seulement les requests) et SYS ou SYSTEM.

NUM_ROWS c'est déjà pas mal comme info

[atporfi]

Bonjour !
Je suis tte à fait d'accord avec vous càd viser les plus grosses tables en premier lieu mais si je dois me baser sur le num_rows selon les stats (les plus recement calculées)
Quelle serait la fréquence (idéale) de calcul des stats la plus conseillée pour ma base ,car je ne sais pas si c nécessaire de le faire quotiennement ou chaque fin de semaine !
Sachant que nous sommes en ce moment sur une base prod et j'ai peur que la taille des tables augmente rapidement ,ce qui me pousse à avoir une idée globale sur l'évolution du nombre d'enregistrements

Merci pour votre collaboration !

[LeoAnderson]

Il n'y a pas de fréquence idéale absolue, sinon, ça aurait déjà été automatisé !

Mais en 9i, il y a les LIST_STALE et GATHER_STALE sur des tables MONITORING....

[atporfi]

Enfin, si je vous demande "la fréquence" parapport à votre experience pratique ,quelle serai votre réponse ?

[LeoAnderson]

sur certaines tables, une fois par migration (8i, 9i, ...), sur d'autres, tous les jours.

[atporfi]

C parfait ,je crois qu'il vaut mieux le faire qotidiennement et comme ça je seari ammener à automatiser ma requête de calcul de (num_rows) en crontab chaque fin de journée ,et ceci me permettra de faire un bon suivi ,car notre administrateur systeme veut avoir une idée globale sur lataille de labase de donnée

Merci pour votre aide précieuse!

[pifor]

En 10g, le job créé par défaut GATHER_STATS_JOB s'exécute par défaut toutes les nuits entre 22H et 6H et durant le week-end. Il calcule les statistics sur les objets qui n'ont pas de statisques et sur les objets dont au moins 10% des lignes ont été modifiées.

[orafrance]

d'exérience, dans OeBS, tous les jours c'est très compliqué quand tu commences à avoir du volume... creuse l'idée de MONITORING de Leo qui fonctionne parfaitement

[LeoAnderson]

d'exérience, dans OeBS, tous les jours c'est très compliqué quand tu commences à avoir du volume... creuse l'idée de MONITORING de Leo qui fonctionne parfaitement

C'est d'ailleurs ce que fait le job de la 10g...

[atporfi]

C noté je vais voir avec le monotoring !