وصف اتصالات عميل SQL Server الظاهري

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

اضغط هنا لرابط المقالة باللغة الانجليزية273673
الموجز
توضح هذه المقالة بعض الأساسيات حول اتصالات عميل الخادم الظاهري لـ Microsoft SQL.
معلومات أخرى
هام هذا المقطع أو أسلوب أو المهمة على خطوات إخبارك عن كيفية تعديل التسجيل. ومع ذلك، قد تحدث مشكلات خطيرة في حالة تعديل السجل بطريقة غير صحيحة. لذلك، تأكد من اتبع الخطوات التالية بعناية. للحصول على الحماية المضافة عمل نسخة احتياطية من السجل قبل تعديله. ثم يمكنك استعادة السجل في حالة حدوث مشكلة. للحصول على مزيد من المعلومات حول كيفية عمل نسخة احتياطية من السجل واستعادته انقر فوق رقم المقالة التالي لعرضها في "قاعدة المعارف لـ Microsoft:
322756كيفية عمل نسخة احتياطية و استعادة التسجيل في Windows


السلوك عميل SQL Server الظاهري

يوفر ملقم الكتلة لـ Microsoft "(MSCS) نظامًا قوة وموثوق حيث يمكنك إنشاء تطبيقات ملقم SQL الصعبة. لا تحتاج إلى تعديل معظم تطبيقات الملقم لاستخدام MSCS. ومع ذلك، التطبيقات المستندة إلى المعاملة (على سبيل المثال، ملقمات قواعد البيانات ، مثل Microsoft SQL Server) عادةً تتطلب التعديل إضافية بحيث إذا فشل الخادم في دعم تجاوز الفشل يمنع فقدان تكامل المعاملات بشكل صحيح. يتم تطوير تطبيق عميل بالعمل مع MSCS مباشرة نسبياً. يجب عليك تصميم التطبيقات مع استرداد قاعدة البيانات "و" تدقيق الأخطاء في الاعتبار.

حتى بدون استخدام الكتل، SQL Server باسترداد الملقم تلقائياً كافة قواعد البيانات عند إعادة تشغيل الملقم. للتأكد من استرداد قاعدة بيانات في حالة تطبيق متناسقة المعاملات قاعدة بيانات الاستخدام بحيث يحدث تجاوز الفشل في قاعدة البيانات بشكل صحيح وفي حالة متناسقة. أي معاملات غير مكتملة عند حدوث تجاوز الفشل يجب أن يكون إرجاع أثناء الاحتفاظ التأثيرات المعينة كافة المعاملات.

أثناء تجاوز الفشل ، تفقد الاتصال بملقم SQL Server تطبيقات العميل ثم يجب إعادة الاتصال متابعة المعالجة. إذا كان اتصال العميل إلى الملقم بدون الحالة ، (على سبيل المثال، التطبيقات التي تم تطويرها باستخدام ملقم معلومات إنترنت Microsoft [IIS] بدون الحالة) العميل يعيد الملقم ومتابعة المعالجة. إلا العميل والملقم وجود حالة شائعة (على سبيل المثال، رؤوس مؤشرات مفتوحة أو متغيرات جلسة العمل, المتغيرات العمومية Transact-SQL أو بيانات في tempdb) ، تجاوز الفشل غير شفافة إلى العميل. في هذه الحالات، يجب تصميم تطبيق عميل لإعلام المستخدم التي تم الاتصال إما فقدان, أو إعادة تعيين أو أن يكون لديك تطبيق تلقائياً إعادة تأسيس اتصال الخاص به إلى الملقم. يتم إرجاع أية معاملة لم يتم قبولها عند حدوث تجاوز فشل.

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

إذا فشل ملقم SQL Server عن طريق نظام الإدارة لا يتم إرسال حزم إعادة التعيين TCP. إذا تم إنهاء عملية SQL Server بواسطة نظام تشغيل (بواسطة Kill.exe) ، يتم إرسال حزم إعادة التعيين.

