Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Dans Metalink, ils parlent d'un bug similaire en 9i... faute d'explication, je pense en effet que c'est un bug.
Le bug en question dit que la suppression des objets ne réduit pas la taille de obj#, un contournement est de supprimer le schéma plutôt que ses objets.
C'est très ressemblant à ton problème.
que donne :
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
Le bug est corrigé en 9.2.0.8 et c'est bien ton problème apparemment
Hypothèse/question : n'as-tu pas eu, à un moment, de très nombreux packages qui auraient été supprimés, voire d'autres utilisateurs ?Envoyé par annemar
Cela pourrait expliquer que la table SOURCE$ s'est remplie considérablement et occupe toujours les segments qu'elle a alloués.
Le résultat de la requête de philcero donne un total de 85 Mo de code PLSQL, très loin des 4 Go de la table source$.
même si c'est possible, ça n'a aucun intérêt puisque ça ne fera pas descendre la HWM et tu ne pourras pas réduire la taille du fichier.
Tu as 2 solutions : recréation de la base
migration 9.2.0.8
ou drop user... cascade plutôt que drop des objets.
Moi qui n'aimait pas faire des drop cascade, je vais me méfier à présent avec les versions 9i >= 9204. Je faisais plutôt des drop objets pour préserver grants, pw etc.
Un bon point pour orafrance.
PS : je recrute dans mon équipe, tu es intéressé ?
Je suis trop cherPS : je recrute dans mon équipe, tu es intéressé ?
Sinon, non, j'ai un excellent poste
Ca ressemble à mon cas : drop des objets quotidiennement pour un réimport du schéma venant de la prod (pour 13thfloor, cette manip est faite depuis mars 2006, tous les jours : ça fait pas mal de suppression et recréation de packages et autres !!).
Bien sûr, cela serait simple de dropper le schéma, mais on veut ici conserver tous les grants etc ...
Donc pour moi, deux choses
1) recréation de cette base copie
2) passage en 10.2.0.3 de ces quelques bases qui sont encore en 9i. Je suis en plein test de cet upgrade, c'est en checkant les différentes instances que je me suis aperçue de ce problème de taille (on a bp de place disque => cela ne remonte pas comme problème)
Pour information : on a eu une première vague d'upgrade sur une série de bases (pour une autre application). De la même façon, il y a copie quotidienne d'un schéma dans une base copie, après drop des objets, cela depuis octobre 2007 : comme elle est en 10.2.0.3, je n'ai pas du tout ce problème de taille de SOURCE$ !!
... Merci pour toutes ces remarques et merci aussi à ceux qui glissent d'office les requêtes dans leur commentaire : cela me fait gagner énormément de temps.
(Pour ta dernière requête orafrance : SELECT COUNT(*) FROM sys.source$ WHERE obj# NOT INT (select obj#FROM sys.obj$), c'est en cours ... je communiquerai le résultat plus tard)
réponse à orafrance : Bon, j'ai arrêté la requête : la session prenait bp de CPU sur un serveur assez sollicité.
Ca avait l'air de partir en scan full (cf Grid Control) ... sur cette table de 4 Go ... Je me dis que cela peut être optimisé mais je n'ai pas trop de temps pour cela
Tant pis sauf si hyper important pour toi.
si c'est long c'est probablement que tu as énormément d'objet qui sont orphelin dans source$ ce qui me conforte un peu plus dans l'idée que c'est bien le bug que j'ai mentionné
Je reste donc sur les 2 manips que j'ai à faire
1) recréation de cette base copie
2) passage en 10.2.0.3 de ces quelques bases qui sont encore en 9i
... manips que je ferai dans les 6 semaines qui viennent.
Merci pour vos interventions
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager