Технический анализ

Дополнительный день високосного года может стать источником проблем

Тимоти Дик (для PC Week Labs)

Разработка проектов для 2000 года предоставляет компаниям “настоятельную возможность” более пристально взглянуть на свои особо важные системы.

Ключевая роль в этом процессе принадлежит СУБД и данным, для хранения которых они используются. К сожалению, оценить возможные последствия наступления следующего столетия и проверить готовность баз данных для работы в 2000 году труднее всего. Дело в том, что в других компонентах вычислительных сетей, включая аппаратные средства и операционные системы, входные и выходные потоки информации гораздо более ограниченны, а ошибки в их работе намного заметнее.

К счастью, архитектура реляционных СУБД, получивших на сегодняшний день наиболее широкое распространение, создавалась в 80-х годах, когда проблема экономии места на носителях уже не стояла столь остро. Благодаря этому разработчики смогли отказаться от двузначной записи года, и сейчас в большинстве реляционных СУБД для этого параметра отведено четыре знака.

Верхний экран: если год указан двумя цифрами, система Oracle по умолчанию относит его к нынешнему столетию. По этой причине последним днем месяца, который начинается 01-Feb-00, система считает 28 февраля, что вполне справедливо для февраля 1900 года, но никак не для февраля года 2000. Четырехзначный формат отображения года воспринимается системой вполне корректно. Хорошие результаты дает и изменение конфигурации системы, которая учитывает приближение границы двух столетий. Нижний экран: для диспетчера задач сервера Microsoft SQL Server 6.5 даты 29 февраля 2000 года просто не существует

Организация, в которой используется формат даты SQL, может быть уверена, что в ее базах данных для хранения года отведено четыре знака.

Для сравнения отметим, что в приложениях на языке Кобол решить проблему 2000 года намного сложнее.

Еще большую проблему грозятся создать системы, использующие для хранения даты и времени не специализированный формат, а обычные символьные или цифровые поля (такой метод был присущ прежним приложениям для AS/400). Администраторам таких систем можно только посочувствовать: им не стоит строить планы на отпуск в 1999 г. Вместо отдыха их ждет колоссальный труд по перестройке таблиц и доработке исходных текстов SQL.

Но сколь ни велики трудности с реконструкцией СУБД, все их способен затмить еще один аспект проблемы - обеспечение работоспособности баз данных. В частности, как показала экспертиза PC Week Labs, проблема дополнительного дня в високосном 2000 году все еще не решена в инструментальных средствах администрирования и конфигурирования, без которых нормальная эксплуатация баз данных невозможна. К тому же 2000 год, в отличие от начальных годов других столетий, кратен 400, что делает его “особо особым”, исключительнейшим среди “обычных исключений столетия”.

Независимо от желания компаний им все же придется в той или иной степени обновлять свое серверное ПО - без этого приведенных выше трудностей не преодолеть. Но и это еще не все. Кроме общих проблем перед многими компаниями возникнут и проблемы, связанные с продуктами конкретных производителей. Некоторые из них мы рассмотрим ниже.

Oracle7 и Oracle8

По заявлению представителей корпорации Oracle, во всех версиях Oracle7 и Oracle8 проблема 2000 года решена.

Однако формат данных, используемый в этих СУБД по умолчанию, предполагает преобразование всех годов, обозначенных двумя цифрами, в годы века нынешнего. И это может застигнуть врасплох тех, кто заранее не подготовится к решению такой проблемы.

Приведем лишь один пример. Когда мы ввели в Oracle8 версии 8.0.4 дату 01-Feb-00 и воспользовались функцией LAST_DATE для расчета последнего дня месяца, система выдала 28-Feb-00, что справедливо для 28 февраля 1900 года.

Исправить такую ситуацию помогает специальная маска вводимых данных (в ней для обозначения года вместо букв YY используются буквы RR), предусмотренная как в Oracle7, так и в Oracle8. При ее использовании все годы, обозначенные двумя цифрами, система помещает в интервал между 1950 и 2049 годами.

