PostgreSQL सिस्टम कैटलॉग को समझना और पढ़ना

डेटाबेस को प्रबंधित करना कोई छोटा काम नहीं है, और कवर के तहत क्या हो रहा है, यह जाने बिना आसानी से निराशा हो सकती है। क्या यह पता लगाने की कोशिश की जा रही है कि क्या नए इंडेक्स मददगार हैं, एक निश्चित समय पर डेटाबेस पर लेन-देन की गिनती होती है, या जो किसी भी समय डेटाबेस से जुड़ा होता है, डेटा जो प्रशासकों को वास्तव में यह जानने की अनुमति देता है कि उनके डेटाबेस कैसा प्रदर्शन कर रहे हैं। सौभाग्य से, PostgreSQL के साथ, इन सब के लिए वह डेटा PostgreSQL सिस्टम कैटलॉग में उपलब्ध है।

PostgreSQL सिस्टम कैटलॉग तालिकाओं और दृश्यों के साथ एक स्कीमा है जिसमें डेटाबेस के अंदर अन्य सभी वस्तुओं के बारे में मेटाडेटा और बहुत कुछ होता है। इसके साथ, हम यह पता लगा सकते हैं कि विभिन्न ऑपरेशन कब होते हैं, टेबल या इंडेक्स कैसे एक्सेस किए जाते हैं, और यहां तक ​​कि डेटाबेस सिस्टम मेमोरी से जानकारी पढ़ रहा है या नहीं या डिस्क से डेटा लाने की जरूरत है।

यहां हम सिस्टम कैटलॉग के एक सिंहावलोकन पर जाएंगे, और इसे कैसे पढ़ा जाए, और इससे उपयोगी जानकारी कैसे प्राप्त करें, इस पर प्रकाश डालेंगे। कुछ मेटाडेटा सीधा है, और अन्य टुकड़े वास्तविक उपयोगी जानकारी उत्पन्न करने के लिए पचने में थोड़ा समय लेते हैं। किसी भी तरह से, PostgreSQL हमें डेटाबेस के बारे में जो भी जानकारी चाहिए, उसे बनाने के लिए हमें एक बेहतरीन मंच प्रदान करता है।

द पोस्टग्रेएसक्यूएल कैटलॉग

PostgreSQL 'pg_catalog' स्कीमा में डेटाबेस और क्लस्टर के बारे में मेटाडेटा जानकारी संग्रहीत करता है। यह जानकारी आंशिक रूप से PostgreSQL द्वारा ही चीजों का ट्रैक रखने के लिए उपयोग की जाती है, लेकिन इसे भी प्रस्तुत किया जाता है ताकि बाहरी लोग/प्रक्रियाएं डेटाबेस के अंदर भी समझ सकें।

PostgreSQL कैटलॉग का एक बहुत ही ठोस नियम है:देखो, स्पर्श मत करो। जबकि PostgreSQL इस सारी जानकारी को किसी भी अन्य एप्लिकेशन की तरह तालिकाओं में संग्रहीत करता है, तालिकाओं में डेटा पूरी तरह से PostgreSQL द्वारा ही प्रबंधित किया जाता है, और इसे तब तक संशोधित नहीं किया जाना चाहिए जब तक कि एक पूर्ण आपात स्थिति न हो, और फिर भी बाद में पुनर्निर्माण की संभावना हो।

हम कुछ उपयोगी कैटलॉग टेबल पर जाएंगे, डेटा को कैसे पढ़ा जाए, और चतुर चीजें जो हम डेटा के साथ ही कर सकते हैं। कैटलॉग में कुछ ऐसी तालिकाएँ हैं जिन पर हम ध्यान नहीं देंगे, लेकिन इन विभिन्न तालिकाओं के लिए सभी जानकारी PostgreSQL के आधिकारिक दस्तावेज़ीकरण पर पाई जा सकती है।

सिस्टम वाइड मेटाडेटा

कैटलॉग में हम जिन तालिकाओं को क्वेरी कर सकते हैं उनका एक अच्छा हिस्सा 'सिस्टम वाइड' टेबल हैं, जहां इससे कोई फर्क नहीं पड़ता कि हम किस डेटाबेस से जुड़े हैं, डेटा पूरे क्लस्टर का प्रतिनिधित्व करता है, कोई एकवचन डेटाबेस नहीं।

डेटाबेस जानकारी

सामान्य डेटाबेस जानकारी pg_database में संग्रहीत होती है और आंकड़े pg_stat_database में संग्रहीत होते हैं।

pg_डेटाबेस:

