Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Хозяйке на заметку. HADR, logindexbuild и LOAD
|
|||
|---|---|---|---|
|
#18+
Известная проблема с HADR'ом и большими/средними по размеру таблицами - перестройка индексов во время REORG. Сам REORG переносится на standby без проблем, а вот rebuild индекса (ов?) идёт в оду транзакцию и может в активные логи не поместиться (а и от logindexbuild особо не откажешься). Обратил внимание на примечательную вещь - при LOAD'е с опцией COPY LOAD YES [TO ...|USE TSM] построение индексов не логируется (в целом). Т.е., к примеру, на табличку в 6Gb с набором индексов в 5Gb (да, таблица индексами перегружена) TOTAL_LOG_USED_TOP получился 13Mb , а образ LOADCOPY на фазе построения индексов продолжал значимо расти. Можно использовать также и для альтернативы REORG'у. Важно! На время LOAD'а standby HADR'а должен быть деактивирован до момента, когда LOADCOPY образ станет/мы сделаем доступным через файловую систему или TSM (по тому пути, по которому указывали в LOAD). В противном случае таблица будет помечена на standby как невалидная (а может и всё табличное пространство в RESTORE PENDING утащит). Что мы выясним только когда переедем (по факту аварии). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2017, 19:33 |
|
||
|
|

start [/forum/topic.php?fid=43&msg=39388691&tid=1600491]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
158ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
31ms |
get tp. blocked users: |
1ms |
| others: | 14ms |
| total: | 243ms |

| 0 / 0 |
