В кластере Oracle будет ли sysdate всегда возвращать согласованный ответ?

Question

В кластере Oracle (более одной машины, взаимодействующей для обслуживания одной базы данных) функция «sysdate» всегда возвращает согласованный ответ? Даже если часы операционной системы серверов сообщают о непоследовательных значениях?

Answer 1

Я бы сильно подозревал, что SYSDATE также связан с ОС. Будьте очень внимательны к причине, почему вы должны использовать его. Если у вас есть какая-либо логика, которая реализует инкрементное отслеживание событий (например, вы делаете инкрементный экспорт), и вы должны обеспечить отсутствие элементов, оставшихся без дублирования, основывать отслеживание на последовательных идентификаторах, а не на SYSDATE.

Фактически это справедливо даже для некластерных систем, поскольку SYSDATE может иногда меняться (сбережения времени, ошибки sysadmin ...).

Answer 2

Используйте NTP для синхронизации времени на всех ваших серверах (Oracle и других) и убедитесь, что этого не происходит. Непостоянные системные часы - это рецепт катастрофы.

Я хотел бы угадать, что sysdate вернет непоследовательные результаты в описываемом вами сценарии.

Answer 3

Я потратил (немного) время на поиск ответа на этот вопрос, но не смог найти его, но, учитывая, что sysdate просто возвращает дату/время из операционной системы, я подозреваю, что dmitriy правильный.

Answer 4

SYSDATE связан с узлом ОС; если бы это было гарантировано правильно по всему кластеру, то узлам пришлось бы синхронизировать каждый раз, когда вы вызывали SYSDATE. В кластерной среде упорядоченные последовательности дороги; лучше всего избегать, если это вообще возможно. Закаленная последовательность гарантирует уникальность и порядок - однако вы все равно можете получить пробелы, если обработка не удалась после выбора из последовательности и до совершения транзакции.

Мы используем несколько обходных пути:

1. Как правило, последовательности устанавливаются неупорядоченные с большим кэшем размером (25,000), чтобы уменьшить INTER кластера связи.
2. Использование NTP для временной синхронизации узлов (они все еще могут быть неверных, +/- наносекунд, так что вы не можете полагаться на это)
3. Для журналов аудита стиля, мы используем systimestamp (метка времени (6)) в качестве уникального идентификатора - и жить с тем , что возможно (хотя крайне маловероятно), что журналы может появиться из строя (это также возможно с нормальной обработки, в зависимости от того, когда происходит Фиксации)

4. Если требуется упорядоченная последовательность , и может быть пробелы - использовать упорядоченную последовательность (старайтесь избегать в кластерном среде как «кэш» не помогает)

5. Где упорядоченная последовательность требуется - но не может быть пробелов - у нас есть своя таблица последовательностей, блокировка записи, получение номера и , а затем запись заблокирована до , которую совершает пользователь; это приведет к тому, что все остальные пытаются получить то же самое Последовательность, чтобы подождать, пока транзакция пользователя будет полностью совершена - избегайте делать это, если это вообще возможно.