مراقبة الأداء باستخدام Query Store
ينطبق على: 
قاعدة بيانات Azure ل PostgreSQL - خادم مرن
توفر ميزة Query Store في خادم Azure Database for PostgreSQL المرن طريقة لتتبع أداء الاستعلام بمرور الوقت. مخزن الاستعلام يعمل على تبسيط استكشاف أخطاء الأداء وإصلاحها من خلال مساعدتك في العثور بسرعة على أطول الاستعلامات قيد التشغيل، وأكثرها استهلاكًا للموارد. يسجل Query Store تلقائياً محفوظات الاستعلامات والخطط وإحصائيات وقت التشغيل، ويحتفظ بها لمراجعتك. هو يقسم البيانات إلى شرائح حسب الوقت بحيث يمكنك أن ترى أنماط الاستخدام الزمني. يتم تخزين البيانات لجميع المستخدمين وقواعد البيانات والاستعلامات في قاعدة بيانات تسمى azure_sys في قاعدة بيانات Azure لمثيل خادم PostgreSQL المرن.
هام
لا تقم بتعديل قاعدة بيانات azure_sys أو مخططاتها. سيؤدي القيام بذلك إلى منع Query Store وميزات الأداء ذات الصلة من العمل بشكل صحيح.
تمكين مخزن الاستعلام
يتوفر Query Store في جميع المناطق دون أي رسوم إضافية. إنها ميزة اشتراك، لذلك لا يتم تمكينها بشكل افتراضي على الخادم. يمكن تمكين مخزن الاستعلامات أو تعطيله بشكل عام لجميع قواعد البيانات على خادم معين ولا يمكن تشغيله أو إيقاف تشغيله لكل قاعدة بيانات.
هام
لا تقم بتمكين Query Store على مستوى التسعير القابل للاندفاع لأنه قد يتسبب في تأثير الأداء.
تمكين Query Store في مدخل Microsoft Azure
- سجل الدخول إلى مدخل Microsoft Azure وحدد مثيل خادم Azure Database for PostgreSQL المرن.
- حدد معلمات الخادم في قسم الإعدادات من القائمة.
- قم بإجراء بحث عن المعلمة
pg_qs.query_capture_mode. - قم بتعيين القيمة إلى
TOPأوALL، استنادا إلى ما إذا كنت تريد تعقب استعلامات المستوى الأعلى أو الاستعلامات المتداخلة أيضا (تلك التي تم تنفيذها داخل دالة أو إجراء)، وانقر فوق حفظ. السماح للدفعة الأولى من البيانات بمدة تصل إلى 20 دقيقة للاستمرار في azure_sys database.
تمكين أخذ عينات انتظار مخزن الاستعلام
- قم بإجراء بحث عن المعلمة
pgms_wait_sampling.query_capture_mode. - تعيين القيمة إلى
ALLو Save.
المعلومات في Query Store
يتكون Query Store من متجرين:
- مخزن إحصائيات وقت التشغيل لاستمرار معلومات إحصائيات تنفيذ الاستعلام.
- مخزن إحصائيات الانتظار لمعلومات إحصائيات الانتظار المستمرة.
تتضمن السيناريوهات الشائعة لاستخدام Query Store ما يلي:
- تحديد عدد المرات التي تم فيها تنفيذ استعلام في إطار زمني معين.
- مقارنة متوسط وقت تنفيذ استعلام عبر نوافذ الوقت لرؤية دلتا كبيرة.
- تحديد أطول استعلامات قيد التشغيل في الساعات القليلة الماضية.
- تحديد أهم استعلامات N التي تنتظر الموارد.
- فهم ينتظر الطبيعة لاستعلام معين.
لتقليل استخدام المساحة، يتم تجميع إحصائيات تنفيذ وقت التشغيل في مخزن إحصائيات وقت التشغيل عبر نافذة زمنية ثابتة وقابلة للتكوين. يمكن الاستعلام عن المعلومات الموجودة في هذه المخازن باستخدام طرق العرض.
الوصول إلى معلومات Query Store
يتم تخزين بيانات مخزن الاستعلام في قاعدة بيانات azure_sys على قاعدة بيانات Azure لمثيل خادم PostgreSQL المرن. يقوم الاستعلام التالي بإرجاع معلومات حول الاستعلامات في Query Store:
SELECT * FROM query_store.qs_view;
أو هذا الاستعلام عن إحصائيات الانتظار:
SELECT * FROM query_store.pgms_wait_sampling_view;
البحث عن استعلامات الانتظار
تقوم أنواع أحداث الانتظار بدمج أحداث الانتظار المختلفة في مستودعات حسب التشابه. يوفر Query Store نوع حدث الانتظار واسم حدث انتظار محدد والاستعلام المعني. القدرة على ربط معلومات الانتظار هذه بإحصائيات وقت تشغيل الاستعلام يعني أنه يمكنك الحصول على فهم أعمق لما يساهم في خصائص أداء الاستعلام.
فيما يلي بعض الأمثلة حول كيفية الحصول على مزيد من الرؤى حول حمل العمل باستخدام إحصائيات الانتظار في Query Store:
| المراقبة | الإجراء |
|---|---|
| انتظارات التأمين العالي | تحقق من نصوص الاستعلام للاستعلامات المتأثرة وحدد الكيانات المستهدفة. ابحث في Query Store عن استعلامات أخرى تقوم بتعديل نفس الكيان، والذي يتم تنفيذه بشكل متكرر و/أو له مدة عالية. بعد تحديد هذه الاستعلامات، ضع في اعتبارك تغيير منطق التطبيق لتحسين التزامن، أو استخدام مستوى عزل أقل تقييداً. |
| ينتظر High Buffer IO | ابحث عن الاستعلامات التي بها عدد كبير من القراءات الفعلية في Query Store. إذا كانت تتطابق مع الاستعلامات مع فترات انتظار IO المرتفعة، ففكر في تقديم فهرس للكيان الأساسي، من أجل القيام بالبحث بدلاً من عمليات المسح. وهذا من شأنه أن يقلل من حمل IO للاستعلامات. تحقق من توصيات الأداء للخادم الخاص بك في المدخل لمعرفة ما إذا كانت هناك توصيات فهرس لهذا الخادم من شأنها تحسين الاستعلامات. |
| انتظارات الذاكرة العالية | ابحث عن الاستعلامات الأكثر استهلاكاً للذاكرة في Query Store. ربما تؤخر هذه الاستعلامات المزيد من التقدم في الاستعلامات المتأثرة. تحقق من توصيات الأداء للخادم الخاص بك في المدخل لمعرفة ما إذا كانت هناك توصيات فهرس لهذا الخادم من شأنها تحسين الاستعلامات. |
خيارات الإعداد
عند تمكين Query Store، فإنه يحفظ البيانات في نوافذ التجميع من الطول التي تحددها معلمة pg_qs.interval_length_minutes الخادم (افتراضيا إلى 15 دقيقة). لكل نافذة، فإنه يخزن ما يصل إلى 500 استعلام مميز (مع استعلامات مميزة، وdbid، و queryid) لكل نافذة. إذا وصل عدد الاستعلامات المميزة خلال فاصل زمني إلى 500، يتم إلغاء تخصيص 5٪ مع استخدام أقل لتوفير مساحة لمزيد من.
تتوفر الخيارات التالية لتكوين معلمات Query Store:
| المعلمة | الوصف | الإعداد الافتراضي | نطاق |
|---|---|---|---|
| pg_qs.query_capture_mode | تعيين العبارات التي يتم تعقبها. | لا شيء | لا شيء، أعلى، كل |
| pg_qs.interval_length_minutes (*) | تعيين الفاصل الزمني لالتقاط query_store بالدقائق pg_qs - هذا هو تكرار استمرار البيانات. | 15 | 1 - 30 |
| pg_qs.store_query_plans | تشغيل حفظ خطط الاستعلام أو إيقاف تشغيلها pg_qs. | off | تشغيل، إيقاف |
| pg_qs.max_plan_size | قم بتعيين الحد الأقصى لعدد وحدات البايت التي سيتم حفظها لنص خطة الاستعلام pg_qs؛ سيتم اقتطاع الخطط الأطول. | 7500 | 100 - 10k |
| pg_qs.max_query_text_length | تعيين الحد الأقصى لطول الاستعلام الذي يمكن حفظه؛ سيتم اقتطاع الاستعلامات الأطول. | 6000 | 100 - 10K |
| pg_qs.retention_period_in_days | تعيين نافذة فترة الاستبقاء بالأيام pg_qs - بعد هذا الوقت سيتم حذف البيانات. | 7 | 1 - 30 |
| pg_qs.track_utility | تعيين ما إذا كان يتم تعقب أوامر الأداة المساعدة بواسطة pg_qs. | تشغيل | تشغيل، إيقاف |
(*) معلمة الخادم الثابت التي تتطلب إعادة تشغيل الخادم لتغيير قيمته لتدخل حيز التنفيذ.
تنطبق الخيارات التالية خصيصا على إحصائيات الانتظار:
| المعلمة | الوصف | الإعداد الافتراضي | نطاق |
|---|---|---|---|
| pgms_wait_sampling.query_capture_mode | تحديد العبارات التي يتم تعقبها بواسطة ملحق pgms_wait_sampling. | لا شيء | لا شيء، كل |
| Pgms_wait_sampling.history_period | تعيين التردد، بالمللي ثانية، حيث يتم أخذ عينات من أحداث الانتظار. | 100 | 1-600000 |
إشعار
pg_qs.query_capture_mode supersedes pgms_wait_sampling.query_capture_mode. إذا كان pg_qs.query_capture_mode بلا، فإن إعداد pgms_wait_sampling.query_capture_mode ليس له أي تأثير.
استخدم مدخل Microsoft Azure للحصول على قيمة مختلفة لمعلمة أو تعيينها.
طرق العرض والوظائف
عرض Query Store وإدارته باستخدام طرق العرض والوظائف التالية. يمكن لأي شخص في دور PostgreSQL العام استخدام طرق العرض هذه لمشاهدة البيانات في Query Store. تتوفر طرق العرض هذه فقط في قاعدة بيانات azure_sys.
يتم تطبيع الاستعلامات من خلال النظر إلى بنيتها وتجاهل أي شيء غير مهم دلاليا، مثل القيم الحرفية أو الثوابت أو الأسماء المستعارة أو الاختلافات في الغلاف.
إذا كان استعلامين متطابقين دلاليا، حتى إذا استخدما أسماء مستعارة مختلفة لنفس الأعمدة والجداول المشار إليها، يتم تعريفهما بنفس query_id. إذا كان استعلابان يختلفان فقط في القيم الحرفية المستخدمة فيهما، يتم تعريفهما أيضا بنفس query_id. بالنسبة لجميع الاستعلامات المحددة بنفس query_id، ستكون sql_query_text الخاصة بها هي الاستعلام الذي تم تنفيذه أولا منذ بدء Query Store نشاط التسجيل، أو منذ المرة الأخيرة التي تم فيها تجاهل البيانات المستمرة بسبب تنفيذ الدالة query_store.qs_reset .
كيفية عمل تسوية الاستعلام
فيما يلي بعض الأمثلة لمحاولة توضيح كيفية عمل هذا التطبيع:
لنفترض أنك قمت بإنشاء جدول باستخدام العبارة التالية:
create table tableOne (columnOne int, columnTwo int);
يمكنك تمكين جمع بيانات Query Store، وتنفيذ مستخدم واحد أو عدة مستخدمين للاستعلامات التالية، بهذا الترتيب الدقيق:
select * from tableOne;
select columnOne, columnTwo from tableOne;
select columnOne as c1, columnTwo as c2 from tableOne as t1;
select columnOne as "column one", columnTwo as "column two" from tableOne as "table one";
تشترك جميع الاستعلامات السابقة في نفس query_id. والنص الذي يحتفظ به Query Store هو نص الاستعلام الأول الذي تم تنفيذه بعد تمكين جمع البيانات. لذلك، سيكون select * from tableOne;.
لا تتطابق مجموعة الاستعلامات التالية، بمجرد تسويتها، مع المجموعة السابقة من الاستعلامات لأن عبارة WHERE تجعلها مختلفة دلاليا:
select columnOne as c1, columnTwo as c2 from tableOne as t1 where columnOne = 1 and columnTwo = 1;
select * from tableOne where columnOne = -3 and columnTwo = -3;
select columnOne, columnTwo from tableOne where columnOne = '5' and columnTwo = '5';
select columnOne as "column one", columnTwo as "column two" from tableOne as "table one" where columnOne = 7 and columnTwo = 7;
ومع ذلك، تشترك جميع الاستعلامات في هذه المجموعة الأخيرة في نفس query_id والنص المستخدم لتعريفها كلها هو الاستعلام الأول في الدفعة select columnOne as c1, columnTwo as c2 from tableOne as t1 where columnOne = 1 and columnTwo = 1;.
وأخيرا، ابحث أدناه عن بعض الاستعلامات التي لا تطابق query_id تلك الموجودة في الدفعة السابقة، والسبب في عدم تطابقها:
الاستعلام:
select columnTwo as c2, columnOne as c1 from tableOne as t1 where columnOne = 1 and columnTwo = 1;
سبب عدم المطابقة: تشير قائمة الأعمدة إلى نفس العمودين (columnOne و ColumnTwo)، ولكن يتم عكس الترتيب الذي تتم الإشارة إليهما به، من columnOne, ColumnTwo في الدفعة السابقة إلى ColumnTwo, columnOne في هذا الاستعلام.
الاستعلام:
select * from tableOne where columnTwo = 25 and columnOne = 25;
سبب عدم المطابقة: يتم عكس الترتيب الذي تتم به الإشارة إلى التعبيرات التي تم تقييمها في عبارة WHERE من columnOne = ? and ColumnTwo = ? في الدفعة السابقة إلى ColumnTwo = ? and columnOne = ? في هذا الاستعلام.
الاستعلام:
select abs(columnOne), columnTwo from tableOne where columnOne = 12 and columnTwo = 21;
سبب عدم المطابقة: التعبير الأول في قائمة الأعمدة ليس columnOne بعد الآن، ولكن الدالة abs التي تم تقييمها على columnOne (abs(columnOne))، وهو ليس مكافئا دلاليا.
الاستعلام:
select columnOne as "column one", columnTwo as "column two" from tableOne as "table one" where columnOne = ceiling(16) and columnTwo = 16;
سبب عدم المطابقة: لا يقيم التعبير الأول في عبارة WHERE المساواة columnOne مع القيمة الحرفية بعد الآن، ولكن مع نتيجة الدالة ceiling التي تم تقييمها على قيمة حرفية، والتي ليست مكافئة دلاليا.
طرق العرض
query_store.qs_view
تقوم طريقة العرض هذه بإرجاع كافة البيانات التي تم الاحتفاظ بها بالفعل في الجداول الداعمة لمتجر الاستعلامات. البيانات التي يتم تسجيلها في الذاكرة للنافذة الزمنية النشطة حاليا، غير مرئية حتى تنتهي النافذة الزمنية، ويتم جمع بياناتها المتقلبة في الذاكرة واستمرارها في الجداول المخزنة على القرص. ترجع طريقة العرض هذه صفا مختلفا لكل قاعدة بيانات مميزة (db_id) والمستخدم (user_id) والاستعلام (query_id).
| الاسم | النوع | المراجع | الوصف |
|---|---|---|---|
| runtime_stats_entry_id | عدد صحيح كبير | معرف من الجدول runtime_stats_entries. | |
| خاصية «user_id» | معرف العنصر | pg_authid.oid | OID للمستخدم الذي قام بتنفيذ العبارة. |
| db_id | معرف العنصر | pg_database.oid | OID لقاعدة البيانات التي تم تنفيذ العبارة فيها. |
| query_id | عدد صحيح كبير | رمز التجزئة الداخلي، المحسوب من شجرة تحليل العبارة. | |
| query_sql_text | varchar(10000) | نص بيان تمثيلي. يتم تجميع الاستعلامات المختلفة ذات البنية نفسها معاً؛ هذا النص هو نص الاستعلامات الأولى في نظام المجموعة. القيمة الافتراضية لأقصى طول لنص الاستعلام هي 6000، ويمكن تعديلها باستخدام معلمة pg_qs.max_query_text_lengthمخزن الاستعلام . إذا تجاوز نص الاستعلام هذه القيمة القصوى، يتم اقتطاعه إلى الأحرف الأولى pg_qs.max_query_text_length . |
|
| plan_id | عدد صحيح كبير | معرف الخطة المقابلة لهذا الاستعلام. | |
| start_time | الطابع الزمني | يتم تجميع الاستعلامات حسب النوافذ الزمنية، التي يتم تعريف الفترة الزمنية بواسطة معلمة pg_qs.interval_length_minutes الخادم (الافتراضي هو 15 دقيقة). هذا هو وقت البدء المطابق للنافذة الزمنية لهذا الإدخال. |
|
| end_time | الطابع الزمني | وقت الانتهاء المطابق للنافذة الزمنية لهذا الإدخال. | |
| calls | عدد صحيح كبير | عدد المرات التي تم فيها تنفيذ الاستعلام في هذه النافذة الزمنية. لاحظ أنه بالنسبة للاستعلامات المتوازية، يتوافق عدد الاستدعاءات لكل تنفيذ مع 1 لعملية الواجهة الخلفية التي تقود تنفيذ الاستعلام، بالإضافة إلى العديد من الوحدات الأخرى لكل عملية عامل خلفية، تم تشغيلها للتعاون في تنفيذ الفروع المتوازية لشجرة التنفيذ. | |
| total_time | الدقة المزدوجة | إجمالي وقت تنفيذ الاستعلام، بالمللي ثانية. | |
| min_time | الدقة المزدوجة | الحد الأدنى لوقت تنفيذ الاستعلام، بالمللي ثانية. | |
| max_time | الدقة المزدوجة | الحد الأقصى لوقت تنفيذ الاستعلام، بالمللي ثانية. | |
| mean_time | الدقة المزدوجة | متوسط وقت تنفيذ الاستعلام، بالمللي ثانية. | |
| stddev_time | الدقة المزدوجة | الانحراف المعياري لوقت تنفيذ الاستعلام، بالمللي ثانية. | |
| صفوف | عدد صحيح كبير | إجمالي عدد الصفوف التي تم استردادها أو المتأثرة بالجملة. لاحظ أنه بالنسبة للاستعلامات المتوازية، يتوافق عدد الصفوف لكل تنفيذ مع عدد الصفوف التي تم إرجاعها إلى العميل بواسطة عملية الواجهة الخلفية التي تقود تنفيذ الاستعلام، بالإضافة إلى مجموع جميع الصفوف التي تم تشغيلها كل عملية عامل خلفية، والتي تم تشغيلها للتعاون في تنفيذ الفروع المتوازية لشجرة التنفيذ، إلى عملية الواجهة الخلفية للقيادة. | |
| shared_blks_hit | عدد صحيح كبير | إجمالي عدد مرات الوصول إلى ذاكرة التخزين المؤقت للكتلة المشتركة بواسطة العبارة . | |
| shared_blks_read | عدد صحيح كبير | إجمالي عدد الكتل المشتركة المقروءة بواسطة العبارة . | |
| shared_blks_dirtied | عدد صحيح كبير | إجمالي عدد الكتل المشتركة التي تم اتساخها بواسطة العبارة . | |
| shared_blks_written | عدد صحيح كبير | إجمالي عدد الكتل المشتركة المكتوبة بواسطة العبارة . | |
| local_blks_hit | عدد صحيح كبير | إجمالي عدد مرات الوصول إلى ذاكرة التخزين المؤقت للكتلة المحلية بواسطة العبارة . | |
| local_blks_read | عدد صحيح كبير | إجمالي عدد الكتل المحلية المقروءة بواسطة العبارة . | |
| local_blks_dirtied | عدد صحيح كبير | إجمالي عدد الكتل المحلية التي تم اتساخها بواسطة العبارة . | |
| local_blks_written | عدد صحيح كبير | إجمالي عدد الكتل المحلية المكتوبة بواسطة العبارة . | |
| temp_blks_read | عدد صحيح كبير | إجمالي عدد الكتل المؤقتة المقروءة بواسطة العبارة . | |
| temp_blks_written | عدد صحيح كبير | إجمالي عدد الكتل المؤقتة المكتوبة بواسطة العبارة . | |
| blk_read_time | الدقة المزدوجة | إجمالي الوقت الذي أمضته العبارة في قراءة الكتل، بالمللي ثانية (إذا تم تمكين track_io_timing، وإلا فلن تكون هناك أي كتل). | |
| blk_write_time | الدقة المزدوجة | إجمالي الوقت الذي أمضته العبارة في كتابة الكتل، بالمللي ثانية (إذا تم تمكين track_io_timing، وبخلاف ذلك صفر). | |
| is_system_query | boolean | تحديد ما إذا كان الاستعلام قد تم تنفيذه حسب الدور باستخدام user_id = 10 (azuresu)، الذي يحتوي على امتيازات المستخدم الفائق ويستخدم لتنفيذ عمليات جزء التحكم. نظرا لأن هذه الخدمة هي خدمة PaaS مدارة، فإن Microsoft فقط هي جزء من دور المستخدم الفائق هذا. | |
| query_type | النص | نوع العملية التي يمثلها الاستعلام. القيم المحتملة هي unknown، select، update، insert، delete، merge، utility، ، nothing. undefined |
query_store.query_texts_view
تقوم طريقة العرض هذه بإرجاع بيانات نص الاستعلام في Query Store. يوجد صف واحد لكل query_sql_text مميز.
| الاسم | النوع | الوصف |
|---|---|---|
| query_text_id | عدد صحيح كبير | معرف الجدول query_texts |
| query_sql_text | varchar(10000) | نص بيان تمثيلي. يتم تجميع الاستعلامات المختلفة ذات البنية نفسها معاً؛ هذا النص هو نص الاستعلامات الأولى في نظام المجموعة. |
| query_type | Smallint | نوع العملية التي يمثلها الاستعلام. في إصدار PostgreSQL <= 14، تكون 0 القيم المحتملة (غير معروفة)، (تحديد)، 1 (تحديث)، 2 (إدراج)، 3 (حذف)، 5 4 (أداة مساعدة)، 6 (لا شيء). في إصدار PostgreSQL >= 15، تكون القيم 0 المحتملة (غير معروفة)، (تحديد)، 1 (تحديث)، 2 (إدراج)، 3 (حذف)، 4 (دمج)، 6 5 (أداة مساعدة)، 7 (لا شيء). |
query_store.pgms_wait_sampling_view
تقوم طريقة العرض هذه بإرجاع بيانات أحداث الانتظار في Query Store. ترجع طريقة العرض هذه صفا مختلفا لكل قاعدة بيانات مميزة (db_id) والمستخدم (user_id) والاستعلام (query_id) والحدث (الحدث).
| الاسم | النوع | المراجع | الوصف |
|---|---|---|---|
| start_time | الطابع الزمني | يتم تجميع الاستعلامات حسب النوافذ الزمنية، التي يتم تعريف الفترة الزمنية بواسطة معلمة pg_qs.interval_length_minutes الخادم (الافتراضي هو 15 دقيقة). هذا هو وقت البدء المطابق للنافذة الزمنية لهذا الإدخال. |
|
| end_time | الطابع الزمني | وقت الانتهاء المطابق للنافذة الزمنية لهذا الإدخال. | |
| خاصية «user_id» | معرف العنصر | pg_authid.oid | OID للمستخدم الذي قام بتنفيذ العبارة. |
| db_id | معرف العنصر | pg_database.oid | OID لقاعدة البيانات التي تم تنفيذ العبارة فيها. |
| query_id | عدد صحيح كبير | رمز التجزئة الداخلي، المحسوب من شجرة تحليل العبارة. | |
| event_type | النص | نوع الحدث الذي تنتظره الخلفية. | |
| event | النص | اسم حدث الانتظار إذا كانت الخلفية قيد الانتظار حاليا. | |
| calls | integer | عدد المرات التي تم فيها التقاط نفس الحدث. |
إشعار
للحصول على قائمة بالقيم المحتملة في أعمدة event_type والحدث في طريقة العرض query_store.pgms_wait_sampling_view، راجع الوثائق الرسمية pg_stat_activity وابحث عن المعلومات التي تشير إلى أعمدة بنفس الأسماء.
query_store.query_plans_view
طريقة العرض هذه ترجع خطة الاستعلام التي تم استخدامها لتنفيذ استعلام. يوجد صف واحد لكل معرف قاعدة بيانات مميز، ومعرف الاستعلام. سيؤدي ذلك إلى تخزين خطط الاستعلام للاستعلامات غير القابلة للعبث فقط.
| plan_id | db_id | query_id | plan_text |
|---|---|---|---|
| plan_id | عدد صحيح كبير | قيمة التجزئة من خطة الاستعلام التي تم تسويتها التي تنتجها EXPLAIN. يعتبر تسوية لأنه يستبعد التكاليف المقدرة لعقد الخطة واستخدام المخازن المؤقتة. | |
| db_id | معرف العنصر | pg_database.oid | OID لقاعدة البيانات التي تم تنفيذ العبارة فيها. |
| query_id | عدد صحيح كبير | رمز التجزئة الداخلي، المحسوب من شجرة تحليل العبارة. | |
| plan_text | varchar(10000) | خطة تنفيذ العبارة المعطاة التكاليف=خطأ، المخازن المؤقتة=خطأ، وتنسيق=نص. هذا هو نفس الإخراج الذي تعطيه EXPLAIN. |
الوظائف
query_store.qs_reset
تتجاهل هذه الدالة كافة الإحصائيات التي تم جمعها حتى الآن بواسطة Query Store. فإنه يتجاهل كل من الإحصائيات للنوافذ الزمنية المغلقة بالفعل، والتي تم الاحتفاظ بها على جداول القرص، وتلك الخاصة بالنافذة الزمنية الحالية، والتي لا تزال محفوظة في الذاكرة. يمكن تنفيذ هذه الدالة فقط بواسطة دور مسؤول الخادم (azure_pg_admin).
query_store.staging_data_reset
تتجاهل هذه الدالة جميع الإحصائيات التي تم جمعها في الذاكرة بواسطة Query Store (أي البيانات الموجودة في الذاكرة التي لم يتم مسحها بعد إلى جداول القرص التي تدعم استمرار البيانات المجمعة لمخزن الاستعلامات). يمكن تنفيذ هذه الدالة فقط بواسطة دور مسؤول الخادم (azure_pg_admin).
وضع القراءة فقط
عندما تكون قاعدة بيانات Azure ل PostgreSQL - مثيل الخادم المرن في وضع القراءة فقط، مثل عند default_transaction_read_only تعيين المعلمة إلى on، أو إذا تم تمكين وضع القراءة فقط تلقائيا بسبب الوصول إلى سعة التخزين، لا يلتقط Query Store أي بيانات.