Large-language-model (LLM) एजंट्सद्वारे तयार केलेले Oracle SQL स्क्रिप्ट्स कागदावर निर्दोष वाटू शकतात, परंतु प्रोडक्शनमध्ये (production) ते अपयशी ठरू शकतात. २.३ दशलक्ष ओळींच्या एका लेगसी कोडबेसमध्ये (legacy codebase), एक AI-चालित एजंट वारंवार असे आयडेंटिफायर्स (identifiers) वापरत असे जे अस्तित्वातच नव्हते – उदाहरणार्थ, वास्तविक STATUS_CD कॉलमऐवजी POLICY_STATUS वापरणे, किंवा CUSTOMER ऐवजी अस्तित्वात नसलेल्या CUSTOMERS टेबलचा संदर्भ देणे.

UPDATE किंवा DELETE स्टेटमेंटमधील चूक पकडण्यासाठी ते स्क्रिप्ट रन करणे हा पर्याय नाही. प्रोडक्शनसारख्या डेटासेटवर ते कार्यान्वित केल्यास लॉक्स (locks) लागतात, सिक्वेन्स नंबर्स (sequence numbers) खर्च होतात आणि परिणामी इतर समस्या (cascading side-effects) उद्भवू शकतात. डेव्हलपर्सना कोणताही डेटा स्पर्श न करता नावे आणि सिंटॅक्स (syntax) तपासण्याचा मार्ग हवा आहे. याचे उत्तर, आश्चर्यकारकपणे सोपे आहे, ते म्हणजे Oracle चे EXPLAIN PLAN कमांड – ज्याचा वापर 'लिंटिंग स्टेप' (linting step) म्हणून केला जाऊ शकतो.

EXPLAIN PLAN एक वेगवान व्हॅलिडेटर (validator) म्हणून कसे काम करते

जेव्हा Oracle ला एखादे स्टेटमेंट मिळते, तेव्हा ते प्रथम त्याचे पार्सिंग (parsing) करते. पार्सिंगमध्ये संदर्भित केलेले प्रत्येक टेबल, कॉलम आणि प्रिव्हिलेज (privilege) अस्तित्वात आहे की नाही हे तपासले जाते, त्यानंतर एक एक्झिक्यूशन प्लॅन (execution plan) तयार केला जातो आणि तो सिस्टम टेबलमध्ये लिहिला जातो. ही कमांड स्टेटमेंट कधीही रन करत नाही: कोणताही रो (row) बदलला जात नाही, कोणतेही ट्रिगर्स (triggers) फायर होत नाहीत आणि कोणतेही लॉक्स (locks) घेतले जात नाहीत. जर पार्सरला एखादी अज्ञात ऑब्जेक्ट आढळली, तर काही मिलीसेकंदातच तो एरर (error) देतो.

ही कार्यपद्धती EXPLAIN PLAN ला AI-जनरेटेड SQL साठी एक उत्तम 'प्री-फ्लाइट चेक' (pre-flight check) बनवते. एखादे टेबल किंवा कॉलम गहाळ असल्यास त्याची त्वरित सूचना मिळते, ज्यामुळे मानवी डोळ्यांना स्क्रिप्ट दिसण्यापूर्वीच जनरेशन लूपला ती चूक सुधारता येते.

मी माझ्या CI पाइपलाइनमध्ये (CI pipeline) सेट केलेली वर्कफ्लो (workflow)

  1. येणाऱ्या स्क्रिप्टचे वैयक्तिक स्टेटमेंटमध्ये विभाजन (Split) करा.
  2. डेव्हलपमेंट स्कीमावर (development schema) EXPLAIN PLAN FOR <statement> रन (Run) करा.
  3. Oracle कडून येणारे कोणतेही पार्सिंग एरर्स (parsing errors) गोळा (Collect) करा.
  4. त्रुटी सुधारण्यासाठी त्या पुन्हा LLM ला द्या (Feed).

प्रत्यक्ष व्यवहारात, एकवेळ पुन्हा प्रयत्न केल्यास (retry) बहुतांश नेमिंग एरर्स (naming errors) दूर होतात. AI योग्य स्कीमा शिकते आणि त्याचे आउटपुट आपोआप समायोजित करते. मी एजंटला 'रीड-ओन्ली मोड' (read-only mode) मध्ये देखील लॉक करतो: तो SELECT आणि EXPLAIN PLAN कॉल्स करू शकतो, परंतु DDL, DML आणि COMMIT ब्लॉक केलेले असतात. हे सँडबॉक्स (sandbox) हे सुनिश्चित करते की AI स्ट्रक्चर तपासत असताना डेटाबेस सुरक्षित राहील.

