ORACLE 2000年问题白皮书

1. 导言

解决2000年兼容性问题，需要在日期的数据类型处理方面满足下列五个主要因素：

1． 正确处理2000年1月1日以前、当天及之后的日期信息、接收日期输入、提供日期输出、进行日期或日期子项的计算。

2． 随着新世纪的到来，采用正确的配置，以保证正常执行2000年1月1日以前、当天及之后的文件。

3． 在适当之处，以公开确定的方式解决世纪取值的含糊问题，以作为对两位数字日期输入的响应。

4． 以明确指出世纪的方式进行日期信息的存储和输出。

5． 根据quad-centennial原则来处理2000年将要出现的闰年。

这些标准是由英国标准协会在《DISC PD-2000-1A，2000年兼容性要求的定义》中所制订的2000年兼容性要求的精华所在。

2. 产品兼容性

Oracle现有产品的设计都解决了2000年兼容性问题。

与现有Oracle数据库相关的软件产品在2000年日期改变兼容性方面的说明请参考下列表格和注解。为方便客户，这里还提供了与仍被大量机构使用的定型产品相对应的2000年兼容信息。根据它们到期程度不同，其中一部分产品未解决2000年兼容问题或只是部分解决了这一问题。

表格与注解分为两大部分：现有产品和定型产品。

现有产品：目前属于Oraclemetals支持产品系列的产品。根据兼容性级别，我们对每种产品/产品集进行了说明。此类型产品主要为“完全兼容”产品。

定型产品：己发布了非支持声明的产品和/或属于“延长辅助支持”类型的产品。

根据兼容性级别，我们对每种产品/产品集进行了说明。对于到期产品来说，主要是给出有关如何简化代码更改和绕过问题的建议。我们希望使用这些定型产品的用户及早考虑升级为Oraclemetals支持产品，以便减少日期据转换的工作量，并获得最优支持。

2.1兼容性水平

兼容性级别 说明

完全兼容 产品的现有生产版本完全符合第一部分描述的五个因素

部分兼容（1） 产品的现有生产版本不完全符合第一部分描述的五个因素，但Oracle将在产品今后的版本中提供完全兼容性。

部分兼容（2） 此定型产品的现有生产版本不完全符合第一部分描述的五个因素，且Oracle没有计划在将来改进其兼容性。

不兼容 此产品的现有生产版本不符合第一部分描述的五个因素，且Oracle今后不再改变其兼容性。

3. 各种产品兼容性信息列表：

略。详细内容请到ORACLE公司 网站http://www.oracle.com/year2000/上查询。

3.6现有产品注解

3.6.1不进行数据操作的产品

这些产品不进行数据操作，因此它们本质上就是2000年兼容的。

3.6.2 Orac1e服务器

Oracle服务器是2000年兼容的。

使用Oracle RDBMS（Oracle7和Oracle8服务器）并采用DATE

数据类型（用于日期和/或带时间值的日期)的应用，在2000年到来

之际无需为其存储的数据担心。Oracle7和Oracle8服务器DATE数据

类型以四位数字年份和包括以秒数计时（一般为

‘YYYY:MM:DD:HH24:MI:SS’）的精确程度来存储日期及时间数据。

Oracle服务器、网络产品及系统管理产品不会出现任何操作问

题。 Oracle的开发部门已对各种2000年操作情况进行了测试以确保

用户在世纪更替之际不会受到任何影响。测试的内容包括复制、时间

点的恢复、分布式事务等。系统管理和网络化特性通过时区/日期行/

世纪来完成。

Oracle RDBMS已采用四位数字年份来存储日期（‘OraDate’格式），

这样使用DATA数据类型的用户就不会有任何应用级方面的问题。为

了方便使用两位数字年份格式的应用解决2000年兼容性问题，Oracle7

和Oracle8提供了一种特殊的年份格式表征码‘RR’。采用‘RR’格

式输入的两位数字年份将做如下转换：

当前年份：最后两位数字指定的两位数字年份‘RR’年份格式返

回

