it-swarm.asia

الآثار المترتبة على استخدام OPENQUERY في طريقة العرض

يرجى الاطلاع على السؤال في stackoverflow:

أستخدم برنامج تشغيل EasySoft ODBC لربط مثيل SQL Server 2008 R2 Express بـ Interbase وأواجه بعض الصعوبات في الحصول على بيانات التعريف من الخادم البعيد. من البحث على الإنترنت ، تشير جميع الاقتراحات الرئيسية باستخدام OPENQUERY بدلاً من بنية الخادم المرتبطة المكونة من أربعة أجزاء.

على سبيل المثال نهجي الحالي (إشكالي) هو ...

CREATE VIEW [LIVE].[vwPRDETS]
AS

SELECT *
FROM [LBLIVE]...[PRDETS] WITH (NOLOCK)

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

Msg 7353 ، المستوى 16 ، الحالة 1 ، السطر 1 قام موفر قاعدة البيانات OLE "MSDASQL" للملقم المرتبط "LBLIVE" بتوفير بيانات تعريف غير متناسقة. تم توفير عمود إضافي أثناء التنفيذ لم يتم العثور عليه في وقت الترجمة.

أيضًا ، بعض المشاهدات التي لا يمكنني إنشاؤها حتى لأنني أحصل على ما يلي ...

Msg 7315 ، المستوى 16 ، الحالة 1 ، السطر 1 يحتوي موفر قاعدة بيانات OLE "MSDASQL" للخادم المرتبط "LBLIVE" على جداول متعددة تطابق الاسم "" SYSDBA "." AUDIT_LBABKP "".

على الرغم من وجود جدول واحد فقط.

يبدو النهج البديل من البحث في الشبكة أشبه ...

SELECT *
FROM OPENQUERY(<linked sevrer>, 'SELECT <column list> FROM MyTable')

لذا ، سؤالي هو ، إذا كنت أستخدم OPENQUERY في تعريف العرض الخاص بي ، فسيكون SQL Server قادرًا على تحسين SQL الناتج الذي يتم إرساله إلى Interbase؟ أم أنه لا يوجد فرق كبير بين النهجين؟

إنه صليب على الموضوع وسيحب بوف DBA.

15
Rich Andrews

ملخص

دع الخادم المرتبط يقوم بأكبر قدر ممكن.
من المستحيل أن يقوم SQL Server بتحسين الاستعلام على خادم مرتبط ، حتى خادم SQL آخر

طويل

العامل الأساسي هو حيث يعمل الاستعلام.

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

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

على سبيل المثال ، الحالة الثانية هنا يجب أن تكون أكثر كفاءة.

SELECT *
FROM OPENQUERY(<linked server>, 
            'SELECT <column list> FROM MyTable') T1
     JOIN
     SomeLocalTable T2 ON ...
WHERE T1.foo = 'bar'

SELECT *
FROM OPENQUERY(<linked server>, 
           'SELECT <column list> FROM MyTable WHERE foo = ''bar''')
     JOIN
     SomeLocalTable T2 ON ...

هناك قيود على OPENQUERY هي أنه لا يمكنك تنفيذ المعايير: لذا فأنت تحتاج إلى SQL ديناميكي لإضافة عبارات WHERE إلخ.

يمكن أن يتأثر أداء الخوادم المرتبطة بـ [sp_serveroption) . الإعداد collation compatible يقول كل شيء

إذا تم تعيين هذا الخيار على "صحيح" ، يفترض SQL Server أن كافة الأحرف الموجودة في الخادم المرتبط متوافقة مع الخادم المحلي ، فيما يتعلق بمجموعة الأحرف وتسلسل الترتيب (أو ترتيب الفرز). يمكّن هذا SQL Server من إرسال مقارنات على أعمدة الأحرف إلى الموفر. إذا لم يتم تعيين هذا الخيار ، يقوم SQL Server دائمًا بتقييم المقارنات على أعمدة الأحرف محليًا.

بمعنى ، حاول عدم السماح لـ SQL Server بمعالجة البيانات محليًا.

ملاحظة: في المثال الثاني foo = 'bar' أعلاه ، يتم إرسال عامل التصفية إلى الخادم المرتبط لأنه مجرد سلسلة ثابتة إلى SQL Server. قد يتم أو لا يتم إرسال عبارة WHERE الحقيقية في المثال الأول عن بُعد.

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

20
gbn