ORA-22813: opérande valeur dépasse les limites du système
Je vais avoir un problème avec un oracle objet que j'ai créé. L'objectif de la procédure stockée est de récupérer tous les fils contenues dans un avion ou de comparer la liste des fils avec un autre (passé de fils d'avion de configuration). Vous comprendrez que cela peut être assez gros... j'ai fait un premier coup avec un tableau d'objets. Je fais une instruction select et boucle à l'aide d'un curseur pour insérer des valeurs dans mes objets. Le problème vient de quand j'essaye ceci:
OPEN P_CURSOR FOR
SELECT * FROM TABLE(CAST(GET_WIRES(P_ACTUAL_HAR_LIST, P_END_IDENT_TYPES) AS TBL_TP_WIRE_LIST));- Je obtenir de l'ORA-22813: opérande valeur dépasse les limites du système. Donc, j'ai commencé à regarder sur internet et j'ai trouvé que je devrais avoir utilisé un PIPELINE de fonction, que je tryied. Mais, le PIPELINE de la fonction n'est pas autorisée dans un PL/SQL contexte, et donc qui ne répond pas à mon problème, car j'ai besoin de retravailler l'objet par la suite. Donc, je tryied une Table Temporaire Globale et j'ai maintenant des problèmes de performances. J'ai aussi tryied de contacter l'administrateur si il pourrait augmenter la PGA taille, dont il a fait (il est maintenant 150 mo), mais j'ai le même problème. C'est peut-être pas encore assez grand, mais je ne veux pas de lui à reincrease si ce n'est pas d'aller travailler... Juste pour que vous ayez une idée, j'ai 1 487 761 de celles-ci:
CREATE OR REPLACE
TYPE TP_WIRE_LIST_ENTRY AS OBJECT (
ATA_NUM VARCHAR2(8 BYTE),
EFFECTIVITIES VARCHAR2(4000 BYTE),
WIRE_ID VARCHAR2(50 BYTE),
DRAWING_NO VARCHAR2(25 BYTE),
END_IDENT_1 VARCHAR2(25 BYTE),
END_IDENT_2 VARCHAR2(25 BYTE),
PIN_1 VARCHAR2(25 BYTE),
PIN_2 VARCHAR2(25 BYTE),
TERM_1 VARCHAR2(25 BYTE),
TERM_2 VARCHAR2(25 BYTE),
DES_LENGTH NUMBER(6,2),
TECH_PUBS_REMARKS VARCHAR2(500 BYTE),
WIRE_CODE VARCHAR2(25 BYTE),
W_CODE VARCHAR2(3 BYTE),
AWG VARCHAR2(3 BYTE),
COLOR VARCHAR2(4 BYTE),
GA VARCHAR2(6 BYTE),
END_IDENT_DESC_1 VARCHAR2(50 BYTE),
END_IDENT_DESC_2 VARCHAR2(50 BYTE),
TECH_PUBS_REMARKS_1 VARCHAR2(500 BYTE),
TECH_PUBS_REMARKS_2 VARCHAR2(500 BYTE),
IDENT_TYPE_ID_1 VARCHAR2(10 BYTE),
IDENT_TYPE_ID_2 VARCHAR2(10 BYTE),
BUS_NAME_1 VARCHAR2(20 BYTE),
PROPERTY_COLLECTION_ID_1 NUMBER(10,0),
BUS_NAME_2 VARCHAR2(20 BYTE),
PROPERTY_COLLECTION_ID_2 NUMBER(10,0),
X_1 NUMBER(8,3),
Y_1 NUMBER(8,3),
Z_1 NUMBER(8,3),
UOM_1 VARCHAR2(10 BYTE),
X_2 NUMBER(8,3),
Y_2 NUMBER(8,3),
Z_2 NUMBER(8,3),
UOM_2 VARCHAR2(10 BYTE),
COORD_CODE_1 VARCHAR2(10 BYTE),
COORD_CODE_2 VARCHAR2(10 BYTE),
UOM_DESC_1 VARCHAR2(50 BYTE),
UOM_DESC_2 VARCHAR2(50 BYTE),
PART_NO VARCHAR2(25 BYTE),
PART_DESC VARCHAR2(50 BYTE),
WIRE_GAUGE VARCHAR2(4 BYTE),
SPEC_REFERENCE VARCHAR2(60 BYTE),
MPS_NUM VARCHAR2(25 BYTE),
PPS_NUM VARCHAR2(25 BYTE),
INSERTION_TOOL VARCHAR2(25 BYTE),
EXTRACTION_TOOL VARCHAR2(25 BYTE)
);
/Nous travaillons avec Oracle9i Enterprise Edition Version 9.2.0.6.0
Cordialement,
- Il n'est pas clair pourquoi vous êtes à l'aide d'une collection à tous. Que les données de l'aide doit venir de quelque part, non? Alors, d'où vient-elle? Aussi, qu'entendez-vous par "Mais, le PIPELINE de la fonction n'est pas autorisée dans un PL/SQL contexte, et donc qui ne répond pas à mon problème"?
- Pourquoi avez-vous encore travailler avec 9i qui est de 8 ans de la date?
- Est-il possible de construire GET_WIRES comme un point de vue plutôt qu'une procédure ?
- APC - Données proviennent d'une instruction Select avec plusieurs jointures. J'ai besoin de l'objet en quelque sorte créer une nouvelle table. Le premier tableau de l'instruction select est un autre objet, qui est créé dynamiquement en fonction, par exemple, le programme de l'avion, le type de rapport, etc. Kevin - Non, parce que la table principale de la déclaration est dynamique (un autre objet) Tony - ce commentaire est non grevés d'affectations. La raison pour laquelle nous utilisons toujours 9i est parce que notre client n'a donc, c'est tout! Demandez-leur pourquoi ils ne peuvent pas payer pour une nouvelle version d'Oracle!
- Kevin - non, parce que pour récupérer les fils, nous devons avoir une liste d'identifiant qui est dynamique en fonction du contexte
- Juste quelques calculs: 150 MO avec 1 487 761 objets ne fait que
150*1024*1024 bytes / 1487761 objects = 105 bytes/object. Clairement un seulTP_WIRE_LIST_ENTRYobjet prend beaucoup plus que cela. - C'est un point interressant, mais j'ai eu le DBA changé la PGA à 1GO de sorte qu'il s'adapte à l'environnement de PROD (DEV était plus petit) je vous tiendrai au courant si ça marche!!!
Vous devez vous connecter pour publier un commentaire.
J'ai couru dans une situation similaire dans un environnement de stockage des données à un emploi passé.
Votre DBA non créé pga_aggregate_target ou _pga_max_size ou les deux? Gardez à l'esprit que lorsque l'administrateur de la base augmente pga_aggregate_target à 150 mo qui ne signifie pas que votre session serait en mesure de saisir tous que 150 MO. Oracle ne permettent à une session donnée de prendre une petite fraction de l'espace. L'augmentation de pga_aggregate_target de 150 MO 200 mo allons seulement donner votre session, un supplément de quelques mégas de mémoire pour jouer avec en mémoire les opérations de l'IIRC.
Si votre serveur de base de données a plus de mémoire disponible, vous devez avoir votre DBA augmenter à la fois la pga_aggregate_target et _pga_max_size, sinon vous aurez à regarder à l'aide d'un GTT ou la création d'un zéro de la table de vider vos données et ensuite travailler à partir de là.
Voulais juste ajouter cette friandise au cas où il permet à quelqu'un d'autre. Tout à coup nous avons commencé à avoir cette erreur dans notre PL/SQL lorsque l'administrateur de définir RESULT_CACHE_MODE AUTO comme un test pour un autre processus. Nous n'avons pas à savoir il l'a fait jusqu'à beaucoup plus tard. De toute façon, la valeur de retour de MANUEL a résolu ce problème.