postgres=# SELECT oid,* FROM pg_database WHERE datname = 'severalnines';
-[ RECORD 1 ]-+-------------
oid           | 16396
datname       | severalnines
datdba        | 10
encoding      | 6
datcollate    | en_US.UTF-8
datctype      | en_US.UTF-8
datistemplate | f
datallowconn  | t
datconnlimit  | -1
datlastsysoid | 13804
datfrozenxid  | 548
datminmxid    | 1
dattablespace | 1663
datacl        |

तालिका pg_database में क्लस्टर में प्रत्येक डेटाबेस के लिए एक पंक्ति होती है, जिसमें तीन जो बॉक्स से बाहर आते हैं (पोस्टग्रेज, टेम्प्लेट 0 और टेम्प्लेट 1) शामिल हैं। इस पंक्ति में एन्कोडिंग, कनेक्शन सीमा और अन्य बुनियादी मेटाडेटा की जानकारी है।

रुचि के स्तंभ:

oid - ऑब्जेक्ट आइडेंटिफ़ायर, जो सीधे संदर्भित होने तक क्वेरी आउटपुट में प्रकट नहीं होता है। यह नंबर क्लस्टर डेटा निर्देशिका /base/.
datname - डेटाबेस का नाम में एक निर्देशिका से मेल खाएगा।
datdba - डेटाबेस का मालिक, ओआईडी संदर्भ pg_authid .oid.
एन्कोडिंग - इस डेटाबेस के लिए वर्ण एन्कोडिंग, pg_encoding_to_char() एक पठनीय नाम में बदल जाएगा।
datconnlimit - डेटाबेस पर अनुमत समवर्ती कनेक्शन की अधिकतम संख्या।
dattablespace - The इस डेटाबेस के लिए डिफ़ॉल्ट टेबलस्पेस, संदर्भ pg_tablespace.oid।

pg_stat_database:

postgres=# SELECT * FROM pg_stat_database WHERE datname = 'severalnines';
-[ RECORD 1 ]--+------------------------------
datid          | 13805
datname        | postgres
numbackends    | 2
xact_commit    | 477460
xact_rollback  | 13
blks_read      | 417
blks_hit       | 16488702
tup_returned   | 252376522
tup_fetched    | 2637123
tup_inserted   | 114
tup_updated    | 3
tup_deleted    | 1
conflicts      | 0
temp_files     | 0
temp_bytes     | 0
deadlocks      | 0
blk_read_time  | 0
blk_write_time | 0
stats_reset    | 2018-02-04 19:52:39.129052+00

यह स्टेट टेबल वह जगह है जहां हमें दिलचस्प और उपयोगी डेटा मिलता है। इस तालिका की प्रत्येक पंक्ति में प्रत्येक डेटाबेस के लिए लाइव डेटा होता है, और परिवर्तनों की निगरानी करने की इच्छा होने पर समय के साथ ट्रैक करने के लिए समय-समय पर निर्यात किया जा सकता है।

लेन-देन

लेन-देन की जानकारी कॉलम xact_commit और xact_rollback में पाई जा सकती है, जिसमें डेटाबेस द्वारा किए गए लेन-देन की संख्या होती है और क्रमशः वापस रोल किया जाता है। यह यह दिखाने में मदद करेगा कि डेटाबेस कितना सक्रिय है, साथ ही उन प्रोग्रामों के साथ संभावित विफलताओं का पता लगाने में मदद करेगा जो खतरनाक दर पर त्रुटि/रोल बैक कर सकते हैं।

डिस्क और मेमोरी एक्सेस

डिस्क या मेमोरी से डेटा पुनर्प्राप्त किया गया है या नहीं, इसकी जानकारी blks_read और blks_hit कॉलम में संग्रहीत है। Blks_read इस डेटाबेस को डिस्क से पढ़े जाने वाले ब्लॉकों की संख्या दिखाता है, जबकि blks_hit PostgreSQL के बफर कैश (shared_buffers पैरामीटर द्वारा दर्शाए गए) में पाए गए ब्लॉकों की संख्या दिखाता है। चूँकि RAM डिस्क की तुलना में बहुत तेज़ है, हम आदर्श रूप से blks_read की तुलना में blks_hit लगातार उच्च देखेंगे, और यदि नहीं, तो हम अपनी उपलब्ध मेमोरी का पुनर्मूल्यांकन कर सकते हैं।

टुपल्स

