Привет
Про 10gR2 пока забудьте, ибо нет такой в природе ;-). Да и не советовал бы... Свежак, однако. Правда, rolling updates наконец-то появились. Внушаить (с) Хрюн
Поддерживаю .dba насчет ASM. Те же raw, но без ручного гемора. Типа, еще один LVM, тока родной ораклиный. Избавлен от кластерных кривостей некоторых LVM, возникающих, например, при добавлении тома, диска, изменении размера тома и т.п., когда не все узлы видять обновленную конфигурацию.
Про архивлоги он погорячился - их тоже можно пихать на ASM, как и FLASHBACK и прочую лабуду.
ТюкВ долгой боевой эксплуатации ASM не видел (маловато рисковых парней с крутыми системами на новье - aka 10g - ползет ;-) ), но одна довольно большая ERP-система (на Axapta) в тестовом режиме проблем не выявила (разве что statspack некорректно выдавал ASM'ные ожидания как значимые, а не idle; в AWR+ADDM не знаю, не смотрел).
Про ocfs лучше Алексея Руднева поспрошать, когда появится. Он этим плотно занимается. Скорее всего, будет нахваливать ;-). Но и про проблемы не умолчит.
SAN/NAS - без разницы. Что ASM/raw, что ocfs - ложатся поверху. Если нужен zero data loss, синхронное аппаратное зеркалирование SAN для redo может здорово помочь. Если ASM/ocfs - их конфигурации тоже синхронно обновлять. М.б. archivelog'и тоже. Остальное дотянется/довосстановится. DataGuard в MAXIMIUM PROTECTION тоже можно, но тогда сетевые каналы должны быть 100% неубойными. Иначе недоступность резервной (всех узлов) тормознет продакшн. Про SLA и время недоступности в случае катастроф - считать надо. DataGuard быстрее всех, я думаю. А для полного кайфа еще и DataGuard Manager/Broker или как он там еще обзывается. Рулить с ним проще, особенно плановые переключения или полуживой продакшн (Switchover). А вот савсэм дохлий продакшн рулить плехо (Failover). Особо жалко RESETLOGS делать, если redo зеркалятся синхронно по SAN'у.
| lilya huff |
| .dba | | Не знаю как в 10-ке, но в 9-ке TAF не распостраняется на транзакции, т.е. все открытые транзакции будут откатаны. |
Это я помню. 10-ка утверждает, что все сделано типа, только я не знаю, работает ли, гуру наш на эту тему само собой сказать ничего не может. |
То же самое гуно упаковано в более красивую коробочку и запрятано подальше от пытливых мозгов.
Оговорюсь - имею в виду только failover для транзакций, которого не было, нет и не надо. То бишь - если тебе надо, заведи журнал в приложении. Тебя уведомят, что транзакция сорвалась. Все. Подход не изменился, и нафинг не надо лишнее в базу пихать. Вроде как, задачка для мониторов транзакций.
Oracle® Database JDBC Developer's Guide and Reference
10g Release 1 (10.1)
Part Number B10979-02
8 Fast Connection Failover| |
8.3.1 What The Application Sees
When a RAC service failure is propagated to the JDBC application, the database has already rolled back the local transaction. The cache manager then cleans up all invalid connections. When an application holding an invalid connection tries to do work through that connection, it receives a SQLException ORA-17008, Closed Connection.
When an application receives a Closed Connection error message, it should:
1. Retry the connection request. This is essential, because the old connection is no longer open.
2. Replay the transaction. All work done before the connection was closed has been lost. |
В 10gR2 ONS (типа, notification services) переименовали в FAN (fast application notification), failover'а для транзакций как не было, так и нет.
Тут, например:| |
| TAF can restart a query after failover has completed but for other types of transactions, such as INSERT, UPDATE, or DELETE, the application must rollback the failed transaction and resubmit the transaction. |
Этот раздел длинный получился. Уточните у своих индусов, на что они расчитывают в плане TAF'а. Ключевой вопрос - как они закодили в своем аппсервере обработку сбоя экземпляра БД. Глядишь, сроки ввода сдвинутся ))) А там и договорчик заключим, раз парням бабло девать некуда.
Всего