अस्थायी टेबल प्रभावी रूप से कैशिंग और एसिंक्रोनस I/O के लिए इन-मेमोरी टेबल के समान होते हैं, और अस्थायी तालिका समाधान को SQL और PL/SQL के बीच कनवर्ट करने के लिए किसी ओवरहेड की आवश्यकता नहीं होती है।
परिणामों की पुष्टि
रनस्टैट्स के साथ दो संस्करणों की तुलना करने पर, अस्थायी तालिका संस्करण दिखता है बहुत खराब। रन1 में अस्थायी तालिका संस्करण के लिए वह सब जंक, और रन 2 में पीएल/एसक्यूएल संस्करण के लिए केवल थोड़ी अतिरिक्त मेमोरी। सबसे पहले ऐसा लगता है कि पीएल/एसक्यूएल स्पष्ट विजेता होना चाहिए।
Type Name Run1 (temp) Run2 (PLSQL) Diff
----- -------------------------------- ------------ ------------ ------------
...
STAT physical read bytes 81,920 0 -81,920
STAT physical read total bytes 81,920 0 -81,920
LATCH cache buffers chains 104,663 462 -104,201
STAT session uga memory 445,488 681,016 235,528
STAT KTFB alloc space (block) 2,097,152 0 -2,097,152
STAT undo change vector size 2,350,188 0 -2,350,188
STAT redo size 2,804,516 0 -2,804,516
STAT temp space allocated (bytes) 12,582,912 0 -12,582,912
STAT table scan rows gotten 15,499,845 0 -15,499,845
STAT session pga memory 196,608 19,857,408 19,660,800
STAT logical read bytes from cache 299,958,272 0 -299,958,272
लेकिन दिन के अंत में केवल दीवार घड़ी का समय मायने रखता है। अस्थायी तालिकाओं के साथ लोडिंग और क्वेरी करने के चरण दोनों बहुत तेज़ी से चलते हैं।
PL/SQL संस्करण को बल्क कलेक्ट . के स्थान पर सुधारा जा सकता है साथ में . लेकिन यह अभी भी अस्थायी तालिका संस्करण की तुलना में काफी धीमा है।
अनुकूलित पठन
छोटी अस्थायी तालिका से पढ़ना केवल बफर कैश का उपयोग करता है, जो स्मृति में है। केवल क्वेरी भाग को कई बार चलाएँ, और देखें कि कैश से संगत कैसे प्राप्त होता है (स्मृति) बढ़ जाती है जबकि भौतिक कैशे पढ़ता है (डिस्क) वही रहें।
select name, value
from v$sysstat
where name in ('db block gets from cache', 'consistent gets from cache',
'physical reads cache');
अनुकूलित लेखन
आदर्श रूप से कोई भौतिक I/O नहीं होगा, खासकर जब से अस्थायी तालिका ON COMMIT DELETE ROWS है . और ऐसा लगता है कि Oracle का अगला संस्करण इस तरह के तंत्र को पेश कर सकता है। लेकिन यह इस मामले में ज्यादा मायने नहीं रखता, डिस्क I/O चीजों को धीमा नहीं करता है।
लोड चरण को कई बार चलाएँ, और फिर select * from v$active_session_history क्रम से sample_time desc; चलाएँ . अधिकांश I/O पृष्ठभूमि है , जिसका अर्थ है कि कुछ भी इस पर प्रतीक्षा नहीं कर रहा है। मुझे लगता है कि अस्थायी तालिका आंतरिक तर्क नियमित डीएमएल तंत्र की एक प्रति है। सामान्य तौर पर, नया तालिका डेटा हो सकता है डिस्क पर लिखा जाना चाहिए, अगर यह प्रतिबद्ध है। ओरेकल इस पर काम करना शुरू कर सकता है, उदाहरण के लिए लॉग बफर से डिस्क पर डेटा ले जाकर, लेकिन वास्तविक COMMIT होने तक कोई जल्दी नहीं है। .
पीएल/एसक्यूएल समय कहां जाता है?
मेरे पास कोई सुराग नहीं है। क्या SQL और PL/SQL इंजन के बीच एकाधिक संदर्भ स्विच, या एकल रूपांतरण हैं? जहां तक मुझे पता है कोई भी उपलब्ध मीट्रिक समय . नहीं दिखाता है SQL और PL/SQL के बीच स्विच करने पर खर्च किया गया।
हम शायद कभी नहीं जान पाएंगे कि पीएल/एसक्यूएल कोड धीमा क्यों है। मैं इसकी ज्यादा चिंता नहीं करता। सामान्य उत्तर यह है कि, डेटाबेस का अधिकांश काम वैसे भी SQL में किया जाना है। यह बहुत मायने रखता है अगर Oracle अपने डेटाबेस के मूल, SQL को एड-ऑन भाषा, PL/SQL की तुलना में अनुकूलित करने में अधिक समय व्यतीत करता है।
अतिरिक्त नोट
प्रदर्शन परीक्षण के लिए इससे कनेक्ट करें . को हटाना सहायक हो सकता है एक अलग कदम में तर्क। डेटा लोड करने के लिए SQL एक बेहतरीन ट्रिक है, लेकिन यह बहुत धीमी और संसाधन गहन हो सकती है। उस ट्रिक के साथ एक बार नमूना तालिका लोड करना और फिर उस तालिका से सम्मिलित करना अधिक यथार्थवादी है।
मैंने नई Oracle 12c सुविधा, अस्थायी पूर्ववत, और नई 18c सुविधा, निजी अस्थायी तालिकाओं का उपयोग करने का प्रयास किया। नियमित अस्थायी तालिकाओं की तुलना में किसी ने भी प्रदर्शन में सुधार नहीं किया।
मैं इस पर दांव नहीं लगाऊंगा, लेकिन मैं एक तरीका देख सकता हूं कि जैसे-जैसे डेटा बड़ा होता जाएगा, परिणाम पूरी तरह से बदल जाएंगे। लॉग बफ़र और बफ़र कैश केवल इतना बड़ा हो सकता है। और अंततः वह पृष्ठभूमि I/O जोड़ सकता है और कुछ प्रक्रियाओं को प्रभावित कर सकता है, पृष्ठभूमि को चालू कर सकता है एक फोरग्राउंड में प्रतीक्षा करें रुको। दूसरी तरफ, पीएल/एसक्यूएल समाधान के लिए केवल इतनी पीजीए मेमोरी है, और फिर चीजें दुर्घटनाग्रस्त हो जाती हैं।
अंत में, यह आंशिक रूप से "इन-मेमोरी डेटाबेस" के मेरे संदेह की पुष्टि करता है। कैशिंग कोई नई बात नहीं है, डेटाबेस दशकों से ऐसा कर रहे हैं।