अगले कुछ कॉलम टुपल्स से संबंधित हैं। Tup_returned डेटाबेस में लौटाई गई पंक्तियों की संख्या है, जो किसी तालिका से अनुक्रमिक स्कैन द्वारा पढ़ी जाने वाली पंक्तियों की संख्या है, या किसी अनुक्रमणिका से वापस आने वाली अनुक्रमणिका प्रविष्टियों की संख्या है"। Tup_fetched डेटाबेस में लाई गई पंक्तियों की संख्या है, जिसका अर्थ है कि वे बिटमैप स्कैन का परिणाम थे, जो कि किसी तालिका से बिटमैप स्कैन द्वारा प्राप्त की गई तालिका पंक्तियों की संख्या है, या अनुक्रमणिका का उपयोग करने पर सरल अनुक्रमणिका स्कैन द्वारा प्राप्त तालिका पंक्तियाँ हैं।

हमारे पास tup_inserted, tup_updated, और tup_deleted भी हैं, जो क्रमशः इस डेटाबेस में सम्मिलित, अद्यतन और हटाए गए टुपल्स की संख्या को दर्शाता है। यह समझने में मदद करेगा कि डेटा डेटाबेस में कैसे प्रवेश करता है, बदलता है और छोड़ता है। चूंकि अद्यतन और हटाए गए ट्यूपल्स मृत पंक्तियों में परिणाम देते हैं, इन स्तंभों में उच्च मान डेटाबेस गतिविधि की जरूरतों को पूरा करने के लिए ऑटोवैक्यूम संचालन को ट्यून करने का सुझाव देंगे।

संघर्ष

यदि विचाराधीन डेटाबेस एक स्टैंडबाय सर्वर है, तो कॉलम विरोध यह ट्रैक करने के तरीके के रूप में काम आता है कि स्टैंडबाय के 'रिकवरी मोड' में होने के कारण विरोध के कारण कितने प्रश्नों को रद्द किया गया था। यदि स्टैंडबाय क्लस्टर नहीं है, तो इस कॉलम को अनदेखा किया जा सकता है।

अस्थायी फ़ाइलें / डेटा

कभी-कभी, प्रश्नों को अस्थायी फ़ाइलों पर लिखने की आवश्यकता होगी। यह तब हो सकता है जब कनेक्शन के लिए आवंटित वर्क_मेम की मात्रा का उपयोग किया गया हो, और मेमोरी के बजाय डिस्क पर सॉर्ट ऑपरेशन जारी रखने की आवश्यकता होती है। स्तंभ temp_files बनाई गई इन फ़ाइलों की संख्या को ट्रैक करता है, और temp_bytes उपयोग की गई सभी अस्थायी फ़ाइलों के कुल आकार को ट्रैक करता है। यह डेटा वर्क_मेम ट्यूनिंग को सूचित करने में मदद कर सकता है, या यहां तक ​​कि ऐसी क्वेरी खोजने में मदद कर सकता है जो अस्थायी फ़ाइल का आकार बहुत बड़ा होने पर री-राइटिंग का उपयोग कर सकती हैं।

गतिरोध

डेडलॉक कॉलम ट्रैक करता है कि डेडलॉक कितनी बार होता है। चूंकि एक गतिरोध क्वेरी के लिए त्रुटियों का कारण बन सकता है जो अन्यथा त्रुटि नहीं होगी, इसे ट्रैक करना और यह सुनिश्चित करना अच्छा है कि एप्लिकेशन एक दूसरे के पैरों पर कदम नहीं उठा रहे हैं।

पढ़ने और लिखने का समय

कॉलम blk_read_time और blk_write_time मिलीसेकंड की कुल संख्या को ट्रैक करता है जो डेटाबेस में बैकएंड डेटा पढ़ने और लिखने में खर्च करता है, जो डिस्क पढ़ने / लिखने की गति की तुलना / सुधार करने में मददगार हो सकता है

आंकड़े रीसेट

यह कॉलम, stats_reset, बस एक टाइमस्टैम्प (समय क्षेत्र के साथ) दिखाता है कि पिछली बार इस पंक्ति में उल्लिखित आँकड़ों को रीसेट किया गया था। एक शून्य मान का मतलब है कि उन्हें स्थापना के बाद से रीसेट नहीं किया गया है, या यहां तक ​​​​कि संभवतः डेटाबेस का क्रैश भी हो सकता है जो इन आंकड़ों को मिटा सकता है।

चेकपॉइंट और बैकग्राउंड राइटर

pg_stat_bgwriter