0-49 0-49 当前世纪

50-99 0-49 下一世纪

0-49 50-99 上一世纪

50-99 50-99 当前世纪

因此，无论在哪一世纪输入数据，‘RR’格式都会确保数据库中

所存年份如下所示：

如果当前年份在后半世纪（50-99）

? 且输入的两位数字年份在‘00’和‘49’之间：将按下一世纪

的年份存储。例如，1996年输入的‘02’将存为‘2002’

? 且输入的两位数字年份在‘50’和‘99’之间：将按本世纪年

份存储。例如，1996年输入的‘97’将存为‘1997’。

如果当前年份在前半世纪（00-49）

? 且输入的两位数字年份在“00’和‘49’之间：将按本世纪年

份存储。例如，2001年输入的‘02’将存为‘2002’

? 且输入的两位数字年份在‘50’和‘99’之间：将按下一世纪

的年份存储。例如2001年输入的‘97’将存为‘1997’

‘RR’日期格式可用于数据库中DATE数据的插入及更新。因为

0rac1e一直以四位数字的格式存储日期的YEAR部分，故您无需对己

存储于数据库中的数据进行检索/查询。

3.6.2.1以字符数据类型存储的日期

‘RR’数据格式只对使用Oracle DATE数据类型的用户应用起作

用。对于那些使用CHAR或VARCHAR2数据类型的字符串的应用，除非

在设计时已有考虑，否则就须对应用作出修改、加入例行程序以确保

这样的数据在受到世纪更替的影响时可得到正确的处理。对于新建应

用或正进行修改以使按字符串存储的日期数据可满足2000年兼容的

应用，我们建议将这些日期转换为Oracle DATE数据类型，这样就确

保了它们的2000年兼容性，如果此方法不可行，那就以语言及格式

相独立且能处理全部年份的规范形式存储数据。‘YYYY/MM/DD’，在必

要时加上时间元素‘HH24:MI:SS’这一格式即是一例。每当显示或从

用户及其它程序中接收到以此形式存储的日期时，必须将其转换为正

确的外部格式。

格式‘YYYY/MM/DD HH24:MI:SS’有如下优势：

? 语言独立，即月份为数字形式

? 年份为四位数字，明确了世纪取值

? 时间得到了全部表示，最重要的元素在前，这样基于字符进行

的排序操作即可对日期进行正确的排序

它的缺点之一是不支持公元前日期。

3.6.4 Oracle Server Manager

Oracle Server Manager显示的Oracle服务器信息可经由内部发

出的SQL查询从RDBMS中获得。因此它完全继承了RDBMS的兼容性。

3.6.5 Oracle ODBC 驱动程序

Oracle ODBC驱动程序使用ODBC日期和时间数据类型，它们都包

括四位数字的年份元素。

3.6.6 Oracle Enterprise Manager

Oracle Enterprise Manager显示的Oracle服务器信息可经由内

部发出的SQL查询从RDBMS中获得。因此它完全继承了RDBMS的兼容

性。

3.6.7 Oracle Precompiler

Oracle Precompiler产品是2000年兼容的。

Oracle Precompiler产品不含有对操作日期型数据的预定义例行

程序，所有这样的操作都由开发商以3GL代码形式提供，并调用至服

务器上的PL/SQL引擎。因此2000年兼容性的解决取决于开发商正确

设计与编写应用代码。

3.6.8 Oracle OLAP Server产品

Express Server和Personal Express是2000年兼容的。处理时

间大小和‘日期’数据类型的内部机制是基于从一个固定基础日期算

起的秒数决定的。2000年在此并无特殊意义，它会得到与其它数据一

样的处理。所有日期的输入、存储、计算或显示日期的功能都与2000

年前的操作一致。

第二个考虑因素是对于格式为两位数字的年份的处理，如用“97”

代表“1997”。在缺省情况下，两位数字的年份被解释为在1950到2049

年之间，这除非通过选项YRABSTART特别指定才会有所改变。于是在

缺省值时“00”即被解释为2000年。

