ओरेकल: स्कीमा के भीतर अंतिम अद्यतन (किसी भी तालिका) का टाइमस्टैम्प कैसे ढूंढें?

Question

एक ओरेकल डेटाबेस स्कीमा है (डेटा में बहुत छोटा है, लेकिन अभी भी लगभग 10-15 टेबल)। इसमें एक प्रकार की कॉन्फ़िगरेशन (रूटिंग टेबल) शामिल है।

एक ऐसा एप्लिकेशन है जिसे समय-समय पर इस स्कीमा को मतदान करना होता है। अधिसूचनाओं का उपयोग नहीं किया जाना चाहिए।

यदि स्कीमा में कोई डेटा अपडेट नहीं किया गया था, तो एप्लिकेशन को अपने वर्तमान इन-मेमोरी संस्करण का उपयोग करना चाहिए।

यदि किसी भी तालिका में कोई अपडेट था, तो एप्लिकेशन को सभी तालिकाओं को स्मृति में पुनः लोड करना चाहिए।

किसी दिए गए कुंजी बिंदु (समय या लेनदेन आईडी) के बाद से अद्यतन के लिए संपूर्ण स्कीमा को जांचने का सबसे प्रभावी तरीका क्या होगा?

मुझे कल्पना है कि ओरेकल प्रति स्कीमा लेनदेन आईडी रखता है। फिर ऐसी आईडी पूछने का एक तरीका होना चाहिए और इसे अगले चुनाव में तुलना करने के लिए रखना चाहिए।

मैं इस सवाल है, जहां इस तरह के एक छद्म स्तंभ एक पंक्ति स्तर पर मौजूद है मिल गया है:

How to find out when an Oracle table was updated the last time

मैं कुछ इसी तरह एक स्कीमा स्तर पर मौजूद है लगता होगा।

क्या कोई मुझे सही दिशा में इंगित कर सकता है?

Answer 1

मुझे ओरेकल में ऐसी किसी भी कार्यक्षमता से अवगत नहीं है। नीचे देखें।

सबसे अच्छा समाधान मैं आपके साथ आने वाली सबसे अच्छी समाधान है जो एक-पंक्ति तालिका या context को वर्तमान दिनांक/समय के साथ अपडेट करता है। इस तरह के ट्रिगर्स टेबल-लेवल (पंक्ति-स्तर के विपरीत) पर हो सकते हैं, इसलिए वे अधिकतर ट्रिगर्स के रूप में ज्यादा ओवरहेड नहीं ले पाएंगे।

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

यह पता चला है कि, यदि आपके पास 10 जी है, तो आप इस जानकारी को प्राप्त करने के लिए ओरेकल की फ्लैशबैक कार्यक्षमता का उपयोग कर सकते हैं। हालांकि, अगर आप फ्लैशबैक सक्षम करने के लिए (जो अपने आप में से कुछ भूमि के ऊपर किया जाता है) और क्वेरी हास्यास्पद धीमी है (संभवतः क्योंकि यह वास्तव में यह उपयोग के लिए नहीं है) आवश्यकता होगी:

select max(commit_timestamp) 
from FLASHBACK_TRANSACTION_QUERY 
where table_owner = 'YOUR_SCHEMA' 
     and operation in ('INSERT','UPDATE','DELETE','MERGE') 

---

आदेश में से बचने के लिए

create or replace procedure log_last_update as 
pragma autonomous_transaction; 
begin 
    update last_update set update_date = greatest(sysdate,update_date); 
    commit; 
end log_last_update; 

यह कुछ हद तक क्रमानुसार करने के लिए अपने आवेदन का कारण होगा: "अंतिम अपडेट" तालिका में मुद्दों पर ताला लगा, तो आप शायद एक प्रक्रिया है जो इस तरह के रूप एक स्वायत्त लेन-देन, का उपयोग करता है कि अद्यतन डाल करना चाहते हैं प्रत्येक इस प्रक्रिया को कॉल करने की आवश्यकता वाले बयान को पीआर तक इंतजार करना होगा एक खत्म हो गया। "आखिरी अपडेटेड" तालिका सिंक से भी बाहर हो सकती है, क्योंकि उस पर अपडेट तब भी जारी रहेगा जब ट्रिगर को सक्रिय करने वाला अद्यतन वापस लुढ़का जाए। अंत में, यदि आपके पास विशेष रूप से लंबा लेनदेन है, तो लेनदेन पूरा होने से पहले एप्लिकेशन को नई तिथि/समय चुन सकता है, उद्देश्य को हराया जा सकता है। जितना अधिक मैं इस बारे में सोचता हूं, उतना ही यह एक बुरा विचार जैसा लगता है।

---

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

Answer 2

dbms_stats.gather_table_stats भी मदद कर सकता है: http://forums.oracle.com/forums/thread.jspa?threadID=607610

4. Statistics is considered to be stale, when the change is over 10% of current rows. 
    (As of 11g, this value can be customized per objects. Cool feature) 


    . 
    . 
    . 

exec dbms_stats.gather_table_stats(user, 'T_STAT'); 

select * from sys.dba_tab_modifications where table_name = 'T_STAT'; 
No row selected 

select stale_stats from sys.dba_tab_statistics where table_name = 'T_STAT'; 
NO 

insert into t_stat select rownum from all_objects where rownum <= 20; 

select * from sys.dba_tab_modifications where table_name = 'T_STAT'; 
No rows selected <-- Oops 
select stale_stats from sys.dba_tab_statistics where table_name = 'T_STAT'; 
NO <-- Oops 

exec dbms_stats.flush_database_monitoring_info; 

select * from sys.dba_tab_modifications where table_name = 'T_STAT'; 
TABLE_OWNER TABLE_NAME PARTITION_NAME SUBPARTITION_NAME INSERTS UPDATES DELETES TIMESTAMP TRUNCATED DROP_SEGMENTS 
UKJA  T_STAT  20 0 0 2008-01-18 PM 11:30:19 NO 0 

select stale_stats from sys.dba_tab_statistics where table_name = 'T_STAT'; 
YES