postgres=# SELECT * FROM pg_stat_bgwriter;
-[ RECORD 1 ]---------+------------------------------
checkpoints_timed     | 47829
checkpoints_req       | 2
checkpoint_write_time | 7323
checkpoint_sync_time  | 38
buffers_checkpoint    | 76
buffers_clean         | 0
maxwritten_clean      | 0
buffers_backend       | 5
buffers_backend_fsync | 0
buffers_alloc         | 440
stats_reset           | 2018-02-04 19:52:34.712832+00

PostgtreSQL क्लस्टर कई अलग-अलग तरीकों से डिस्क पर डेटा लिखने का प्रबंधन करता है। 'डर्टी बफ़र्स' के संदर्भ में (स्मृति में डेटा जिसे डिस्क से पढ़ने के बाद से बदल दिया गया है, लेकिन अभी तक उस परिवर्तन को डिस्क पर लिखा नहीं गया है), यह या तो एक चेकपॉइंट, या पृष्ठभूमि लेखक द्वारा किया जाता है। चूंकि एक गंदे बफर को डिस्क पर मुक्त या पुनः आवंटित करने से पहले लिखा जाना चाहिए, यह सुनिश्चित करना महत्वपूर्ण है कि इन प्रक्रियाओं को ठीक से ट्यून किया गया है, और यह तालिका इस बात पर प्रकाश डालने में मदद करती है कि यह सब कैसे काम कर रहा है।

चेकपॉइंट

एक चेकपॉइंट या तो शेड्यूल पर होता है (चेकपॉइंट_टाइमआउट पैरामीटर द्वारा दर्शाया गया है), या जब अंतिम चेकपॉइंट के बाद से अधिकतम मात्रा में WAL फ़ाइलों का उपयोग किया गया है, और एक चेकपॉइंट को मजबूर करने की आवश्यकता है। किसी भी तरह, एक चेकपॉइंट डिस्क पर गंदे बफर लिखता है, और इसे ट्रैक करने वाले चार कॉलम होते हैं।

कॉलम checkpoints_timed और checkpoints_req अनुसूचित चौकियों की संख्या (समयबद्ध) और अनुरोधित चौकियों की संख्या (जिसे मजबूर भी कहा जाता है) दिखाते हैं। checkpoint_req का उच्च चढ़ाई मान एक अपर्याप्त max_wal_size मान का सुझाव दे सकता है।

कॉलम checkpoint_write_time और checkpoint_sync_time कुल समय रिकॉर्ड करते हैं (मिलीसेकंड में) चेकपॉइंट प्रक्रिया ने डिस्क पर लिखने और सिंक करने में खर्च किया है।

अंत में, बफ़र्स_चेकपॉइंट चौकियों द्वारा डिस्क पर लिखे गए बफ़र्स की कुल संख्या है।

बैकग्राउंड राइटर

बैकग्राउंड राइटर एक अलग प्रक्रिया है जो डिस्क पर गंदे बफ़र्स लिखता है, जो आदर्श रूप से चेकपॉइंटर को किए जाने वाले काम की मात्रा को कम करता है।

कॉलम बफ़र्स_क्लीन पृष्ठभूमि प्रक्रिया द्वारा डिस्क पर लिखे गए बफ़र्स की संख्या का प्रतिनिधित्व करता है। बफ़र्स_चेकपॉइंट की तुलना में, यह दिखाता है कि प्रत्येक प्रक्रिया द्वारा कितना कार्यभार संभाला जाता है (अतिरिक्त ज्ञान के साथ कि पृष्ठभूमि लेखक के पास बफ़र्स को कई बार लिखने की संभावना होती है यदि वे अक्सर बदलते हैं, बनाम एक समयबद्ध चेकपॉइंट के साथ कम बार)।

मैक्सलिखित_क्लीन यह दर्शाता है कि कितनी बार पृष्ठभूमि लेखक हर बार चलने पर फ़्लश करने के लिए पृष्ठों की अधिकतम संख्या तक पहुँचता है (bgwriter_lru_maxpages पैरामीटर के साथ नियंत्रित)।

सामान्य रूप से बफ़र

शेष कॉलम हमें सामान्य बफ़र जानकारी दिखाते हैं, जिसमें बफ़र्स_बैकएंड बफ़र्स की संख्या होती है, जिसे बैकएंड को खुद लिखना होता है, बैकग्राउंड राइटर या चेकपॉइंटर के बजाय, बफ़र्स_बैकएंड_फ़सिंक इस बात की गिनती है कि बैकएंड को कितनी बार अपने स्वयं के fsync कॉल को निष्पादित करना पड़ा, और बफ़र्स_आलोक सामान्य रूप से आवंटित किए गए बफ़र्स की संख्या दिखाता है।

