أداء الخادم المرتبط وخياراته

Question

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

وقد أدى ذلك إلى وجود خادم SQL ثانٍ مرتبط بالخادم الأول وإنشاء مكتبة من الإجراءات المخزنة التي تستعلم عن البيانات من كلا الجانبين باستخدام الخادم المرتبط.تستغرق بعض هذه الاستعلامات وقتًا أطول مما أريد.

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

أيضًا ما هي خيارات الخادم المرتبط المتوفرة لدي حاليًا:

• ترتيب متوافق صحيح
• الوصول إلى البيانات صحيح
• RPC صحيح
• RPC خارج صحيح
• استخدم خطأ الترتيب عن بعد
• اسم الترتيب (فارغ)
• مهلة الاتصال 0
• مهلة الاستعلام 0

يحرر:

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

Answer 1

أنصح باستخدام الاستعلامات المفتوحة الديناميكية في حلقة المؤشر بدلاً من الروابط المرتبطة.هذه هي الطريقة الوحيدة التي تمكنت من خلالها من تكرار أداء الانضمام المرتبط بـ MS Access (على الأقل بالنسبة للجداول البعيدة الفردية)

تعتبر الصلات المرتبطة العادية في ms sql غير فعالة للغاية عن طريق سحب كل شيء خصيصًا في الجداول الضخمة.

- أود أن أعرف ما هو الشيء السيئ للغاية بشأن الاستعلامات المفتوحة داخل حلقات المؤشر؟إذا تم ذلك بشكل صحيح، فلا توجد مشكلات في القفل.

Answer 2

تجنب الانضمام إلى جداول الخادم المرتبطة.

يمكن استخدام تسمية مكونة من أربعة أجزاء للانضمام الخاص بك ولكنها أكثر تكلفة.يمكن أن يحتوي انضمامك على معايير يمكن استخدامها للحد من مجموعة البيانات من الخادم المرتبط واستخدام الأعمدة المفهرسة.

مثال:

SELECT loc.field1, lnk.field1
FROM MyTable loc
INNER JOIN RemoteServer.Database.Schema.SomeTable lnk
  ON loc.id = lnk.id
  AND lnk.RecordDate = GETDATE()
WHERE loc.SalesDate = GETDATE()

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

الطريقة الموصى بها هي استخدام OPENQUERY.

من خلال تجنب الانضمام باستخدام OPENQUERY، يرسل الخادم المحلي فقط الاستعلام ليتم تنفيذه عن بعد بدلاً من إرسال مجموعة من المعرفات للانضمام.

استخدم الرابط لاسترداد مجموعة من البيانات وإجراء العمليات الحسابية محليًا.إما أن تستخدم جدولاً مؤقتًا (للاستعلامات المخصصة) أو تدرج الصف في جدول دائم في مهمة ليلية.

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

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

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

ستتجنب أيضًا إلغاء استفساراتك بسبب حركة البيانات على الخادم المرتبط.كن على دراية دائمًا بتعيين مستوى العزل المناسب لاستفساراتك وتلميحات الجدول مثل NOLOCK.

و فضلا!لا تضع أبدًا OPENQUERY (أو أي خادم مرتبط) داخل حلقة!

Answer 3

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

تتضمن البدائل نسخ مجموعة فرعية من البيانات إلى جدول مؤقت مع بذل أكبر قدر من العمل لتقليل النتائج وأي معالجة مسبقة يمكن للخادم المرتبط إجراؤها، ثم القيام بالربط على الجانب "المحلي".

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

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

Answer 4

ألم ملكي

لقد اعتدنا أن يكون لدينا العديد من الخوادم المرتبطة في متجرنا، وقد تبين أن الأمر كذلك مثل بيتا.

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

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

وفي النهاية، تخلصنا من الخوادم المرتبطة تمامًا ونقلنا مزامنة البيانات إلى خدمات الويب.

Answer 5

لا تميل الاستعلامات التي تتضمن روابط شبه عبر خادم مرتبط إلى أن تكون فعالة للغاية.قد يكون من الأفضل لك استخدام استفسار مفتوح لملء البيانات في جدول مؤقت محلي ثم العمل عليها من هناك.

