ORA-03113 lors de l'exécution d'une requête sql
J'ai un 400 de la ligne de requête sql qui est en train de lancer une exception à l'intérieur de 30 secondes
ORA-03113: fin de fichier sur le canal de communication
Ci-dessous sont des choses à noter:
- J'ai mis le timeout de 10 minutes
- Il y a une dernière condition lors de la suppression résout cette erreur.
- Cette erreur est venu que récemment, lorsque j'ai analysé les indices.
La troublante condition est comme ceci:
AND UPPER (someMultiJoin.someColumn) LIKE UPPER ('%90936%')Donc mon hypothèse est que la requête est prise en résilié à partir du côté serveur apparemment parce que sa identifié comme un mangeur de ressources.
Est mon hypothèse appropriée ? Comment dois-je procéder pour résoudre ce problème ?
EDIT: j'ai essayé de me l'expliquer le plan de la mauvaise requête, mais l'expliquer le plan de requête me donne aussi un ORA-03113 erreur. Je comprends que ma requête n'est pas très performant, mais pourquoi devrait-il être une raison pour ORA-03113 erreur. Je suis en train de lancer la requête à partir de crapaud, et il n'y a pas d'alerte de journal ou de la trace générée, ma version db est
Oracle9i Enterprise Edition Version 9.2.0.7.0 - Production
S'il vous plaît, ajouter une condition qui provoque des ennuis à cause de texte.
Je ne pense pas que vous devriez avoir supprimé votre réponse. Il contenait utiles et des conseils pertinents. Vous avez juste besoin d'enlever cette grande partie de la citation de la note MOS.
Pouvez-vous svp reposter une partie de votre réponse, il a été utile.
OriginalL'auteur Ravi Gupta | 2010-07-28
Vous devez vous connecter pour publier un commentaire.
Une cause possible de cette erreur est un fil de collision sur le côté serveur. Vérifier si le serveur Oracle a généré tous les fichiers de trace, ou connecté d'erreurs dans son journal des alertes.
Vous dire que la suppression de la condition de la requête à l'origine du problème pour s'en aller. Combien de temps la requête pour exécuter sans cette condition? Avez-vous vérifié les plans d'exécution pour les deux versions de la requête pour voir si l'ajout de cette condition est à l'origine de certains inefficace plan choisir?
+1 - vérifiez d'Abord l'état de trace et d'alerte des journaux.
Fait que vous obtenez de l'ORA-03113 erreur de faire un plan d'expliquer est une preuve supplémentaire d'un crash dans l'Oracle du CBO. Vous avez besoin d'élever ce sera le support d'Oracle (si vous n'avez pas le support, essayez de mettre à niveau vers une version ultérieure, comme le bug, vous sont frapper pourrait être fixé). Peut-être il ya un buggy optimisation pour UPPER() sur une constante?
OriginalL'auteur Dave Costa
J'ai eu la même connexion abandon des problèmes avec certaines variations sur une requête. Dans mon cas, les connexions chuté lors de l'utilisation de rownum dans certaines circonstances. Il s'est avéré être un bug qui a une solution de contournement en ajustant un certain Oracle Base de données de configuration. Nous sommes allés avec une solution de contournement jusqu'à ce qu'un patch pourrait être installé. Je souhaite que je pourrais souviens plus des détails, ou de trouver un ancien e-mail sur ce sujet, mais je ne connais pas les détails permettrait de résoudre votre problème. Je poste juste pour dire que vous avez probablement rencontré un bug et si vous avez accès à Oracle du site de support (support.oracle.com) vous trouverez probablement que d'autres l'ont rapporté.
Edit:
J'ai eu un coup d'oeil rapide à la prise en charge Oracle. Il y a plus de 1000 bugs liés à des ORA-03113 mais j'en ai trouvé un qui peut s'appliquer:
Bug 5015257: REQUÊTE ÉCHOUE AVEC l'erreur ORA-3113 ET COREDUMP QUAND QUERY_REWRITE_ENABLED='TRUE'
Pour résumer:
(non identifié) provoque ORA-03113
même
$ORACLE_HOME/dbs
QUERY_REWRITE_ENABLED false: alter
de l'ensemble du système query_rewrite_enabled =
FALSE;
Une autre possibilité:
Bug 3659827: ORA-3113 DEPUIS LONGTEMPS l'EXÉCUTION de la REQUÊTE
Sur les clients du système qu'ils reçoivent de base.les fichiers journaux mais ne reçoivent pas d'erreurs
dans l'alerte.journal. Sur le système de test que j'ai utilisé j'ai reçu ORA-7445 erreurs.
OriginalL'auteur jlpp
Vous pouvez supprimer la partie "SUPÉRIEURE" sur les deux parties si vous utilisez le comme avec des chiffres (qui ne sont pas sensibles à la casse), ce qui peut réduire la durée de la requête pour vérifier la comme phrase
Est égal à:
Numéros ne sont pas affectés par le HAUT (et % est indépendante de caractère boîtier).
OriginalL'auteur Dubas
De l'information jusqu'à présent, il ressemble à un back-end crash, comme Dave Costa suggéré il y a quelques temps. Avez-vous été en mesure de vérifier les logs du serveur?
Pouvez-vous obtenir le plan de
set autotrace traceonly explain? T-il se passer à partir de SQL*Plus localement, ou seulement avec une connexion à distance? Certainement sonne comme un ORA-600 sur le back-end pourrait être le coupable, surtout si c'est au moment de l'analyse. L'exécution réussie de plus de la faute de l'un semble exclure un problème de réseau. Je le soupçonne de ne pas assez rapidement, mais le client est de prendre jusqu'à 30 secondes pour donner jusqu'à la mort de connexion, ou le serveur est de prendre autant de temps pour écrire de la trace et de fichiers de base.Qui probablement vous laisse la possibilité de patcher (si vous pouvez trouver une solution pertinente pour les ORA-600 sur Metalink) ou la mise à niveau de la DB; ou la réécriture de la requête pour l'éviter. Vous pouvez obtenir quelques idées pour le faire à partir de Metalink si c'est un bug connu. Si vous avez de la chance, cela peut être aussi simple que d'un indice, si la condition est d'avoir un impact inattendu sur le plan. Est
someMultiJoin.someColumnpartie d'un indice qui est utilisé dans le succès de la version? Il est possible que laUPPERest source de confusion et vous pourrait l'inciter à revenir sur le succès de plan par allusion à l'index de toute façon, mais évidemment c'est assez spéculatives.OriginalL'auteur Alex Poole
Cela signifie que vous avez été déconnecté. Ce ne sera probablement pas en raison d'être un mangeur de ressources.
J'ai vu où la connexion à la DB est en cours d'exécution à travers un NAT et parce qu'il n'y a pas de trafic, il ferme le tunnel et donc supprime la connexion. En général, si vous utilisez le regroupement de connexion, vous n'obtiendrez pas ce.
OriginalL'auteur Daniel
@Daniel dit, la connexion réseau au serveur, est rompu. Vous pouvez prendre un coup d'oeil à Fin-de-fichier sur le canal de communication pour voir si elle offre des suggestions utiles.
De partager et de profiter.
OriginalL'auteur Bob Jarvis
C'est souvent un bug dans l'Optimiseur Basé sur les Coûts avec des requêtes complexes.
Ce que vous pouvez faire est de modifier le plan d'exécution. E. g. utilisation AVEC de tirer subquerys. Ou utiliser le SELECT /*+ RÈGLE */astuce pour empêcher l'Oracle de l'aide de l'OAC. Aussi à la baisse les statistiques de l'aide, car Oracle utilise ensuite un autre plan d'exécution.
Si vous pouvez mettre à jour la base de données, effectuez une installation de test de 9.2.0.8 et voir si l'erreur est là.
Il est parfois utile de faire un dump du schéma, de tout laisser tomber dans et importer le dump de nouveau.
OriginalL'auteur andrem