|
rman, allocate channel и duplicate в 11g
|
|||
---|---|---|---|
#18+
Доброго "что там у вас", коллеги. Никогда такого не было и вот, опять: надо перенести базу с Oracle 11g Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production PL/SQL Release 11.2.0.4.0 - Production "CORE 11.2.0.4.0 Production" TNS for 64-bit Windows: Version 11.2.0.4.0 - Production NLSRTL Version 11.2.0.4.0 - Production под Windows Windows Server 2012 R2 Standard на аналогичную версию Oracle Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production PL/SQL Release 11.2.0.4.0 - Production "CORE 11.2.0.4.0 Production" TNS for Linux: Version 11.2.0.4.0 - Production NLSRTL Version 11.2.0.4.0 - Production под Linux NAME="Oracle Linux Server" VERSION="7.7" ID="ol" ID_LIKE="fedora" VARIANT="Server" VARIANT_ID="server" VERSION_ID="7.7" PRETTY_NAME="Oracle Linux Server 7.7" ANSI_COLOR="0;31" CPE_NAME="cpe:/o:oracle:linux:7:7:server" HOME_URL=" https://linux.oracle.com/" BUG_REPORT_URL=" https://bugzilla.oracle.com/" ORACLE_BUGZILLA_PRODUCT="Oracle Linux 7" ORACLE_BUGZILLA_PRODUCT_VERSION=7.7 ORACLE_SUPPORT_PRODUCT="Oracle Linux" ORACLE_SUPPORT_PRODUCT_VERSION=7.7 Проблема в следующем: при выполнении в RMAN команды Код: plsql 1.
Если просто выполнить команду из RMAN - все проходит "на ура". RMAN создаст по три канала type=DISK для TARGET и AUXILIARY и все сделает как попросили. Но, если задаться целью урезать нагрузку на сеть, описывая каналы руками Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.
то RMAN валится с ошибкой на дублировании controlfail в скрипте backup as copy current controlfile for standby auxiliary. Первый из трех controlfile's создается "где доктор прописал" в DUPLICATE, а два валятся в '?/dbs' как D:ORACLEORADATAEFIRCONTROL02.CTL и т.д, игнорируя в том числе и указанное явно в SET "DB_FILE_NAME_CONVERT". Соответственно, база при старте в MOUNT их не находит, "жутко ругается и матерно кроет Голливуд". Поскольку ищет файлы как прописано в SET "CONTROL_FILES". Без ALLOCATE CHANNEL (и по три, и по одному для TARGET и AUXILIARY) все ОК, конфигурация Data Guard работает, архивлоги передаются и накатываются... DUPLICATE снимается с экземпляра STANDBY, где новый сервер описан как каскадный. Где собака порылась? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.03.2020, 02:20 |
|
rman, allocate channel и duplicate в 11g
|
|||
---|---|---|---|
#18+
kva6513, parameter_value_convert ... |
|||
:
Нравится:
Не нравится:
|
|||
20.03.2020, 05:09 |
|
rman, allocate channel и duplicate в 11g
|
|||
---|---|---|---|
#18+
xtender parameter_value_convert Спасибо, попробую. Хотя и смущает Код: plsql 1.
Прямо сейчас проверить не могу, но проверю обязательно. Но, все равно, даже если поможет - вопрос-то останется. Почему без явного ALLOCATE CHANNEL все работает даже без прописывания имен контрольников в DB_FILE_NAME_CONVERT (посмотрел по сохраненным логам), хватает и кляузы SET CONTROL_FILES? А в случае явной конфигурации каналов - все валится хоть прописывай контрольники в DB_FILE_NAME_CONVERT, хоть не прописывай... ... |
|||
:
Нравится:
Не нравится:
|
|||
20.03.2020, 12:33 |
|
rman, allocate channel и duplicate в 11g
|
|||
---|---|---|---|
#18+
kva6513 DB_FILE_NAME_CONVERT ... |
|||
:
Нравится:
Не нравится:
|
|||
20.03.2020, 12:42 |
|
rman, allocate channel и duplicate в 11g
|
|||
---|---|---|---|
#18+
xtender но ты не показал ничего. Мне не жалко, сейчас покажу. Но смысл это делать? Без ALLOCATE CHANNEL оно работает, хотя и ведет себя не как в PFILE. Там можно каждую пару DB_FILE_NAME_CONVERT прописать, для более лучшей читабельности, отдельной строкой и все будет ОК. А в команде DUPLICATE - полный конец обеда и индейский дом (который фигвам). Работать будет только последнее значение SET "DB_FILE_NAME_CONVERT", все предшествующие пойдут по бороде... И без никаких сообщений об ошибках от RMAN-а. Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27.
... |
|||
:
Нравится:
Не нравится:
|
|||
20.03.2020, 12:56 |
|
rman, allocate channel и duplicate в 11g
|
|||
---|---|---|---|
#18+
Помогло примерно никак. Валится на том же месте, на скрипте Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
В $ORACLE_HOME/dbs Код: plaintext 1. 2.
После переноса controlfile-ов из DB_FILE_NAME_CONVERT в parameter_value_convert RMAN-скрипт выглядит так Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39.
... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2020, 10:17 |
|
rman, allocate channel и duplicate в 11g
|
|||
---|---|---|---|
#18+
kva6513 В $ORACLE_HOME/dbs Код: plaintext 1.
нигде ошибок со слешами нет? рман на какой стороне запущен? на линуксе или винде? ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2020, 13:40 |
|
rman, allocate channel и duplicate в 11g
|
|||
---|---|---|---|
#18+
xtender нигде ошибок со слешами нет? Зуб не дам (мало осталось), но без ALLOCATE CHANNEL работает. Дублирует базу и дальше синхронно катит логи через каскад. xtender рман на какой стороне запущен? на линуксе или винде? На линуксе. Поскольку злые сетевые админы рубят неактивные коннекты, запускается в бэкраунд Код: plaintext 1.
А в duplicate_efir.rman и лежит собственно либо блок RUN{} c ALLOCATE (когда DUPLICATE валится), либо просто DUPLICATE. Впрочем, когда запускал в FOREGROUND - результат был одинаковый. Да, без RUN{} тоже пробовал. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2020, 19:43 |
|
rman, allocate channel и duplicate в 11g
|
|||
---|---|---|---|
#18+
kva6513, Ну запусти с debug trace ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2020, 20:36 |
|
rman, allocate channel и duplicate в 11g
|
|||
---|---|---|---|
#18+
Но opt oradata наводят на мысли о неправильных слешах ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2020, 20:37 |
|
rman, allocate channel и duplicate в 11g
|
|||
---|---|---|---|
#18+
xtender Но opt oradata наводят на мысли о неправильных слешах И кто их (неправильные слэши) правит без ALLOCATE? Сам исходник, во всех вариантах запуска, лежит в локальном файле, где редактируется и копипаститься в запускаемый без редактирования скрипт. xtender Ну запусти с debug trace Мысль интересная. Но не факт, что найду время: с меня жеж работающий сервер хотят. Скорей всего, как те космонавты из анекдота, полетим на Солнце ночью. :) Я то думал, когда тему открывал, что совсем уже отупел и не вижу чего-то совсем явного - благо сценариев DUPLICATE в сети вертеп едучий. И у всех работает... BTW: Версия Linux (7.7) не может быть причиной? Какая там либа... Все-таки, когда 11g писали, семерки еще не было... ... |
|||
:
Нравится:
Не нравится:
|
|||
22.03.2020, 23:26 |
|
rman, allocate channel и duplicate в 11g
|
|||
---|---|---|---|
#18+
kva6513, а если сделать Код: plsql 1.
вместо allocate и убрать вообще все convert для контролов и оставить только set control_files= с новыми путями? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2020, 01:30 |
|
rman, allocate channel и duplicate в 11g
|
|||
---|---|---|---|
#18+
Уже Код: plaintext 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2020, 02:01 |
|
rman, allocate channel и duplicate в 11g
|
|||
---|---|---|---|
#18+
Давайте, я попробую еще раз объяснить суть проблемы. Я явно плохо, негодно объясняю. Когда я перестал путаться в сопляхсинтаксисе команды DUPLICATE (что произошло не сразу - раньше обходился CREATE STANDBY CONTROLFILE AS + RMAN бэкапы). Как только RMAN перестал ругаться на синтаксис DUPLICATE - без явного ALLOCATE все поехало. Но отъедало выделенный серверу гиг "полосы" под завязку. На что мне предложили, на всякий случай, урезать RMAN, пока нам не настучали по голове "злые сетевые админы". :) Явно урезать параллелизм через определение по одному каналу для target/auxiliary я пробовал - падает с описанными выше симптомами. Правда, можно попробовать ALLOCATE CHANNEL без явного указания RATE? Или наоборот, выставить PARALLELISM 1 и забить на RATE? Как говорил один мой бывший шеф и просто хороший человек: - Это не программирование, это какое-то шаманство уже... :) ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2020, 02:29 |
|
rman, allocate channel и duplicate в 11g
|
|||
---|---|---|---|
#18+
Я как-то не очень понял Если не задавать в команде DUPLICATE вообще ничего, относящегося к параметрам, а прописать все это в [s]pfile, тоже не работает? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2020, 03:03 |
|
rman, allocate channel и duplicate в 11g
|
|||
---|---|---|---|
#18+
Вячеслав Любомудров Если не задавать в команде DUPLICATE вообще ничего Так - не пробовал. Если не задавать - он потянет весь spfile с исходного сервера, что не нужно. Исходный сервер под Windows, а новый под Linux и там не только разница в путях файловой системы. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2020, 11:05 |
|
rman, allocate channel и duplicate в 11g
|
|||
---|---|---|---|
#18+
xtender убрать вообще все convert для контролов и оставить только set control_files= с новыми путями? Все убирать не пробовал. Сейчас пошарил, какие логи у меня сохранены: из неудавшихся только тот, про который написано в сообщении 22103863 . Там ведь какая последовательность (если RMAN не ругнулся на синтаксисе): - выделяются (явные или дефолтные) дисковые каналы; - копируется (backup as copy reuse) PWD-файл; - выполняется alter system set spfile и выполняются команды сперва alter system reset потом alter system set; - shutdown и startup auxiliary database; - снова выделяются каналы; - backup as copy current controlfile for standby auxiliary format и restore clone controlfile to. Вот на этом месте оно всегда и валится, если задаю явно Код: plaintext 1. 2. 3. 4. 5. 6.
Пробовал и по одному каналу назначать и по три, каждый раз картина одинаковая - первый контрольник создается как прописано в SET CONTROL_FILES, а два других отправляются в $ORACLE_HOME/dbs в виде Код: plaintext 1. 2.
и на этом месте RMAN валится с ошибкой Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9.
т.е. до создания файлов тейблспейсов и логов REDO дело просто не дойдет и что там будет с SET DB_FILE_NAME_CONVERT и SET LOG_FILE_NAME_CONVERT - неизвестно. Кляузы RESET в команду DUPLICATE прописал не сразу, только после того, как увидел, что в созданный на auxiliary SPFILE приехали установки с исходной базы. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.03.2020, 11:54 |
|
rman, allocate channel и duplicate в 11g
|
|||
---|---|---|---|
#18+
kva6513 Вячеслав Любомудров Если не задавать в команде DUPLICATE вообще ничего Так - не пробовал. Если не задавать - он потянет весь spfile с исходного сервера, что не нужно. Исходный сервер под Windows, а новый под Linux и там не только разница в путях файловой системы. Заранее формируешь [s]pfile и файл паролей и выполняешь просто DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE NOFILENAMECHECK DORECOVER ... |
|||
:
Нравится:
Не нравится:
|
|||
24.03.2020, 03:58 |
|
rman, allocate channel и duplicate в 11g
|
|||
---|---|---|---|
#18+
Просто есть подозрение, что ручные AUXILIARY каналы открываются раньше, чем реально необходимо и считывают значения до того, как файл параметров сформировался ... |
|||
:
Нравится:
Не нравится:
|
|||
24.03.2020, 04:01 |
|
rman, allocate channel и duplicate в 11g
|
|||
---|---|---|---|
#18+
Вячеслав Любомудров Заранее формируешь [s]pfile и файл паролей Так пошлет жеж rman, если auxiliary будет запущено с spfile, ошибку выдаст. Файл паролей - да лежал готовый в ?/dbs. Но rman вот что сделал (после ALLOCATE): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
... |
|||
:
Нравится:
Не нравится:
|
|||
24.03.2020, 13:12 |
|
rman, allocate channel и duplicate в 11g
|
|||
---|---|---|---|
#18+
Экземпляр auxiliary запускался командой startup nomount pfile=?/dbs/initefir.ora В initefir.ora Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18.
... |
|||
:
Нравится:
Не нравится:
|
|||
24.03.2020, 13:26 |
|
|
start [/forum/topic.php?fid=52&fpage=50&tid=1881428]: |
0ms |
get settings: |
9ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
37ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
73ms |
get tp. blocked users: |
1ms |
others: | 285ms |
total: | 434ms |
0 / 0 |