डेटाबेस गतिविधि और लॉक

दो दृश्य हैं जो वर्तमान उपयोगकर्ता गतिविधि दिखाते हैं, pg_stat_activity और pg_locks। जब पूछताछ की जाती है, तो ये डेटाबेस के वर्तमान कनेक्शन के बारे में जानकारी दिखाते हैं, और किस तरह के संबंधों पर उनके पास किस प्रकार के ताले हैं।

pg_stat_activity

postgres=# SELECT * FROM pg_stat_activity;
-[ RECORD 1 ]----+--------------------------------
datid            | 13805
datname          | severalnines
pid              | 29730
usesysid         | 10
usename          | postgres
application_name | psql
client_addr      |
client_hostname  |
client_port      | -1
backend_start    | 2018-07-21 02:29:48.976588+00
xact_start       | 2018-07-21 02:30:03.73683+00
query_start      | 2018-07-21 02:30:03.73683+00
state_change     | 2018-07-21 02:30:03.736835+00
wait_event_type  |
wait_event       |
state            | active
backend_xid      |
backend_xmin     | 559
query            | SELECT first_name FROM customers WHERE customers_sid = 472;
backend_type     | client backend

सामान्य जानकारी

pg_stat_activity दृश्य डेटाबेस से प्रत्येक कनेक्शन के लिए एक पंक्ति और इसके बारे में कुछ बुनियादी जानकारी दिखाता है। कॉलम डेटानाम उस डेटाबेस का प्रतिनिधित्व करता है जिससे कनेक्शन वास्तव में जुड़ा हुआ है, पीआईडी ​​​​डेटाबेस होस्ट पर ही कनेक्शन की प्रक्रिया आईडी है, और यूज़सिसिड और यूज़नाम कनेक्टेड डेटाबेस उपयोगकर्ता का प्रतिनिधित्व करते हैं।

क्लाइंट के स्रोत के लिए, client_addr उस होस्ट का IP पता है जिससे कनेक्शन आया था, नल का अर्थ है कि यह एक स्थानीय यूनिक्स सॉकेट कनेक्शन है।

टाइमस्टैम्प

चार टाइमस्टैम्प कॉलम हैं जो दिखाते हैं कि कुछ चीजें कब शुरू हुईं:बैकएंड_स्टार्ट तब है जब कनेक्शन वास्तव में स्थापित किया गया था, xact_start तब होता है जब वर्तमान लेनदेन शुरू होता है (यदि क्लाइंट के पास कोई खुला लेनदेन नहीं है), query_start तब होता है जब वर्तमान या सबसे हाल की क्वेरी शुरू होती है, और State_change वह समय है जब कनेक्शन की स्थिति पिछली बार बदली गई थी।

कनेक्शन स्थिति

pg_stat_activity के अंतिम बिट्स कनेक्शन की वास्तविक स्थिति को कवर करते हैं। यदि क्वेरी लॉक जारी करने के लिए दूसरे पर प्रतीक्षा कर रही है, तो Wait_event_type में कुछ जानकारी है कि यह किस प्रकार की प्रतीक्षा घटना है, और कॉलम प्रतीक्षा_इवेंट प्रतीक्षा ईवेंट नाम दिखाएगा। यह एक लंबी सूची है, लेकिन पोस्टग्रेएसक्यूएल दस्तावेज़ीकरण में अधिक जानकारी मिली है।

अंत में, कॉलम 'स्टेट' दिखाता है कि वर्तमान कनेक्शन किस स्थिति में है, जैसे कि सक्रिय, निष्क्रिय, लेन-देन में निष्क्रिय, और क्वेरी कॉलम वास्तविक क्वेरी को चला रहा है, या हाल ही में चलाया गया है।

pg_lock

SELECT * FROM pg_locks;
-[ RECORD 1 ]------+----------------
locktype           | virtualxid
database           |
relation           |
page               |
tuple              |
virtualxid         | 3/475862
transactionid      |
classid            |
objid              |
objsubid           |
virtualtransaction | 3/475862
pid                | 29730
mode               | ExclusiveLock
granted            | t
fastpath           | t

यदि क्वेरी गतिविधि को देखा जाए तो pg_locks तालिका pg_stat_activity के साथ हाथ से काम करती है। जब भी किसी रिलेशन को लॉक किया जाता है, तो वह जानकारी pg_locks में स्टोर हो जाती है। pg_stat_activity से pid का उपयोग करके, हम pg_locks को यह देखने के लिए क्वेरी कर सकते हैं कि किसी कनेक्शन में कौन से संबंध लॉक हो सकते हैं, वे किस प्रकार के ताले हैं, और ताले दिए गए हैं या नहीं।