Answer 6

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

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

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

لا أعرف ما إذا كانت هناك حقًا طريقة فعالة لإجراء هذه الاستعلامات باستخدام خادم بعيد لأنه يبدو أن SQL Server لا يمكنه الاستفادة من تحسيناته العادية عند مواجهة خادم مرتبط.قد يبدو الأمر وكأنك تقوم بنقل الجدول بأكمله لأن هذا ما يحدث في الواقع.

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

لا أعرف أي مقالات جيدة لتوجيهك نحوها.أثناء كتابتي لتطبيقات SQL Server أكثر تعقيدًا، بدأت أعتقد أنني بحاجة إلى فهم أفضل لكيفية عمل SQL Server في ظلها.ولتحقيق هذه الغاية، اشترينا سلسلة MS Press Inside Microsoft SQL Server 2005 التي حرّرها كالين ديلاني هنا في العمل.المجلد 1:من المؤكد أن محرك التخزين هو المكان المناسب للبدء، لكنني لم أتعمق فيه كثيرًا.نظرًا لأن مشاريعي القليلة الأخيرة لم تتضمن SQL Server، فقد أصبحت دراستي لها متساهلة.

Answer 7

هل هناك إمكانية لإعداد قاعدة بيانات منفصلة على الخادم بدلاً من استخدام خادم مرتبط؟

Answer 8

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

ما حل مشكلتي ..

لقد قمت بترقية SQL Server 2000 من SP2 إلى SP4 وإذا كان لديك بالفعل SP4 على SQL Server 2000، فقم بتشغيل Instcat.sql.وفقًا لخبرتي، يمكنني أن أؤكد لك أن هذا سيعمل بالتأكيد، إذا كنت مرهقًا من جميع الحلول الأخرى.

شكرا ، mithalesh mithalesh.gupta@gmail.com

Answer 9

يمكن استخدام SQL الديناميكي والوظيفة للتغلب على سؤال الاسم المشفر.على سبيل المثال ، أحاول تطبيقًا حيث تقوم وظيفة UFN_LINKEDDATABASE (PURPOSE NVARCHAR (255)) مع إدخال "CPI.CPI" (الغرض من مؤشر أسعار المستهلك ، الافتراضي للأغراض الفرعية) [server-name.domain.lcl ، 2000]. [CPI] 'في بيئة الإنتاج (حيث نستخدم رقم المنفذ البديل لخادم SQL ، لا أعرف السبب ، بما في ذلك في اسم الخادم المرتبط).ثم يتم تجميع أمر SQL في @template varchar (max) مع expression @{cpi.cpi} الذي يمثل الخادم المرتبط وقاعدة البيانات ، ثم workstring = استبدال (template ، n'{cpi.cpi} ،. ..).إن الطريقة التي تحصل بها الوظيفة فعليًا على اسم قاعدة البيانات منفصلة عن الإجراءات - جدول البحث جيد.

المشكلات - للقيام بـ OPENQUERY()، والذي ربما لا يزال أفضل على الأقل ما لم يتم تعيين خيار الخادم المرتبط "متوافق مع الترتيب" على "صحيح" بحيث يمكن تنفيذ المزيد من المهمة على الخادم المرتبط - وهو أمر مهم حتى على شبكة سريعة، والشبكة الداخلية لغرفة الخادم لدينا سريعة بشكل محترم - للقيام بـ OPENQUERY() ربما أحتاج إلى التعامل مع "cpi.cpi.server" و"cpi.cpi.database" و"cpi.cpi.server.database" بشكل منفصل.وقد ينتهي بي الأمر بكتابة تطبيق واحد فقط باستخدام هذا التصميم، وفي هذه الحالة يكون تصميمه مبالغًا فيه.ومع ذلك، هذا يعني أن الوظيفة نفسها لا يجب أن تكون أي نوع من العمل الخيالي.

قد يكون حل المشكلة بأجهزة الشبكة السريعة هو الحل الأرخص على أي حال.