3

私の推測では、日付にも世紀を使用しているため、そうすべきではないと思います

ここから、

DATE データ型には、年 (世紀を含む)、月、日、時、分、および秒 (午前 0 時以降) が格納されます。

問題に直面しましたか？

4

4 に答える 4

6

はい、Oracleは2000年問題の影響を受けました。Oracle 7より前は、データベースは世紀を保存していませんでした。下位互換性は、Oracle7データベースが日付のデフォルトのフォーマットマスクとしてDD-MON-YYを使用することを意味しました。また、そのマスクを使用して日付を作成すると、世紀のデフォルトは現在の世紀になります。これは、前世紀の日付または次の世紀の日付にまだ問題を残しています。厳密に言えば、これはストレージの問題ではなく、アプリケーションの問題です。

この回避策として、オラクルはRR要素を日付マスクに導入しました。日付マスクは日付ウィンドウに基づいて世紀を導き出します。これは表示を目的としています。もちろん、この回避策は現在組み込み機能になっており、それ自体があらゆる種類の問題を引き起こします。特に、アプリケーションがユーザーに1世紀を明示的に入力するのではなく、入力形式のマスクとして使用したためです。

とにかく、これがどのように機能するかです。

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では、Y2Kバグはストレージの問題ではなく、アプリケーションの問題であることを繰り返し述べます。14-OCT-09がバグを永続させているため、存在するすべてのアプリケーションでユーザーは日付を書き込むことができます。RRマスクがこの怠惰を助長する限り、事態は悪化しました。

于 2010-08-12T15:06:38.673 に答える
2

APC が述べたように、Oracle は V7 以降、完全な日時形式で日付を格納しており、ほとんどのクライアント アプリケーションは、明示的な -YY 形式のマスクの使用を 2K 期限の少し前に修正しました。

しかし、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 接続が OS 環境から継承されたセッション形式を -YY に設定し、データベースを上書きした場合に発生するエラーも見てきました。デフォルト。

これらはいずれも Oracle のソフトウェアの障害ではありません。システムとプログラミング言語で 2 桁の年が許可されている限り、「Y2K」問題は発生することを認識しておくだけの価値があります。

于 2010-08-12T17:51:06.163 に答える
1

おそらく少し話題から外れていますが...

私は、ロールオーバーナイト自体を含め、2000年問題の期間にわたってOracleサポートで働いていました。

オラクルのY2Kステートメントのコピーを要求する顧客が一晩中1回電話を受けました。少し遅いメチンク。:)

それ以外は、2000年問題に関する電話を受けたことを思い出さないでください。（ただし、RDBMSサーバーグループでは作業していなかったことに注意してください）

于 2010-08-12T15:06:57.890 に答える
1

はい、彼らがしたようです：

http://news.cnet.com/Oracle-offers-free-Y2K-upgrade/2100-1001_3-222123.html

ただし、彼らがあなたが言及しているものに正確に直面したかどうかはわかりません.

于 2010-08-12T14:28:27.927 に答える