सबसे महत्वपूर्ण कॉलम 'पिड' हैं, जो pg_stat_activity से पिड से मेल खाता है, 'रिलेशन' जो pg_class से ओआईडी से मेल खाता है, 'मोड' आयोजित लॉक मोड का नाम दिखाता है, और 'अनुदान' जो बताता है कि लॉक इन है या नहीं प्रश्न दिया गया है।

प्रतिकृति जानकारी

चूंकि PostgreSQL ने प्रतिकृति सुविधाओं में बनाया है, ऐसे कुछ विचार हैं जो प्रदर्शन और प्रतिकृति की स्थिति पर ही प्रकाश डालते हैं।

pg_stat_replication देखें: प्रत्येक WAL प्रेषक प्रक्रिया के लिए एक पंक्ति होती है, जिसमें इसकी स्थिति, WAL फ़ाइलों के स्थान के बारे में जानकारी होती है, जिस पर वह काम कर रहा है, और स्टैंडबाय होस्ट की कनेक्शन जानकारी जो प्रतिकृति के लिए WAL डेटा प्राप्त कर रहा है।

pg_stat_wal_receiver देखें: यदि क्लस्टर एक स्टैंडबाय है, तो इसमें एक एकल पंक्ति होगी जो मेजबान के रूप में रिसीवर प्रक्रिया के बारे में आंकड़े दिखाती है।

pg_stat_subscription देखें: यदि WAL डेटा को स्टैंडबाय नोड में भेजा जा रहा है, तो यहां की प्रत्येक पंक्ति उस सदस्यता का प्रतिनिधित्व करेगी, और इसमें सदस्यता की स्थिति के बारे में जानकारी होगी।

pg_replication_slots देखें: क्लस्टर पर मौजूद सभी प्रतिकृति स्लॉट और उनकी वर्तमान स्थिति की एक सूची शामिल है।

डेटाबेस विशिष्ट मेटाडेटा

प्रत्येक डेटाबेस के अंदर कैटलॉग टेबल का एक संग्रह होता है जिसमें डेटाबेस के लिए विशिष्ट जानकारी होती है जिसे क्वेरी किया जा रहा है। यदि हम इन तालिकाओं से विशिष्ट डेटा की तलाश कर रहे हैं, तो हमें यह सुनिश्चित करना चाहिए कि हम सही डेटाबेस से जुड़े हैं क्योंकि हम प्रश्न जारी करते हैं।

यह वह जगह है जहां डेटा विश्लेषण का दिल आ सकता है, जहां हम देख सकते हैं कि हमारे उपयोगकर्ता डेटा को कैसे एक्सेस किया जा रहा है। तालिकाओं से लेकर अनुक्रमित तक, डेटाबेस में आने वाली क्वेरी और डेटा लाने या संशोधित करने, उनके कार्यों और प्रभाव को इन तालिकाओं में संग्रहीत किया जाएगा, और हम डेटाबेस को प्रबंधित करने के बारे में सूचित निर्णय लेने के लिए उस जानकारी को देख सकते हैं। सड़क।

टेबल मेटाडेटा

हमारे उपयोगकर्ता तालिकाओं के बारे में मेटाडेटा निम्नलिखित दो तालिकाओं में संग्रहीत किया जाता है, और उनमें से प्रत्येक में सिस्टम में बनाई गई प्रत्येक उपयोगकर्ता तालिका के लिए एक पंक्ति होती है। तालिका pg_stat_user_tables में तालिका तक उपयोगकर्ता पहुंच के आंकड़े होते हैं, जबकि pg_statio_user_tables में प्रत्येक तालिका के लिए I/O आंकड़े होते हैं।

नोट:यहां दिया गया डेटा हमेशा 100% सही नहीं होता है, और सही होने के लिए तालिकाओं के लगातार विश्लेषण पर निर्भर करता है। स्वतः विश्लेषण इसे कवर करता है, लेकिन स्वतः विश्लेषण प्रक्रिया की अच्छी ट्यूनिंग ताकि यह प्रत्येक तालिका के बारे में अच्छे आंकड़े रख सके। यदि आंकड़े बंद प्रतीत होते हैं, तो तालिका पर मैन्युअल रूप से विश्लेषण चलाने से वे ताज़ा हो जाएंगे।

तालिका pg_stat_user_tables:

severalnines=> SELECT * FROM pg_stat_user_tables WHERE schemaname = 'public' AND relname = 'history';
-[ RECORD 1 ]-------+---------
relid               | 2766788
schemaname          | public
relname             | history
seq_scan            | 13817
seq_tup_read        | 466841
idx_scan            | 12251
idx_tup_fetch       | 127652
n_tup_ins           | 11
n_tup_upd           | 13
n_tup_del           | 3
n_tup_hot_upd       | 13
n_live_tup          | 3
n_dead_tup          | 21
n_mod_since_analyze | 19
last_vacuum         |
last_autovacuum     |
last_analyze        |
last_autoanalyze    |
vacuum_count        | 0
autovacuum_count    | 0
analyze_count       | 0
autoanalyze_count   | 0

हमारे उपयोगकर्ता तालिका आँकड़ों के लिए, हमारे पास डेटा के कुछ टुकड़े हैं।

टेबल एक्सेस के तरीके

जब क्लाइंट टेबल से डेटा एक्सेस करते हैं, तो यह सीधे या इंडेक्स के माध्यम से ऐसा करता है। कॉलम 'seq_scan' प्राप्त अनुक्रमिक स्कैन की संख्या की गणना करता है, और 'seq_tup_read' उस प्रक्रिया के माध्यम से पढ़े जाने वाले टुपल्स की संख्या की गणना करता है। कॉलम 'idx_scan' यह गिनता है कि डेटा लाने के लिए टेबल पर मौजूद इंडेक्स का कितनी बार इस्तेमाल किया गया था।

टेबल टुपल गतिविधि

अब हमारे पास कुछ कॉलम हैं जो टेबल पर विभिन्न गतिविधियों की गणना करते हैं।

'n_tup_ins' डाले गए टुपल्स की संख्या को ट्रैक करता है

'n_tup_upd' अपडेट किए गए टुपल्स की संख्या को ट्रैक करता है

'n_tup_del' हटाए गए टुपल्स की संख्या को ट्रैक करता है

टेबल टुपल स्टेट

अपडेट और डिलीट के कारण, मृत टुपल्स हो सकते हैं जो अब सक्रिय डेटा नहीं हैं, और वैक्यूम प्रक्रिया अंततः उन्हें मुक्त कर देगी। कॉलम 'n_tup_ins' और 'n_tup_ins' क्रमशः जीवित और मृत टुपल्स की संख्या को ट्रैक करते हैं। जब मृत ट्यूपल्स एक निश्चित बिंदु पर पहुंच जाते हैं, तो ऑटोवैक्यूम सेटिंग्स के आधार पर एक ऑटोवैक्यूम लॉन्च किया जाएगा।

टेबल वैक्यूम गतिविधि

टेबल रखरखाव या तो वैक्यूम या ऑटोवैक्यूम के माध्यम से किया जाता है, और आंकड़े विश्लेषण या ऑटोएनालिज के माध्यम से एकत्र किए जाते हैं। अगले चार कॉलम में ये तारीखें होती हैं कि इनमें से प्रत्येक ऑपरेशन को आखिरी बार कब चलाया गया था:'last_vacuum', 'last_autovacuum', 'last_analyze', 'last_autoanalyze'।

हमारे पास चार और सुविधाजनक कॉलम भी हैं जो केवल यह गिनते हैं कि पिछली कार्रवाइयां कितनी बार हुईं। इनका उपयोग करके, हम देख सकते हैं कि किन तालिकाओं में सबसे अधिक गतिविधि होती है:'vacuum_count', 'autovacuum_count', 'analyze_count', और 'autoanalyze_count'।

तालिका pg_statio_user_tables:

severalnines=> SELECT * FROM pg_statio_user_tables WHERE schemaname = 'public' AND relname = history;
-[ RECORD 1 ]---+---------
relid           | 2766788
schemaname      | public
relname         | history
heap_blks_read  | 4
heap_blks_hit   | 63081
idx_blks_read   | 5
idx_blks_hit    | 44147
toast_blks_read | 0
toast_blks_hit  | 0
tidx_blks_read  | 0
tidx_blks_hit   | 0

I/O आउटपुट यह समझने में मदद करने के लिए उपयोगी है कि कवर के तहत डेटा को कैसे एक्सेस किया जा रहा है। कॉलम 'heap_blks_read' इस तालिका के लिए पढ़े गए डिस्क ब्लॉक की संख्या का प्रतिनिधित्व करता है, और 'heap_blks_hit' इस टेबल पर मेमोरी से पढ़े गए बफर ब्लॉक का प्रतिनिधित्व करता है। यह जानने में मददगार है कि क्या टेबल तक पहुंचने वाली क्वेरी को लगातार डिस्क पर जाना है, या मेमोरी से डेटा लाना है।