Чтобы воспользоваться этой маской, мы изменили параметр NLS_DATE_ FORMAT на DD-MM-RR, после чего система начала воспринимать год 00 как 2000 (см. верхний экран на иллюстрации).

Мы настоятельно рекомендуем компаниям, использующим СУБД Oracle, внести в файл инициализации такие же изменения. В противном случае все даты придется вводить в четырехзначном формате.

Полностью готовы к работе в 2000 году будут лишь те СУБД Oracle, которые оснащены консолью управления Enterprise Manager версии 1.4 и последующих. Что же касается Oracle Lite, то это должен быть пакет версии 2.5 или более поздней (его версии от 2.0 до 2.3 выпускались в 1996 году, и их еще можно встретить в некоторых организациях).

Во всех версиях Oracle Express начиная с 5.0 и далее проблема 2000 года решена.

Microsoft SQL Server

Корпорация Microsoft сама указывает на некоторые незначительные проблемы в совместимости своей СУБД SQL Server с датами 2000 года.

Одна из этих проблем связана с дополнительным днем високосного года: консоль Enterprise Manager не позволила нам спланировать рабочие задания на 29 февраля 2000 года. Этой даты в ее календаре просто не существует (см. нижний экран на иллюстрации).

Кроме того, как оказалось, после 1 января 2000 года нарушится стандартный порядок резервного копирования баз данных. Вместо того чтобы вывести на экран предупреждение и дождаться подтверждения от пользователя, система просто заменит прежнюю архивную копию на новую.

По заявлению представителей Microsoft, все эти недочеты будут устранены в служебном комплекте SQL Server Service Pack 5, который должен появиться еще до конца текущего года.

При вводе любой даты, в которой год обозначен двумя цифрами, SQL Server автоматически учитывает, что она может относиться к следующему столетию. Все годы, обозначенные цифрами больше 50, воспринимаются системой как относящиеся к веку нынешнему, а меньше 50 - к веку XXI.

Sybase Adaptive Server Enterprise и SQL Server

Adaptive Server Enterprise 11.5.1 стал первой версией этого продукта, в которой Sybase удалось полностью решить проблему 2000 года.

Конечно, многое было сделано уже в предыдущей его версии 11.5, но там встречались ошибки. Они, в частности, не позволяли проводить анализ записей контрольного журнала, внесенных после 1 января 2000 года, а также воспроизводить сеансы, проведенные в 2000 году и позже.

Сможет работать в 2000 году и сервер Sybase SQL Server - предшественник Adaptive Server Enterprise. В его версии 11.0.3.2 решен ряд проблем резервного копирования, сходных с теми, которые встретились нам в Microsoft SQL Server.

В обеих СУБД Sybase все годы, обозначенные двумя цифрами менее 50, воспринимаются как относящиеся к следующему столетию.

Решена проблема перехода в XXI век и в новых вариантах СУБД для рабочих групп SQL Anywhere начиная с версии 5.5.02 (она была выпущена в середине 1997 года).

IBM DB2

Корпорация IBM сертифицировала для работы в XXI веке свою СУБД DB2 2.1 для сред Unix и Windows NT и последующие ее версии (включая DB2 Universal Database 5.x).

Что же касается мира мэйнфреймов, то здесь проблема 2000 года решена в DB2 for MVS/ESA версий 3 и более поздних (с применением служебных обновлений). Все необходимые для этого доработки полностью вошли лишь в версию 5.

Из хранилищ данных, выпускаемых корпорацией IBM, к работе в 2000 году готов пакет Visual Warehouse 2.1 и его более поздние версии.

Дополнительную информацию о DB2 в вариантах для AS/400, MVS и OS/390 можно найти в базе данных о готовности программных продуктов IBM на узле wwwyr2k.raleigh.ibm.com.

С внештатным редактором Тимоти Диком можно связаться по адресу: tim@journalist.com.