PostgreSQL डेटाबेस आकार (टेबल-स्पेस आकार) बहुत बड़ा तो संबंधों

Question

Hallo सब की गणना की कुल राशि,

मैं (HDD पर और pg_database_size() कॉल द्वारा प्रदर्शित) वास्तविक डेटाबेस आकार के बीच एक बहुत बड़ा अंतर देख सकते हैं और आकार, pg_total_relation_size() द्वारा पुनर्प्राप्त कुल संबंध आकारों को संक्षेप में गणना करके गणना की गई।

पहले 62 ग्रा है और पिछले 16 जी (सबसे बड़ी मेज से हटाए गए डेटा का सही अंतर)

यहाँ, एक सरल प्रश्न है कि अपने सिस्टम पर वह अंतर कर सकते हैं:

select current_database(), 
     pg_size_pretty(sum(total_relation_raw_size)::bigint) as calculated_database_size, 
     pg_size_pretty(pg_database_size(current_database())) as database_size 
    from (select pg_total_relation_size(relid) as total_relation_raw_size 
      from pg_stat_all_tables -- this includes also system tables shared between databases 
     where schemaname != 'pg_toast' 
     ) as stats; 

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

पुनश्च: मुझे लगता है, कि यह किसी प्रकार का एक डेटाबेस भ्रष्टाचार था ... इस स्थिति से उबरने के लिए एक ही रास्ता गर्म स्टैंडबाय डेटाबेस के लिए स्विच करने के लिए ...

Answer 1

आप अप्रयुक्त LOBs है था ?

आप कुछ इस तरह है: डेटाबेस में

\lo_import '/tmp/bigfile' 
11357 
INSERT INTO bigobjects VALUES (1, 'bigfile', 11357); 
TRUNCATE TABLE bigobjects; 

तुम अब भी LOB होगा (आईडी 11357):

CREATE TABLE bigobjects (
    id BIGINT NOT NULL PRIMARY KEY, 
    filename VARCHAR(255) NOT NULL, 
    filecontents OID NOT NULL 
); 

द्वारा पीछा किया।

आप अपने डेटाबेस में सभी बड़ी वस्तुओं के लिए pg_catalog.pg_largeobject प्रणाली सूची तालिका जाँच कर सकते हैं (pg_catalog.pg_largeobject से अलग loid का चयन करें जब तक आप अष्टाधारी के रूप में अपने सभी LOB डेटा देखना चाहते हैं सलाह देते हैं।)

आप तो अपने सभी अप्रयुक्त LOB को साफ़ करें और एक वैक्यूम पूर्ण करें, आपको भंडारण में भारी कमी दिखाई देनी चाहिए। मैंने बस इसे एक निजी देव डेटाबेस पर प्रयोग किया है जिसका उपयोग मैंने किया है और 200 एमबी से 10 एमबी तक आकार में कमी देखी है (जैसा कि pg_database_size (current_database()) द्वारा रिपोर्ट किया गया है।)

Answer 2

आपकी क्वेरी विशेष रूप से pg_toast टेबल को स्क्रीनिंग कर रही है, जो बड़ा हो सकता है। देखें कि उस से छुटकारा पाने के लिए schemaname != 'pg_toast' आपको अधिक सटीक उत्तर प्राप्त करता है।

Answer 3

जैसा कि हम स्थिति में प्रकट हुए और उस डीबी से अप्रयुक्त डेटा के बहुत से खाली होने के बाद, इस स्थिति में दिखाई दिया।

मुझे इसी तरह का अनुभव था: 3 जीबी डीबी बहुत गतिशील डेटा के साथ जो एक महीने या उससे भी अधिक के लिए 20 जीबी तक चला गया। मैन्युअल हटाने/सफाई समस्याग्रस्त टेबल प्रभाव .. के लिए seamed नहीं करता है और फिर हम सिर्फ पूरे डीबी पर एक अंतिम

VACUUM FULL ANALYZE 

किया था ... और यह आधे आकार गिरा दिया।

इसमें 4 घंटे लग गए, इसलिए इससे सावधान रहें।

Answer 4

LOB एक बहुत ही वैध चिंता है क्योंकि बॉब लिखते हैं, क्योंकि जब आपकी एप्लिकेशन तालिका (ओआईडी युक्त) की पंक्तियां हटा दी जाती हैं तो उन्हें हटाया नहीं जाता है।

ये स्वचालित रूप से VACUUM प्रक्रिया द्वारा हटाए नहीं जाएंगे, केवल आप ही VACUUMLO चला चुके हैं।

वैक्यूमलो डेटाबेस से सभी अपरिवर्तित LOB को हटा देगा।

उदाहरण कॉल:

vacuumlo -U postgres -W -v <database_name> 

(मैं केवल -v अधिक वर्बोज़ थोड़ा vacuumlo बनाने के लिए इतना है कि आप देखें कि यह कैसे कई LOBs को हटा शामिल) vacuumlo LOBs, आप नष्ट कर दिया गया है के बाद वैक्यूम पूर्ण चला सकते हैं (या ऑटो-वैक्यूम प्रक्रिया को चलाने दें)।