टेबल पर इंडेक्स आंकड़े 'idx_blks_read' और 'idx_blks_hit' कॉलम के साथ समान जानकारी दिखाते हैं।

अंत में, यदि तालिका में कोई TOAST तालिका है, तो 'toast_blks_hit' और 'toast_blks_read' कॉलम टोस्ट तालिकाओं को ट्रैक करते हैं, जबकि 'tdix_blks_read' और 'tdix_blks_read' उन टोस्ट तालिकाओं पर अनुक्रमणिका को ट्रैक करते हैं।

सूचकांक मेटाडेटा

pg_stat_user_indexes

severalnines=> SELECT * FROM pg_stat_user_indexes WHERE indexrelname = 'history_pkey';
-[ RECORD 1 ]-+-------------
relid         | 2766797
indexrelid    | 2766934
schemaname    | public
relname       | history
indexrelname  | history_pkey
idx_scan      | 43910
idx_tup_read  | 98147
idx_tup_fetch | 98147

तालिका समकक्षों की तरह, इस तालिका में विशेष रूप से अनुक्रमणिका के बारे में जानकारी है। प्रति अनुक्रमणिका एक पंक्ति, यह तालिका दिखाती है कि कितनी बार अनुक्रमणिका को 'idx_scan' कॉलम के साथ स्कैन किया गया था, कितने tuples को 'idx_tup_read' के साथ पढ़ा गया था, और कितनी लाइव पंक्तियों को वास्तव में 'idx_tup_fetch' के साथ प्राप्त किया गया था।

pg_statio_user_indexes

severalnines=> SELECT * FROM pg_statio_user_indexes WHERE indexrelname = 'history_pkey';
-[ RECORD 1 ]-+-------------
relid         | 2766797
indexrelid    | 2766934
schemaname    | public
relname       | history
indexrelname  | history_pkey
idx_blks_read | 2
idx_blks_hit  | 49380

pg_statio_user_indexes के लिए, डेटा के लिए उपलब्ध दो कॉलम 'idx_blks_read' और 'idx_blks_hit' हैं, जो डिस्क और मेमोरी से पढ़े गए ब्लॉकों की संख्या को दर्शाते हैं।

हम इस डेटा के साथ क्या कर सकते हैं?

रचनात्मक हो! यदि किसी विशिष्ट तालिका के लिए क्वेरीज़ बेहद धीमी लगती हैं, तो समय के साथ उसकी गतिविधि को ट्रैक करें, देखें कि उसे कितने अनुक्रमिक स्कैन मिलते हैं बनाम इंडेक्स स्कैन, देखें कि यह डिस्क पर जा रहा है या डेटा के लिए मेमोरी।

अगर एक बड़ी टेबल बार-बार ऑटोवैक्यूम होती रहती है, तो समय के साथ लाइव टू डेड टुपल्स को ट्रैक करें, हो सकता है कि इसे विशेष रूप से ऑटोवैक्यूम को ट्वीक करने की आवश्यकता हो, ताकि यह जल्दी से पूरा हो सके, या शायद टेबल विभाजन के लिए एक उम्मीदवार है।

चूंकि हम देख सकते हैं कि जब डेटा डिस्क या मेमोरी से आता है, तो हम समय के साथ मेमोरी का डिस्क से अनुपात बना सकते हैं, यह इंगित करते हुए कि क्या अनुपात दिन के दौरान किसी भी समय गिरता है।

हमारे द्वारा कवर की गई तालिकाओं की मात्रा बड़े हिटरों पर चली गई, मुख्य डेटा जो डेटाबेस के आंतरिक कामकाज के बारे में जानने के लिए उपयोगी है। हालांकि सिस्टम कैटलॉग में कई और टेबल हैं जिनमें स्थितिजन्य रूप से उपयोगी डेटा होता है। पहले की तरह अन्य तालिकाओं को पढ़ने से सामान्य रूप से डेटाबेस के स्वास्थ्य पर अंतर्दृष्टि प्रदान करने में मदद मिलेगी।

PostgreSQL कैटलॉग में किसी भी तालिका या दृश्य के बारे में अधिक जानकारी के लिए, यहाँ आधिकारिक दस्तावेज़ीकरण पर जाएँ, साथ ही यहाँ सांख्यिकी संग्राहक के बारे में जानकारी देखें।