it-swarm.asia

Oracle - هل هناك طريقة لعرض التغييرات غير الملتزم بها على جدول معين؟

أنا أقوم بالتصحيح من خلال عملية مجمعة حاليًا تقوم بالكثير من عبارات DML ، ولكنها لا تقوم بالتنفيذ على الفور. سيكون من الجميل أن تكون قادرًا على عرض التغييرات "المعلقة" من جلسة أخرى بينما لا يتم الالتزام بالمعاملة. هل هذا ممكن؟

مثال:

Insert into table myTable (col1, col2) values ("col1", "col2");

--Somehow view the pending transaction maybe by system view?....

...other DML statements....

commit;
24
contactmatt

هناك عدد قليل من الطرق المختلفة اعتمادًا على تفاصيل عملية الدُفعة الخاصة بك ولماذا تحاول عرض التغييرات غير الملتزم بها.

1) Oracle Workspace Manager هي أداة تم تصميمها في الأصل للسماح للأشخاص الذين يطورون التطبيقات المكانية بالحصول على ما يعادل المعاملات طويلة المدى للغاية (أي المعاملات التي قد تتطلب أيامًا أو أسابيع عديدة من البشر لمعرفة أين لتشغيل خط الأنابيب في معاملة واحدة). يمكن أن تؤدي عملية الدُفعات الخاصة بك إلى إنشاء مساحة عمل جديدة (والتي تشبه منطقياً إنشاء معاملة جديدة) ، وإجراء أي تغييرات قد ترغب فيها في مساحة العمل هذه أثناء الالتزام متى شئت. في جلسة منفصلة ، لن ترى أيًا من التغييرات التي تم الالتزام بها حتى تدخل مساحة عمل العملية الدفعية. عند انتهاء عملية الدُفعة ، يمكن أن تدمج مساحة العمل الخاصة بها مرة أخرى في مساحة العمل المباشرة التي تعادل تنفيذ المعاملة.

2) DBMS_XA package يمكن استخدامها للسماح لك "بتسليم" معاملة من جلسة إلى أخرى وللسماح لجلسة واحدة بالاتصال بمعاملة بدأت بجلسة أخرى. هذه حزمة غامضة جدًا لاستخدامها ، ولكن كان هناك مثال جميل لاستخدامها في PL/SQL Challenge (قد تحتاج إلى حساب مجاني للوصول إليها) مؤخرًا.

3) إذا كنت تحاول فقط رؤية حالة عملية الدُفعات بدلاً من رؤية البيانات الفعلية ، فيمكن لعملية الدُفعات كتابة معلومات تسجيل باستخدام المعاملات المستقلة التي يمكنك بعد ذلك الاستعلام عنها من جلسة أخرى. أو يمكنك استخدام حزمة DBMS_APPLICATION_INFO لجعل تطبيقك يقوم بتحديث السمات المختلفة في V $ SESSION و/أو V $ SESSION_LONGOPS حتى تتمكن من مراقبة حالة التحميل من جلسة أخرى.

18
Justin Cave

تحرير: كتب هذا قبل توضيح السؤال

يمكنك استخدام استعلامات الفلاش باك لرؤية الجدول دون الخاصة بيانات غير ملتزم بها.

يعتبر:

SQL> CREATE TABLE my_table
  2  AS SELECT ROWNUM ID FROM dual CONNECT BY LEVEL <= 5;

Table created

SQL> INSERT INTO my_table VALUES (6);

1 row inserted

لمعرفة الفرق بين الجدول مع معاملتي والجدول كما يراه الآخرون يمكنني إصداره:

SQL> SELECT * FROM my_table
  2  MINUS
  3  SELECT * FROM my_table AS OF TIMESTAMP (systimestamp);

        ID
----------
         6
10
Vincent Malgrat

ما Oracle ليس لديه هو وضع عزل قراءة غير ملتزم بها . بمعنى آخر ، لن تتمكن من الاستعلام عن البيانات غير الملتزم بها في معاملة أخرى.

هناك طرق للحصول على المعلومات من معاملة طويلة الأمد - واحدة لم يتم ذكرها حتى الآن هي المعاملات المستقلة (والتي يجب استخدامها بحذر)

8
Jack says try topanswers.xyz

نعم - LogMiner يمكنه القيام بذلك. في الواقع ، إذا كنت تريد فقط المعاملات الملتزم بها ، فعليك على وجه التحديد التصفية الإخراج! وهناك TABLE_NAME في V$LOGMINER_CONTENTS ، هكذا ستبدو على طاولة واحدة.