नावांच्या तपासणीव्यतिरिक्त, जनरेट केलेला प्लॅन कामगिरीतील (performance) स्पष्ट धोके देखील दर्शवतो. जर एखाद्या स्टेटमेंटमुळे मोठ्या टेबलवर 'फुल-टेबल स्कॅन' (full-table scan) होणार असेल, तर कोणताही डेटा बदलण्यापूर्वीच प्लॅन ते दर्शवतो, ज्यामुळे डेव्हलपर्सना इंडेक्स (indexes) सुचवण्याची किंवा प्रेडिकेट (predicate) पुन्हा लिहिण्याची संधी मिळते.

या दृष्टिकोनाच्या मर्यादा

  • लॉजिकल अचूकता (Logical correctness) तपासली जात नाही. योग्य कॉलमचा संदर्भ देणारे परंतु चुकीचे फिल्टर वापरणारे स्टेटमेंट देखील लिंटमध्ये पास होऊ शकते.
  • PL/SQL ब्लॉक्सच्या मर्यादेबाहेर आहे. पार्सर फक्त वैयक्तिक SQL स्टेटमेंट हाताळतो; प्रोसिजरल कोडसाठी वेगळ्या व्हॅलिडेशन मार्गाची आवश्यकता असते.
  • डेटा-लेव्हल व्हॅलिडेशनचा अभाव आहे. एखादे लिटरल व्हॅल्यू (literal value) कॉलमच्या डोमेनशी सुसंगत आहे की नाही किंवा फॉरेन-की (foreign-key) रेफरन्स खरोखर अस्तित्वात आहे की नाही, हे लिंट सांगू शकत नाही.
  • केवळ डेव्हलपमेंट स्कीमा. जे एरर्स फक्त प्रोडक्शनमध्ये दिसतात – उदाहरणार्थ, एखादे टेबल जे डेव्हपमध्ये अस्तित्वात आहे परंतु प्रोडक्शनमध्ये त्याचे नाव बदलले आहे – ते नंतरपर्यंत दिसत नाहीत.

या त्रुटी या पद्धतीचे महत्त्व कमी करत नाहीत; त्या केवळ त्याची व्याप्ती निश्चित करतात. बहुतेक LLM-जनरेटेड DML स्क्रिप्ट्समध्ये, सर्वात सामान्य त्रुटी म्हणजे टायपो (typo) किंवा चुकीचे ऑब्जेक्ट नाव, आणि EXPLAIN PLAN नेमके तेच पकडते.

इतर डेटाबेस इंजिन्ससाठी पोर्टेबिलिटी (Portability)

हेच तत्त्व Oracle च्या पलीकडे देखील लागू होते. PostgreSQL चे PREPARE स्टेटमेंट किंवा EXPLAIN एक्झिक्यूशनशिवाय क्वेरी पार्स करू शकते. SQL Server SET PARSEONLY ON ऑफर करते, जे प्रत्यक्ष प्रोसेसिंग वगळून सिंटॅक्स आणि ऑब्जेक्टची नावे तपासण्यास इंजिनला भाग पाडते. कोणताही RDBMS जो पार्सिंग आणि एक्झिक्यूशन वेगळे करतो, तो एक हलका (lightweight) लिंटिंग गेट बनू शकतो.

निष्कर्ष (Takeaway)

प्रत्येक AI-जनरेटेड SQL स्टेटमेंटवर EXPLAIN PLAN (किंवा त्याच्या समकक्ष) चालवल्यामुळे डेटाबेस पार्सरचे रूपांतर एका स्वस्त आणि शून्य-धोका असलेल्या लिंटिंग गेटमध्ये होते. कोणताही डेटा बदलण्यापूर्वीच ते सर्वात वारंवार होणाऱ्या नेमिंग आणि सिंटॅक्स एरर्स पकडते, ज्यामुळे लेगसी सिस्टम्स स्थिर राहतात आणि डेव्हलपर्सना LLM-असिस्टेड कोडिंगचा उत्पादकता वाढवण्याचा फायदा मिळतो.