يتعطل التطبيق عند التحدث إلى Oracle ما لم يحتوي المسار القابل للتنفيذ على مسافات

Question

لدينا مشكلة في ملفات x مع تطبيق .NET الخاص بنا.أو بالأحرى، تطبيق Win32 و.NET المختلط.

عندما يحاول التواصل مع Oracle، فإنه يموت.يختفي.يذهب إلى الفراغ الأسود الكبير في السماء.لا توجد رسالة سجل الأحداث، لا استثناء، لا شيء.

إذا طلبنا ببساطة من التطبيق التحدث إلى MS SQL Server بدلاً من ذلك، والذي له تأثير استبدال استخدام OracleConnection والفئات ذات الصلة باستخدام SqlConnection والفئات ذات الصلة، فإنه يعمل كما هو متوقع.

اليوم حققنا اختراقا.

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

في الأساس، كان قابلاً للتكرار بنسبة 100% أن التطبيق يعمل إذا تم تشغيله من الدليل على سطح المكتب، ويفشل إذا تم تشغيله من الدليل في الجذر.

اكتشفنا اليوم أن الاختلاف المهم هو ما إذا كانت هناك مسافة في اسم الدليل أم لا.

لذلك، ستعمل هذه الدلائل:

C:\Program Files\AppDir\Executable.exe
C:\Temp Lemp\AppDir\Executable.exe
C:\Documents and Settings\someuser\Desktop\AppDir\Executable.exe

في حين أن هذه لن:

C:\CompanyName\AppDir\Executable.exe
C:\Programfiler\AppDir\Executable.exe      <-- Program Files in norwegian
C:\Temp\AppDir\Executable.exe

آمل أن يكون شخص ما قد قرأ هذا قد رأى سلوكًا مشابهًا ولديه "آها، أنت بحاجة إلى التلاعب في تكوين برنامج تشغيل Oracle glitz" أو ما شابه.

أي واحد؟

---

المتابعة رقم 1: حسنًا، لقد قمت بمعالجة إخراج procmon الآن، كلا الملفين منذ أن قمت بالضغط على الزر الذي يحاول فتح النافذة التي تؤدي إلى فشل التتالي، وقد لاحظت أنهم يتابعون في الغالب، هناك بعض الاختلافات الصغيرة بالقرب من الجزء العلوي من كلا الملفين، وأنهم يتتبعون طريقًا طويلًا.

ومع ذلك، عندما يفشل تشغيل واحد، يستمر الآخر، وتكون الأسطر القليلة التالية من إخراج السجل هي التالية:

ReadFile C:\oracle\product\10.2.0\db_1\BIN\orageneric10.dll    SUCCESS    Offset: 274 432, Length: 32 768, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O
ReadFile C:\oracle\product\10.2.0\db_1\BIN\orageneric10.dll    SUCCESS    Offset: 233 472, Length: 32 768, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O

بعد ذلك، يستمر تشغيل العمل في التنفيذ، ويلمس الآخر ملفات mscorwks.dll عدة مرات قبل إغلاق المواضيع وإغلاق التطبيق.وبالتالي، فإن التشغيل الفاشل لا يمس الملفات المذكورة أعلاه.

---

المتابعة رقم 2: اعتقدت أنني سأحاول ترقية برامج تشغيل عميل Oracle، ولكن يبدو أن 10.2.0.1 هو الإصدار الأعلى المتاح لخادم Windows 2003 وعملاء XP.

---

المتابعة رقم 3: حسنًا، لقد انتهينا من حل الصندوق الأسود.في الأساس وجدنا أن المشكلة تتعلق في مكان ما بـ XPO وأوراكل.يحتوي XPO على جدول نظام يديره، يسمى XPObjectType، مع ثلاثة أعمدة:معرف الهوية واسم النوع واسم التجميع.نظرًا لكيفية تكوين Oracle في قواعد البيانات التي نتحدث إليها، كانت أسماء الأعمدة هي OID وTYPENAME وASSEMBLYNAME.لن يكون هذا مشكلة في العادة، باستثناء أن XPO يتصل بمعلومات المخطط مباشرة ويتحقق مما إذا كان الجدول موجودًا بأسماء الأعمدة الصحيحة، ولا يتعامل XPO مع اختلافات الحالة لذا يرى جدول XPObjectType بثلاثة أعمدة غير معروفة ولا شيء من تلك التي تتوقعها.

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

ما زلت لا أملك أي فكرة عن المكان الذي تأتي فيه المساحة الموجودة في اسم المجلد بالضبط، ولكن هذه المشكلة لها مستويان:

1. إيقاف التطبيق من التعطل لدى عملائنا، حل قصير المدى
2. إصلاح الخلل، حل طويل الأمد