考虑到除了不能被400整除的世纪元年(如1900年）之外，每4

年是一个闰年。Express将2000年作为闰年对待。我们可作一项简单

的测试，对2000年2月之内的日期使用ENDOF（month）函数结果为

29FEB2000，验证了2000年确实已被作为闰年处理。

Express有一种可以转换为日、月份及年份的“日期”数据类型。

它可以处理从1899年12月31日到大约400,000年间的日期。这是

日期数据在数据库中的基本存储方式。

Express还有一个向Express程序返回日期-时间“邮戳”的函数。

此时间邮戳常常用于跟踪事件发生顺序的应用。此邮戳的返回值为一

个31位整数，代表着从PC采用此规定起的那一刻（1950年）以来的

秒数。它将于2036年溢出。但所有使用此邮戳的Express应用都可

将它转换为可处理任意4位数字年份的文本（例如到9999）。我们在

将来的产品版本中将改变日期-时间邮戳函数，使之返回一个较大的

十进制数。这一数值可处理超过4000年的年份，且因为存储它的文

本数据已经可以处理任何4位数字的年份，故它不需要作任何变动。

显然，我们可在2036年年底之前的任何时候完成这项改动，当然在

方便的情况下我们会及早行动。

3.6.9 Oracle RDB

Oracle RDB是2000年兼容的。

使用Oracle RDB并采用DATE或TIMESTAMP数据类型的应用无须

在2000年到达之际为其存储的数据而担心。Oracle RDB存储含有全

部年份和世纪的DATE（SQL92兼容且为VMS风格）和TIMESTAMP型数

据，自从1984年此产品第一版问世起就一直如此。

Oracle RDB实现了SQL92 SQL标准中规定的大多数日期/时间功

能。用这些数据类型所作的日期比较自然就可以不受世纪更换的影

响。事实上RDB数据库中可存储及操作的最大年份为9999年。

3.6.10 Developer/2000客户/服务器开发工具

Developer/2000客户/服务器开发工具集是2000年兼容的。

Text选项Item和Display Item有两个可以使用的特殊格式表征

码‘RR’和‘RRRR’。这些格式表征码采用上文描述的‘RR’日期格

式表示码所用的规则。

“RRRR”格式表征码允许将两位数字年份输入到四位数字域中，

并根据上文中‘RR’日期格式表征码中的规则将其赋予正确的世纪值。

Developer/2000的报告模块――Oracle Report和Oracle Graphic

不会受到世纪更替的影响，这是因为它们主要是从以四位数字形式存

储年份的数据库中检索数据。而这些产品中所有允许在

数据库中进行数据操作的部分都是2000年兼容的。

Web Cartridge（适用于Developer/2000 1.4w版的应用服务器）

是2000年兼容的。

3.6.11 Discoverer/2000客户/服务器报告工具

Discoverer/2000客户/服务器报告工具集是2000年兼容的。

Oracle Data Query和Oracle Data Browser都为带两位数字年

份的日期数据提供了包括‘RR’年份格式表征码在内的完全兼容性。

当使用‘RR’格式表征码时。在用来对数据库进行插入或删除操作处，

都将加入相应的世纪值。

3.6.12 Oracle OLAP开发及分析工具

Express Analyzer中所有与日期相关的功能都依靠Personal

Express和Express Server来完成。因此根据提供的指令使用现有生

产版本的Express Ana1yzer时，它是2000年兼容的。

Oracle Sales Analyzer 1.5版是2000年兼容的，从1.5版起，

日期就以四位数字的格式存储。

Oracle Sales Analyzer 1.5版将自动更新早先版本数据库，使

之采用四位数字日期格式。数据库中所有现存的日期值和所有用户定

义的对象(如报告、图象、用户测量值、用户集合和保存的选项等）

将自动更新为1.5版格式，并可在2000年使用。包括跨越1999年和

2000年在内的带有日期的计算都将得到正确处理。1.5版的更新和对

2000年的处理不需要DBA或最终用户的介入。

1.5版前的版本到1999年12月31日就不能再继续使用了。如果

在2000年1月1日或以后使用Oracle Sales Analyzer1.3版，则在

数据库启动时Catalog integration process期间将会发生错误。

Oracle Financial Analyzer版本（当前版本--4.8.01）是2000

年兼容的。

Oracle Financial Controller（当前版本1.0）是2000年兼容

的。

EIS和Oracle Express Analyzer(1.0版）包括下列2000年兼容

产品：

? EIS DOS 4.5A

? EIS Windows 4.8

? EIS Windows 4.5A

? Oracle Express Analyzer 1.0

但是，在安装过程中当前版本会检查各DOS文件日期，它不会认

为‘9x’要早于‘00’，这是MS-DOS在文件日期方面的限制。因此万

一您在进入2000年后的某一天安装其中的一个版本，安装时可能会

暂时将系统时间设置回二十世纪。

Oracle Express的基本技术是2000年兼容的。

Oracle Express Objects从2.0版起均为2000年兼容产品。

3.6.13带有限日历的产品

在2036年前运作并提供完全兼容性。

3.6.14 Oracle Power Objects

Oracle Power Objects是2000年兼容的。在使用两位数字年份

的日期数据之处，正确的世纪值的计算是根据本机操作系统、即

Microsoft Windows中的算法进行的。例如对Windows95来说，其算

法与Oracle使用‘RR’年份格式的方法类似，不同点只是它采用在

‘现在时间’基础上加减50年的方法，而不是Oracle算法中的2000

年而已。

3.6.15 Designer/2000和CASE产品

若生成的目标产品支持2000年兼容性，Designer/2000也提供对

2000年兼容性的全面支持。例如，生成Developer/2000模块时，可

通过‘RR’日期格式表征码实现对2000年问题的完全兼容，而生成

Visual Basic或C＋＋模块时，兼容性必须由应用开发商/程序员提

供。其中提供此兼容性的最为直接的方法就是使用四位数字的年份字

段。

Designer/2000使用的与基表中与审计列相关的日期库触发器来

维护。因此数据库会处理这一问题。Designer/2000只显示日期信息。

所有日期的显示形式由一个‘.ini’文件变量（M.S Windows 3.1）

或一个注册变量（M.S Windows NT/95）来决定，缺省值为DD Month

YYYY。当然用户也可以对它进行修改。

并且，过程模型创建者（process modeler）会对日期进行若干

运算以支持其关键路径分析功能。这些计算是用M.S.Windows数据类

型结构来完成的。这样2000年的日期改变不会产生任何问题。

3.6.16产品和平台技术

MVS--1996年年底之前IBM将修改几处小问题；

Open Gateway--只要目标数据库用四位数字的年份来存储日期，

Open Gateway系列产品就能正确处理2000年问题。与Oracle7服务

器和Oracle8服务器类似，此产品中也可针对非Oracle数据来使用RR

日期格式，这样就方便了使用两位数字年份的应用对2000年兼容性

的支持。除非日期在非Oracle数据库中在INETGER或CHARACTER字

段中存储（这是应用设计问题），否则Open Gateway不会出现应用级

的问题。

Open Gateway手册正在进行更新，为每个它支持的目标数据库添

加解决2000年问题的考虑因素。

适用于DB2的Oracle Transparent Gateway――安装手册及用户

指南提供了针对21世纪日期输入所需要的SQL语句编码指令。该手

册对21世纪的日期提供了专门指导。

DB2 Gateway手册中指出：NLS-DATE-FORMAT甚至可以在未安装DB2

Local Date Exit的情况下使用，这是因为DB2可自动接受这些格式。

DB2格式 表征码/模式 范例

ISO/JIS Yyyy-mm-dd l996-12-31

USA mm/dd/yyyy 12/31/1996

EUR dd.mm.yyyy 31.12.1996

我们建议客产不要安装DB2 Local Date Exit，并将上面所列三

种日期格式中的一种作为他们的Oracle缺省日期格式。这样客户就

总是必须提供四位数字的年份，于是就避免了混淆或意义含糊。

如果指定了适当的NLS C DATE - FORMAT且没有使用DB2 Local

Date Exit，适用于IBM DRDA的Oracle Transparent Gateway可对2000

年完全兼容。

VM-VM/ESA2.2.0版引人了对2000年兼容性的支持。详细信息可

参见1BM网页：http//vmdev.gpl.ibm.com/year200O/。

3.6.17 SQL *Plus

使用ACCEPT命令创建的DATE变量按字符串存储。这些变量可用

DEFINE命令查看。SQL *plus程序开发商应确保所存储的字符串不会

与四位数字年份格式既‘DD-MON-YY’相混淆。

4.产品兼容性――定型产品

这一部分提供了有关定型产品的信息。

此处提及的产品都是此时正被某些客户使用且不受Oraclemetals

支持或应从那一类型中删除的产品。

表4.1――定型产品

产品或打包产品	兼容性版本	产品/打包产品	参见注解
SQL*Forms Version3.0& SQL*Menu Version5.0&		不兼容 不兼容	4.2.1
SQL*Forms Version2.0/2.3 SQL*Report Version Writer1.1 SQL*Report Version1.0 (RPT)		不兼容 不兼容 不兼容	4.2.2 4.2.3 4.2.4
Oracle Forms Version4.0 OracleＲeports2.0&Oracli Graphics2.0(CDE1)		不兼容	4.2.10
Oracle RDBNMS Version6		部分兼容（2）	4.2.5
Oracle Data Version3.0		不兼容	4.2.6
Oracle Data Browser Version 1.0		完全兼容	4.2.7
Oracle CASE/Dictionary Version5.1		不兼容	4.2.8
Oracle Core Applications Version9		不兼容	4.2.9

4.2定型产品注解

4.2.1 SQL*Forms Version 3.0，SQL*Menu Version 5.0

这些产品无2000年兼容性。但可以通过使用四位数字年份日期

字段来达到较高水平的兼容性。如使用两位数字年份字段，那么为了

确保向数据库存储新数据或改变日期数据时能使用正确的世纪值，则

应使用触发器来调用使用用户编写的实现相应算法的存储过程或函数

来实现兼容性。

我们建议的工作方式如下：

在SQL*Forms 3.0中对DATE字段采取如下步骤：

1． 将日期类型改为DATETIME。

2． 使用格式表征码DD-MON-YY。

3． 创建一个On-Validate-Field触发器：（注意此代码对名为

hiredate的DATE字段重新格式化）。

DECLARE

tempdate CHAR(9)；

BEGIN

tempdate：＝TO-CHAR(：hiredate，‘DD-MON-YY)；

SELECT TO-DATE(tempdate，“DD-MON-RR’)

INTO：hiredate

FROM dual；

EXCEPTION

WHEN VALUE-ERROR THEN

MESSAGE(invalid format DD-MON-YY’)；

BELL；

RAISE FORM-TRIGGER-FAIL URE；

END；

Oracle Customer Support可提供技术资料，给出有关使用

‘RR’年份格式表征码的详细内容。

4.2.2 Oracle RDBMS第Version6

此产品是部分2000年兼容产品。而它之所以不能划分为完全兼

容产品的唯一原因是当使用两位数字年份日期时，它没有定出世纪缺

省值的程序解决方案（即Oracle RDBMS第6版中没有Oracle7 Server

和Oracle8 Server中采用的‘RR’算法）。

象Oracle7 Server和Oracle8 Server一样，Oracle RDBMS第6

版的DATE数据类型在存储日期和时间数据时可精确到四位数字年份

和秒级时间（一般为‘YYYY：MM：DD：HH24：MI：SS’)。

4.2.3 Oracle Forms4.0，Oracle Reports2.0和Oracle Graphics2.0

（CDE 1）

这些产品均不是2000年兼容产品。但它们可以达到较高水平的

兼容性-请参见4.2.1部分中关于SQL*Forms3.0版和SQL*Menu5.0版

的注解。