8
Gaius

لا توجد طريقة مباشرة. سيتعين عليك إما تحليل السجلات (كما هو مذكور في إجابة أخرى) ، أو استخدام طرق بديلة لمعرفة ما يحدث في عملية طويلة الأمد.

أنا شخصياً أقترح استخدام المعاملات المستقلة لتمكين هذه الميزة - ليس على المعاملة نفسها ، ولكن كآلية تسجيل تتيح لك معرفة ما يجري. على سبيل المثال ، يمكن أن يكون لديك استدعاء PROCEDURE LONG_ACTION PROCEDURE WRITE_LOG_ENTRY (يُعرف على أنه معاملة مستقلة) يمكن أن يكتب VARCHAR2 إلى جدول آخر. لا تتداخل المعاملات المستقلة مع معاملتك الحالية (من منظور منطقي ؛ احذر من التأثيرات المحتملة على الأداء) وبذلك يمكنك مشاهدة ما يحدث عبر إدخالات التسجيل بغض النظر عن الالتزام أو ROLLBACK في معاملتك الحالية. ومع ذلك ، يمكنك القيام بذلك باستخدام عبارة DML واحدة ضخمة ؛ عليك استخدام حلقة.

يعتبر:

TABLE LOG_ENTRIES defined as
    activity_date  date,
    log_entry varchar2(2000)

TABLE BIG_JOB (definition doesn't really matter)

PROCEDURE WRITE_LOG_ENTRY
                        ( str VARCHAR2 )
IS
    PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
    INSERT INTO LOG_ENTRIES VALUES ( SYSDATE, str );
    COMMIT;
END;

PROCEDURE LONG_ACTION IS
    c NUMBER;
BEGIN
    FOR r IN ( SELECT * FROM BIG_JOB )
    LOOP
       c := c + 1;
       UPDATE BIG_JOB z
          SET fld = hairy_calculation
        WHERE z.rowid = r.rowid;
       IF MOD(c,500) = 0 THEN
           WRITE_LOG_ENTRY ( c || ' rows processed.' );
       END IF;
    END LOOP;
    COMMIT;
END;

بالنظر إلى ما سبق ، ستحصل على إدخال سجل لكل 500 صف تتم معالجتها بغض النظر عن نجاح الإجراء الطويل. إذا كنت بحاجة إلى نسخة طبق الأصل من البيانات لترى أنها تعمل ، أقترح إنشاء جدول مكرر واستدعاء إجراء من شأنه تكرار البيانات (الإجراء هو معاملة مستقلة). ثم قم بتدمير البيانات بعد وقوعها. (لا حاجة للازدواجية.)

علاوة على ذلك ، إذا كان هذا لغرض التصحيح ، فإنني أقترح إزالة أو تقليل الحاجة إلى مثل هذا التسجيل عندما يتم اختبار الأشياء. وكالعادة ، اختبر واختبر واختبر على نظامك الخاص للتحقق من كيفية عمل الأشياء. (راجع التعليق من Niall للحصول على مثال جيد لكيفية تأثير التسجيل بشكل كبير على الأداء.)

(أخيرًا ، لأنني أهملت ذكره من قبل: احذر من المعاملات المستقلة. افهمها تمامًا قبل التنفيذ ، ولا تستخدمها "لمجرد". يمكن استخدامها بملايين الطرق بشكل غير صحيح (على سبيل المثال ، لمحاولة تجنب حدوث خطأ تحويلي في المشغل) ، لذا من الأفضل دائمًا العثور على بدائل ، إن أمكن. إذا لم تتمكن من ذلك ، فتابع بحذر. كان تسجيل الدخول أثناء عمليات التشغيل الطويلة حالة دائمًا حيث يكون آمنًا إلى حد ما (تجاهل مشاكل الأداء) ، ولكن لا تتسرع في تطبيقه على استخدامات أخرى دون معرفة العواقب.)

5
Kerri Shotts

غير متاح في 10 جرام ، ولكن DBMS_XA يمكن أن يسمح للمعاملة بعبور جلسات متعددة. باستخدام ذلك يمكن للجلسة الثانية رؤية ما يحدث في المعاملة

3
Gary

بالإضافة إلى المعلومات الأخرى هنا ، فإن بعض الطرق الإضافية لإرسال معلومات حول معاملة غير ملتزمة هي إرسال بريد إلكتروني أو الكتابة إلى ملف نصي.

3
Leigh Riffel