تم الآن حل المستوى 1، وسيتم إعادة المستوى 2 إلى قائمة الانتظار في الوقت الحالي ومنحه الأولوية.نحن نواجه بعض التغييرات الأكبر في طبقة البيانات لدينا على أي حال، لذا قد لا تكون هذه مشكلة نحتاج إلى حلها، على الأقل إذا تحقق جميع عملاء Oracle لدينا من أن إصلاح الجدول تخلص بالفعل من المشكلة.

سأقبل الإجابة بواسطة ديف ماركل نظرًا لأنه على الرغم من أن مراقبة العمليات (الأخ الأكبر لـ File Monitor) لم تحدد المشكلة فعليًا، إلا أنني تمكنت من استخدامها لتحديد ذلك بعد نقطة التوقف في رمز المستخدم حيث قام XPO بإنشاء استعلام لهذا الجدول، لا يمكنني/ لقد حدث ذلك حتى تم تسجيل جميع الإدخالات الخاصة بإغلاق التطبيق، مما دفعني إلى الاعتقاد بأن هذا الجدول هو السبب، أو على الأقل أثر على المشكلة بطريقة ما.

إذا تمكنت من الوصول إلى السبب الحقيقي لذلك، فسوف أقوم بتحديث المنشور.

Answer 1

وهنا ما سأفعله.أولاً، تحقق ثلاث مرات من أنك ترى السلوك الذي تعتقد أنك تراه.أستطيع أن أرى أن هذا يحدث في الاتجاه المعاكس من خلال عدم استخدام System.IO.Path لتسلسل المسارات، ولكن ليس كما تراه.تحقق ثلاث مرات من أن أذونات الملف منطقية.

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

Answer 2

ربما يجب أن ترى ما إذا كان بإمكانك إعادة إنتاج المشكلة باستخدام تطبيق بسيط يحاول فقط فتح اتصال بـ Oracle.وبهذه الطريقة يمكنك أن تكون متأكدًا بنسبة 100% من أن المشكلة تتعلق بـ OracleConnection أو برنامج تشغيل Oracle وليس بالرمز الخاص بك.

Answer 3

يجب أن تحصل على وسام المثابرة على ذلك!.

"Exactly what XPO does now I don't really know, but if I dropped this table, and recreated it with the right case, using double quotes around all the column names to get the case right, the problem doesn't crop up.

Exactly where the space in the folder name comes into this, I still have no idea"

المشكلات التي أواجهها فيما يتعلق بالمسافات في الأسماء هي أنها تفسر عمومًا البت قبل المسافة كاسم والباقي كمعلمة.إذا كان الأمر كذلك، فباستخدام الاسم العادي يمكنه رؤية "C emp" وهو دليل.باستخدام الاسم المتباعد، يحصل على "C:\Program Files"، ويبحث عن "C:\Program" وهذا غير موجود.قد يفشل، على سبيل المثال، في الكتابة فوق "C: emp" ولكنه قد ينجح في كتابة "C:\Program".أتساءل عما إذا كان سيظل يفشل مع "C:\Program Files" إذا كان هناك ملف أو دليل يسمى "C:\Program"

Answer 4

أشك في أن يكون عميل أوراكل صادقًا.واجهت مشكلة مماثلة في طبيعتها المحبطة.

إذا قمنا بالتثبيت على أجهزة 64 بت، فسيتوقف العميل عند البداية عند الاتصال بأوراكل على الرغم من أن التطبيق 32 بت.لقد تعقبنا الأمر في النهاية إلى حقيقة أن عميل أوراكل معين (Ora 10 واجه مشكلة مع الأقواس في المسار بحيث يعمل البرنامج الذي يعمل ضمن ملفات البرنامج ضمن ملفات البرنامج (x86) مما تسبب في التعطل.أدى تحديث الجهاز لاستخدام عميل 11G إلى حل المشكلة، ولكن كانت هناك أيضًا بعض التصحيحات المتاحة من metalink والتي لا تتوفر بشكل مباشر.الأمر الغريب في حالتك هو أنك لا تحصل على أي استثناء ولكن سلوك نقل التطبيق إلى مجلد جديد يعمل على إصلاح المشكلة بطريقة مماثلة لذلك قد تكون ذات صلة.

أورا-12154:الاتصال غير مفتوح.

روابط مفيدة http://blogs.msdn.com/debarchan/archive/2009/02/04/good-old-connectivity-issue.aspx

التفاصيل من Metalink أدناه.

خطأ Metalink 3807408 لا يمكن مصادقة المستخدم خارجيًا باستخدام علامة الاقتباس في اسم المستخدم

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

The hallmark of this problem is that the Net trace (level 16) shows the problem character/s replaced by a "?" in the trace.

Workaround For the authentication problem: change username, or do not use remote OS authentication for those users

بالنسبة لمشكلة البرنامج/الدليل:تغيير اسم البرنامج/الدليل