قد يؤثر هذا على تطبيق العميل إذا كان التطبيق لا تحدد معلمة مهلة استعلام أو مهلة استعلام من صفر (0).

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

لمعالجة هذه المشكلة من منظور تطبيق عميل تغيير مهلة الاستعلام إلى عدد محدد.

سلوك فشل قاعدة البيانات الظاهري

عند فشل خادم قاعدة بيانات ظاهري يتم إرجاع رسالة خطأ فشل ارتباط اتصال إلى عميل انتظار. قاعدة بيانات على العقدة التي فشلت الكتلة يتم إيقاف وإعادة تشغيله على عقدة نفس لكل معلمات إعداد في:

Start\Programs\Administrative Tools (Common)\Cluster Administrator\Group\Failover\Properties				
العتبة الافتراضية "تجاوز الفشل المجموعة" إعادة تشغيل 10 في فترة 6 ساعة قبل حدوث تجاوز فشل إلى عقدة المتبقية. ومع ذلك، تشغيل SQL Server العتبة التي يمكن التحقق من خلال خصائص SQL Server على مورد نظام المجموعة SQL Server و له حد افتراضي من ثلاث عمليات إعادة التشغيل على تلك SQL Server بالثواني 900 و بشكل افتراضي يؤثر في المجموعة. إذا حاول عميل الاتصال بالملقم أثناء استرداد قاعدة بيانات ، يتلقى انتظار رسالة الخطأ استرداد قاعدة بيانات العميل ثم يجب إعادة المحاولة بعد الإيقاف مؤقت قصيرة.

اعتبارات SQL Server 6.5 و SQL Server 7.0

SQL Server 6.5 و SQL Server 7.0 تعمل تماماً كما هو موضح في القسم "سلوك فشل قاعدة الظاهري" السابقة.

عند تشغيل SQL Server 7.0 كملقم ظاهري يعتمد عنوان IP واحد فقط SQL Server 7.0 لكن قد استماع على منافذ إضافية كما تم تكوينه بواسطة العميل. هذا هو الموصوفة في موضوع "متعددة إصغاء على TCP/IP منافذ" في مقالة "قاعدة معارف Microsoft" التالية:
254321INF: Do's ملقم SQL متفاوت المسافات, Don'ts والتحذيرات أساسي

اعتبارات Microsoft SQL Server 2000

يتضمن SQL Server 2000 بعض الاختلافات في سلوك من إصدارات SQL Server 6.5 و SQL Server 7.0.

استخدام المنفذ SQL Server 2000

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

إذا تم تكوين ملقم للإصغاء على منفذ ديناميكي فشل الخادم في للإصغاء على المنفذ الديناميكي على بدء تشغيل الملقم اختيار منفذ آخر.

في حالة تكوين منفذ ثابت أثناء الإعداد أو بعد الإعداد باستخدام الأداة المساعدة شبكة ملقم فشل الإصغاء على TCP/IP هذا المنفذ في حالة استخدام.

يكتشف العملاء رقم المنفذ للاتصال به في الحالة الخاصة مثيل مسمى أو ذات رقم منفذ غير افتراضي.

تتم كتابة معلومات الاتصال إلى ذاكرة التخزين المؤقت "LastConnect" في مفتاح التسجيل هذا:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\supersocketnetlib\lastConnect
ستجد إدخالات لكل ملقم "و" الأسلوب المستخدم في الاتصال بها في التسجيل.

يحاول العميل بإعادة استخدام معلومات الاتصال على كل اتصال إلا إذا كان فشل ثم re-negotiates المعلومات الجديدة. قد يحدث هذا إذا تم تغيير رقم المنفذ بسبب شخص تغيير أو إذا كان منفذ ديناميكي تم re-assigned بسبب إلى منفذ قيد الاستخدام.

الاتصالات المقطوعة

