ما الذي يمكن أن يسبب ORA-12519 المتقطع (TNS:لم يتم العثور على معالج مناسب) أخطاء

Question

نحن نقوم بتشغيل مجموعة اختبار Junit 4 الخاصة بنا مقابل Weblogic 9 أمام قاعدة بيانات Oracle 10 (باستخدام Hudson كخادم تكامل مستمر) وأحيانًا سنواجه تعطل ORA-12519 أثناء تفكيك البرنامج النصي.ومع ذلك، فإن الخطأ متقطع للغاية:

• يحدث هذا عادةً لنفس فئة الاختبار
• لا يحدث ذلك دائمًا لنفس حالات الاختبار (في بعض الأحيان ينجحون)
• لا يحدث ذلك لنفس العدد من حالات الاختبار (في أي مكان من 3 إلى 9)
• في بعض الأحيان لا يحدث ذلك على الإطلاق، كل شيء يمر

على الرغم من أنني لا أستطيع ضمان عدم حدوث ذلك محليًا (عند التشغيل على نفس قاعدة البيانات بالطبع)، فقد قمت بتشغيل نفس مجموعة الفصل عدة مرات دون أي مشاكل.

أيه أفكار؟

Answer 1

لا أعرف إذا كان هذا سيكون إجابة الجميع، ولكن بعد بعض البحث، إليك ما توصلنا إليه.

من الواضح أن سبب الخطأ هو حقيقة أن المستمع لم يقبل الاتصالات، ولكن لماذا نتلقى هذا الخطأ عندما تتمكن الاختبارات الأخرى من الاتصال بشكل جيد (لم نتمكن أيضًا من الاتصال بأي مشكلة من خلال sqlplus)؟لم يكن مفتاح المشكلة هو عدم قدرتنا على الاتصال، بل أنه كان كذلك متقطع

بعد إجراء بعض التحقيقات، وجدنا أن هناك بعض البيانات الثابتة التي تم إنشاؤها أثناء إعداد الفصل والتي من شأنها أن تبقي الاتصالات مفتوحة طوال عمر فصل الاختبار، مما يؤدي إلى إنشاء اتصالات جديدة أثناء استمرارها.الآن، على الرغم من أن جميع الموارد قد تم تحريرها بشكل صحيح عندما خرجت هذه الفئة عن النطاق (عبر كتلة أخيرًا{} بالطبع)، فقد كانت هناك بعض الحالات أثناء التشغيل عندما تبتلع هذه الفئة جميع الاتصالات المتاحة (حسنًا، سيئة تنبيه تدريبي - كان هذا رمز اختبار الوحدة الذي تم توصيله مباشرة بدلاً من استخدام التجمع، لذلك لا يمكن أن تحدث نفس المشكلة في الإنتاج).

كان الإصلاح هو عدم جعل هذا الفصل ثابتًا وتشغيله في إعداد الفصل، ولكن بدلاً من ذلك استخدمه في طريقتي الإعداد والتدمير لكل طريقة.

لذا، إذا تلقيت هذا الخطأ في تطبيقاتك الخاصة، فضع ملف تعريف على ذلك الولد الشرير وانظر ما إذا كان من المحتمل أن يكون لديك تسرب في الاتصال.امل ان يساعد.

Answer 2

الحل الآخر الذي وجدته لخطأ مشابه ولكن رسالة الخطأ نفسها هو زيادة عدد معالجات الخدمة التي تم العثور عليها.(حدث هذا الخطأ بسبب عدد كبير جدًا من الاتصالات في تجمعات Weblogic Portal Connection.)

• يجري SQL*Plus وتسجيل الدخول باسم SYSTEM.يجب أن تعرف كلمة المرور التي استخدمتها أثناء تثبيت Oracle DB XE.
• قم بتشغيل الأمر alter system set processes=150 scope=spfile; في SQL * زائد
• مهم جدا:أعد تشغيل قاعدة البيانات.

من هنا:

http://www.atpeaz.com/index.php/2010/fixing-the-ora-12519-tnsno-مناسب-service-handler-found-error/

Answer 3

لقد واجهت نفس المشكلة أيضًا، وبحثت عن الإجابات في العديد من الأماكن.حصلت على العديد من الإجابات المشابهة لتغيير عدد معالجات العملية/الخدمة.لكنني فكرت، ماذا لو نسيت إعادة ضبطه مرة أخرى؟

ثم حاولت استخدام Thread.sleep() طريقة بعد كل من بلدي connection.close();.

لا أعرف كيف، لكنه يعمل بالنسبة لي على الأقل.

إذا أراد أي شخص تجربتها ومعرفة كيفية عملها، فيرجى المضي قدمًا.وأود أيضًا أن أعرف ذلك لأنني مبتدئ في عالم البرمجة.

Answer 4

كان لدي مشكلة مماثلة.لقد حدث ذلك في كل مرة أقوم فيها بتشغيل حزمة من اختبارات قاعدة البيانات (Spring JDBC). SpringJUnit4ClassRunner, ، لذلك قمت بحل المشكلة @DirtiesContext تعليق توضيحي لكل اختبار من أجل تنظيف سياق التطبيق وتحرير كافة الموارد وبالتالي يمكن تشغيل كل اختبار مع تهيئة جديدة لسياق التطبيق.

Answer 5

لقد واجهت هذه المشكلة في اختبار الوحدة الذي فتح الكثير من الاتصالات بقاعدة البيانات عبر تجمع اتصال ثم "أوقف" تجمع الاتصال (ManagedDataSource في الواقع) لتحرير الاتصالات في نهاية كل اختبار.لقد نفدت الاتصالات دائمًا في مرحلة ما من مجموعة الاختبارات.

تمت إضافة Thread.sleep(500) في عملية التفكيك () لاختباراتي وهذا أدى إلى حل المشكلة.أعتقد أن ما كان يحدث هو أن توقف تجمع الاتصال () يطلق الاتصالات النشطة في مؤشر ترابط آخر بحيث إذا استمر مؤشر الترابط الرئيسي في إجراء الاختبارات، فقد تأخر مؤشر ترابط (سلاسل) التنظيف كثيرًا لدرجة نفاد الاتصالات من خادم Oracle.تسمح إضافة وضع السكون لخيوط الخلفية بتحرير الاتصالات المجمعة.

هذه مشكلة أقل بكثير في العالم الحقيقي لأن خوادم قاعدة البيانات أكبر بكثير ويوجد مزيج صحي من العمليات (وليس فقط عمليات الاتصال/قطع الاتصال التي لا نهاية لها لقاعدة البيانات).