هل واجهت أوراكل مشكلة Y2K؟ [مغلق

Question

أظن أنه لا يوجد لديه لأنهم يستخدمون قرون أيضًا في التواريخ

من هنا,

نوع DATATINGE DATE المتاجر في السنة (بما في ذلك القرن), ، الشهر ، اليوم ، الساعات ، الدقائق ، والثواني (بعد منتصف الليل).

هل وجهت المشكلة?

Answer 1

نعم ، تأثرت أوراكل بحشرة Y2K. قبل Oracle 7 ، لم تخزن قاعدة البيانات القرن. التوافق المتخلف يعني أن قاعدة بيانات Oracle 7 استخدمت DD-MON-YY كقناع تنسيق افتراضي للتواريخ. وإذا قمت بإنشاء تاريخ باستخدام هذا القناع الافتراضيات القرن إلى القرن الحالي. الذي لا يزال يترك مشاكل مع تواريخ من القرن السابق الآن أو يعود إلى القرن المقبل بعد ذلك. بالمعنى الدقيق للكلمة ، هذه مشكلة تطبيق بدلاً من مشكلة تخزين.

كعمل حول هذا Oracle قدم عنصر RR إلى قناع التاريخ ، الذي يستمد قرن على أساس نافذة التاريخ. كان هذا مخصص لأغراض العرض. بطبيعة الحال ، أصبح هذا الحل المتكلس ميزة مضمنة الآن ، ويؤدي إلى جميع أنواع المشاكل الخاصة بها. ليس أقلها لأن التطبيقات استخدمتها كقناع تنسيق إدخال بدلاً من مطالبة المستخدمين بدخول قرن بشكل صريح.

على أي حال ، ها هو كيف يعمل.

SQL> insert into t72 values (1, to_date('12-MAY-32', 'DD-MON-YY'))
  2  /

1 row created.

SQL> insert into t72 values (2, to_date('12-MAY-99', 'DD-MON-YY'))
  2  /

1 row created.

SQL> insert into t72 values (3, to_date('12-MAY-50', 'DD-MON-YY'))
  2  /

1 row created.

SQL> insert into t72 values (11, to_date('12-MAY-32', 'DD-MON-RR'))
  2  /

1 row created.

SQL> insert into t72 values (12, to_date('12-MAY-99', 'DD-MON-RR'))
  2  /

1 row created.

SQL> insert into t72 values (13, to_date('12-MAY-50', 'DD-MON-RR'))
  2  /

1 row created.

SQL> insert into t72 values (14, to_date('12-MAY-49', 'DD-MON-RR'))
  2  /

1 row created.

SQL>

محتويات الجدول:

SQL> alter session set nls_date_format = 'DD-MON-YYYY'
  2  /

Session altered.

SQL> select * from t72
  2  /

        ID D
---------- -----------
         1 12-MAY-2032
         2 12-MAY-2099
         3 12-MAY-2050
        11 12-MAY-2032
        12 12-MAY-1999
        13 12-MAY-1950
        14 12-MAY-2049

7 rows selected.

SQL>

يتم تعيين السنوات 1-49 19 و 0 ، 50-99 يتم إعطاء 20.

---

يتحمل تكرار أنه في Oracle ، تعتبر Bug Y2K مشكلة في التطبيق وليس تخزينًا. سيظل كل تطبيق موجود للمستخدمين كتابة تواريخ حيث أن 14 Oct-09 يديم الخطأ. إلى الحد الذي يشجع فيه قناع RR هذا الكسل الذي جعل الأمور أسوأ.

Answer 2

كما قال APC ، قامت Oracle بتخزين التواريخ بتنسيق كامل للتاريخ منذ V7 ، كما قامت معظم تطبيقات العميل بتصحيح أي استخدام لأقنعة تنسيق صريحة -بعض الوقت قبل الموعد النهائي.

ومع ذلك ، فقد رأيت حشرات تحدث منذ 2K حيث تراجع الأشخاص إلى أقنعة إعادة استخدام -yy ، وعدم ملاحظة الاختبار لأن جميع بيانات الاختبار الخاصة بهم هي بعد y2k -خاصة عند القيام بالمعالجة/السلسلة/التاريخ -وهو مصطنع مثال :

TO_DATE(TO_CHAR(a_date_column,'DD-MM-YY')||'12:00','DD-MM-YYHH24:MI')

هذا النوع من المنطق شائع جدًا إذا كنت تتعامل مع نظام قديم يخزن التاريخ والوقت كأعمدة قاعدة بيانات منفصلة. قد يكون بناء الجملة Oracle محددًا ، لكن المشكلة هي حقًا إحدى البرمجة العامة.

حيث رأيت المشكلات التي تتعلق أكثر بـ Oracle كانت حول إعدادات تاريخ NLS. لقد رأيت DBA تقوم بإعادة بناء قاعدة بيانات ولكنني أعيد التنسيق الافتراضي إلى -yy ، ورأيت أيضًا أخطاء تسببت في وضع اتصال JDBC لتنسيق الجلسة إلى -yy ، ورثت من بيئة نظام التشغيل ، والتجاوز قاعدة البيانات إفتراضي.

لم يكن أي من هذه الأخطاء مع برامج Oracle ، فمن المفيد أن ندرك أن مشكلات "Y2K" ستكون موجودة طالما أن الأنظمة ولغات البرمجة تسمح بسنوات من رقمين.

Answer 3

نعم يبدو أنهم فعلوا:

http://news.cnet.com/oracle-spreed-free-y2kprade/2100-1001_3-222123.html

لست متأكدًا مما إذا كانوا يواجهون بالضبط الذي تشير إليه.

Answer 4

ربما خارج الموضوع قليلاً ، ولكن ....

كنت أعمل لدعم Oracle خلال فترة Y2K ، بما في ذلك ليلة الرول نفسها.

تلقينا مكالمة واحدة طوال الليل - عميل يطلب نسخة من بيان Oracle Y2K. ميثينك المتأخر قليلا. قون

بخلاف ذلك ، لا تتذكر تلقي أي مكالمات على مشاكل Y2K. (لاحظ أنني لم أعمل في مجموعة خادم RDBMS)