هناك ثلاث طرق يمكن أن يتم قطع اتصال:
  1. فشل الخادم في إنهاء العملية بواسطة killed (نظام إنهاء معرّف العملية "الخادم" [spid]) أو خرق في وصول (AV) أو شيء آخر يتسبب نظام التشغيل أو إلى فشل خدمة المطلوبة.
  2. فقدان الطاقة أو فشل في الأجهزة الجهاز.
  3. إيقاف تشغيل الملقم.
كل من هذه الاتصالات المقطوعة يواجه سلوك آخر رؤيتها على جهاز الكمبيوتر العميل.
  1. في حالة فشل ملقم العميل يتلقى رسالة خطأ قطع اتصال فوراً. يمكنك محاكاة هذا السلوك بواسطة الاتصال بـ OSQL تشغيل استعلام طويلة واستخدامها ثم إنهاء لإنهاء عملية SQL Server. إنهاء العميل مع ظهور رسالة خطأ ODBC.
  2. فشل جهاز أكثر تعقيداً. يمكن تغيير السلوك قليلاً استناداً إلى كيفية الكشف عن فقدان الاتصال.

    في حالة في منتصف قراءة معلومات العميل فقدان الاتصال يمكن الكشف عن مباشرة بسبب توقف البيانات.

    العميل قيد انتظار فقط للحصول على نتائج السلوك حالة مختلف قليلاً. يعتمد السلوك تكوين جهاز الكمبيوتر العميل "الاحتفاظ النشاط".

    في Microsoft Windows 2000 احتفاظ Alive يتم تعيين بواسطة رمز العميل لكل اتصال على حده. بشكل افتراضي، "الاحتفاظ النشاط" يتم تعيين إلى 30 ثانية. هذا يعني إذا مأخذ التوصيل dies فإنه يتم الكشف عن 30 ثانية و العميل يتلقى رسالة إعلام بالخطأ. في Microsoft Windows NT 4.0 الاحتفاظ النشاط لا يمكن تعيين لكل اتصال على حده. الاحتفاظ Alive يجب تعيين الكمبيوتر بأكمله وبالتالي التأثير على كافة التطبيقات على الملقم.

    مفاتيح التسجيل التي يتم يشار إليها:
    KeepAliveTime\REG_DWORD HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 30000

    KeepAliveInterval\REG_DWORD HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters 1000
  3. عند بدء وإيقاف تشغيل ملقم, ينتظر الملقم الوقت لعملاء لإنهاء. ومع ذلك، إذا كان لا يزال قيد العميل الملقم kills مؤشرات الترابط داخل الملقم. killing مؤشرات الترابط قد تؤدي أيضًا إلى حدوث رسائل خطأ مختلفة على العميل. يمكن أن تتضمن رسائل خطأ اتصال مقطوع خطأ; ومع ذلك، معظم الوقت تشاهد رسالة الخطأ هذه:
    "حدث خطأ غير معروف, قد يكون تم إنهاء الاتصال بواسطة الملقم".
    يتم تعيين رمز الخطأ الأصلي ODBC إلى صفر (0) في هذه الحالة ولكن يتم إرجاع كرسالة خطأ إلى العميل.
مراجع
للحصول على مزيد من المعلومات حول سلوك عميل SQL Server الظاهري في SQL Server 2005 قم بزيارة موقع شبكة مطوري Microsoft (MSDN) التالي على الويب:

تحذير: تمت ترجمة هذه المقالة تلقائيًا

خصائص

رقم الموضوع: 273673 - آخر مراجعة: 12/04/2007 03:44:52 - المراجعة: 7.3

Microsoft SQL Server 6.5 Enterprise Edition, Microsoft SQL Server 7.0 Enterprise Edition, Microsoft SQL Server 2000 Enterprise Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Standard Edition

  • kbmt kbhowto kbsql2005cluster kbclientserver kbinfo KB273673 KbMtar
تعليقات