오라클은 Y2K 문제에 직면 했습니까?

Question

내 생각 엔 그들이 날짜

here에서

도 세기를 사용하기 때문에이, 월, 일 (세기 포함)

날짜 데이터 타입 저장 년이 shouln't이다 ,시, 분, 초 (자정 이후).

얼굴이 the problem입니까? 그들이했던 것처럼

Answer 1

예, Oracle은 Y2K 버그의 영향을받습니다. 오라클 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

---

부여되는 오라클에 Y2K 버그는 저장소 문제가 아니라 응용 프로그램 문제입니다. 14-OCT-09가 버그를 영속화하면서 존재하는 모든 응용 프로그램은 여전히 ​​사용자가 날짜를 쓸 수있게합니다. RR 마스크가이 게으름을 조장하는 정도까지 상황이 악화되었습니다.

Answer 2

예 그것은 본다 : 그들은 당신이 생각 언급하는 정확한 하나를 직면

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

확실하지합니다.

Answer 3

아마도 약간 주제에서 벗어난,하지만 ....

내가 롤 오버 밤 자신을 포함하여 Y2K 기간 동안 오라클 지원을 위해 일하고 있었다.

오라클의 Y2K 성명서 사본을 요청하는 고객이 밤새 전화 한 통을 받았습니다. 조금 늦은 methinks. :)

그 외의 경우 Y2K 문제에 대한 호출을 수신하지 마십시오. (비록 내가 RDBMS 서버 그룹에서 작동하지 않았 음을 유의하십시오.)

Answer 4

오라클은 V7 이후 날짜를 전체 날짜 - 시간 형식으로 저장했으며, 대부분의 클라이언트 애플리케이션은 explicit -YY 형식 2K 기한보다 약간의 시간을 마스킹합니다.

그러나 2K 이후 사람들이 YY 형식 마스크를 다시 사용하기 시작한 후 테스트 데이터가 post-Y2K이므로 테스트에주의하지 않고 버그가 발생했습니다. 특히 date/string/date를 수행 할 때 특히 그렇습니다. 조작 - 인공 예 : 별도의 데이터베이스 컬럼으로 날짜와 시간을 저장하는 기존 시스템을 취급하는 경우

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

이러한 논리는 매우 일반적이다. 구문은 오라클에 따라 다를 수 있지만 문제는 실제로 일반적인 프로그래밍입니다.

오라클과 더 관련이있는 문제는 NLS 날짜 설정과 관련되어 있습니다. DBA가 데이터베이스를 다시 작성했지만 기본 형식을 -YY로 다시 설정하는 것을 보았습니다. 또한 JDBC 연결에서 세션 형식을 -YY로 설정하고 OS 환경에서 상속받으며 데이터베이스를 무시하는 오류가 발생했습니다. 태만.

이들 중 어느 것도 오라클 소프트웨어의 결함이 아니며 시스템 및 프로그래밍 언어가 2 자리 연도를 허용하는 한 'Y2K'문제가 발생한다는 것을 알고 있습니다.