لماذا تنتهي مهلة تقرير SSRS عندما يقوم الإجراء المخزن بناءً عليه بإرجاع النتائج في غضون ثوانٍ قليلة؟

Question

لدي تقرير يعرض البيانات التي تم إرجاعها من إجراء مخزن.باستخدام ملف التعريف يمكنني التقاط المكالمة إلى الإجراء المخزن من خدمات التقارير.

فشل التقرير في الإشارة إلى انتهاء مهلة التقرير ولكن يمكنني تنفيذ الإجراء المخزن من SSMS ويقوم بإرجاع البيانات مرة أخرى خلال خمس إلى ست ثوانٍ.

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

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

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

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

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

بمجرد انتهاء المهلة مرة أخرى، أفضل حل لدي حتى الآن هو إعادة إنشاء الإجراء المخزن.لا يبدو أن هذا هو الحل المثالي.

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

Answer 1

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

<اقتباس فقرة>   

إذا كنت تقوم بإضافة الكثير من الصفوف في   نهاية مجموعة من عمود (اعتقد   حول إضافة autonumbers، أو   الطوابع)، والرسم البياني لذلك   والعمود تصبح قديمة بسرعة.   يمكنك فرض تحديث فوري من   T-SQL بواسطة تنفيذ UPDATE   بيان إحصائيات.

Answer 2

لقد واجهت أيضًا هذه المشكلة حيث يستغرق SPROC ثوانٍ للتشغيل ولكن انتهت مهلة SSRS.

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

1. هو استنشاق المعلمة!عندما يتم تنفيذ الإجراء المخزن الخاص بك من SSRS، فإنه "سيتعرف" على المعلمات الخاصة بك لمعرفة كيفية استخدام SPROC لها.سيقوم SQL Server بعد ذلك بإعداد خطة تنفيذ بناءً على النتائج التي توصل إليها.يعد هذا أمرًا جيدًا في المرة الأولى التي تقوم فيها بتنفيذ SPROC، ولكنك لا تريد أن يقوم بذلك في كل مرة تقوم فيها بتشغيل التقرير.لذلك أعلن عن مجموعة جديدة من المتغيرات في الجزء العلوي من SPROC الخاص بي والتي تقوم ببساطة بتخزين المعلمات التي تم تمريرها في الاستعلام واستخدام هذه المعلمات الجديدة طوال الاستعلام.

مثال:

CREATE PROCEDURE [dbo].[usp_REPORT_ITD001]
@StartDate DATETIME,
@EndDate DATETIME,
@ReportTab INT
AS

-- Deter parameter sniffing
DECLARE @snf_StartDate DATETIME = @StartDate
DECLARE @snf_EndDate DATETIME = @EndDate
DECLARE @snf_ReportTab INT = @ReportTab

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

1. إذا كان SPROC الخاص بك يحتوي على الكثير من الجداول المؤقتة التي تم الإعلان عنها كمتغيرات (DECLARE @MyTable AS TABLE)، فهي مكثفة حقًا على الخادم (من حيث الذاكرة) عند إنشاء التقارير.باستخدام جداول التجزئة المؤقتة (SELECT MyCol1, MyCol2 INTO #MyTable) بدلاً من ذلك، سيقوم SQL Server بتخزين الجداول المؤقتة الخاصة بك في TempDB على الخادم بدلاً من ذاكرة النظام، مما يجعل إنشاء التقرير أقل كثافة.

Answer 3

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

Answer 4

وأساسا كل ما قمت به حتى الآن هو تحسين sproc أكثر قليلا، ويبدو أن حل المشكلة مؤقتا على الأقل.

وأنا لا تزال ترغب في معرفة ما هو الفرق بين استدعاء sproc من SSMS وSSRS.