June 17-18: ORACLE MIG-RAT-ION event (DBUG)
Update 1. Если Вы член RuOUG, не забудьте упомянуть этот факт в письме.
Update 2. Мы начинаем рассылку по email. Если Вы уже отослали заявку и получили положительный ответ - то повторять заявку не надо.
Первое 2-х дневное мероприятие "ORACLE MIG-RAT-ION" будет проходить 17-18 июня в Москве. Москва, Шлюзовая наб., дом 6, отель Катерина-Сити, 8 этаж, зал «Нобель». Начало мероприятия в 10-00, оба дня. Мы всегда начинаем ровно в 10-00. И пароли к архивам тоже сообщаем в 10-00 :)
- Первый день будет посвещен методам миграции, на что обратить внимание при миграции.
- Второй день будет посвещен снижению рисков при миграции, используя Real Application Testing.
Мероприятие предназначено для заказчиков. Если Вы партнер - мы тоже можем Вас пригласить, но вы должны обозначить в заявке конкретный проект, в котором Вы предполагаете миграцию.
Еще важно уточнение. Это не мероприятие, чем хороша 11g. Это мероприятие для тех, кто решил мигрировать, и знает сроки проекта. Если Вы еще не уверены, нужна ли Вам 11g приходите на Database Options Details.
Приглашение (версия для печати). Программа. Отправить заявку.
Mark Townsend, Vice President, Database Product Management отвечая на вопрос "можно ли уже мигрировать на 11g ?" пишет:
"
The stability of 11g release 1 is very good, so I would have no problem recommending that your customer go to release 1 now, ahead of release 2. One thing I would caution however is that if they do go to release 1, they will probably want to upgrade again to release 2 sometime after it comes out, as they will get typically see bug fixes and patchsets for release 2 a little ahead of release 1
"
Что в моем вольном переводе звучит как:
"Стабильность 11g R1 очень хорошая и я не вжу проблем в том, чтобы рекомендовать заказчикам мигрировать сейчас, не дожидаясь 11g R2. Надо только ответить, что скорее всего придется обновлять чуть позже до 11gR2"
Mark серьезный человек, и ему стоит доверять. По чистому совпадению, 17-18 июня, в отеле
1-ый день будет посвещен методам миграции, на что обратить внимание при миграции
2-ой день будет посвещен снижению рисков при миграции, используя Real Application Testing.
Попасть на событие можно будет только написав мне заявку.
Обращаю Вам внимание, что для семинара DBUG есть отдельное требование - написав заявку, вы соглашаетесь с тем, что мы Вам позвоним, и спросим, как прошла миграция, про которую Вы нам писали в заявке.
Пожалуйста, отнеситесь к заявке серьезно. Команда, делающая это событие делает это на собственном энтузиазме. Нам не платят, за то, чтобы Вы мигрировали на 11g. Нам даже выгоднее, чтобы Вы этого не делалали, и заплатили больше за support. Мы просто хотим, чтобы Вы могли использовать всю мощь 11g.
имеет смысл писать заявку, если миграция только предстоит в конце этого года? ну и соответственно скорей всего уже на 11gR2...
ОтветитьУдалитьЭто зависит от Вас. Если любите проводить новый год на работе - лучше конечно не ходить, потом 29 декабря прочитаете mig guide и вперед :))))
ОтветитьУдалитьДоброе утро, опять недовольный пользователь.
ОтветитьУдалитьЯ Вас не понимаю: "...Нам не платят, за то, чтобы Вы мигрировали на 11g...". Вы продвигаете продукт, Вы получаете деньги за upgrade, support в любом случае оплачивается при покупке upgrade лицензии(так же?). А вы пишете "...Нам даже выгоднее, чтобы Вы этого не делалали...". Я не понимаю. Вы, похоже, не сильно зинтересованы в новых клиентах, Вам, похоже, интересно работать только с тем кто уже работает с Oracle и точно решил его купить. А если клиент сомневается - похоже он Вам не интересен.
Простите за грубость, но, относясь лично к Вам с симпатией, я не понимаю политику.
нет, НГ я привык проводить в горах на лыжах :) посему заявку напишу. я просто к чему вопрос задал, ничего, что после посещения семинара референс о миграции будет предоставлен только спустя полгода минимум? ;)
ОтветитьУдалитьhf_artem,
ОтветитьУдалитьВы не в курсе лицензионной политики. Пользователи обычно приобретают пожизненную лицензию Oracle. Это означает, что при условии оплаченной поддержки вы бесплатно пожизненно получаете все новые версии Oracle. Никто в Oracle не получает деньги за то, что Вы мигрируете на новую версию. Более того, если Вы не мигрировали в течении срока обычной поддвиржи начинает период Extended support, где Вы платите больше, чем за стандартную поддержку. Таким образом, это клиенты заинтересованы в том, чтобы мигрировать и снизить затраты на поддержку. Со стороны команды которая делает это мероприятие как я и написал это личня инициатива. Мы хотим чтобы Вы смогли перейти на 11g, воспользовались ее преимуществами, и все это как с можно меньшими проблемами.
Конечно же семинар по upgrade для тех, кто уже купил лицензии. Для новых клиентов (да и старых) у нас есть Database Options Details.
AcidMan,
ОтветитьУдалить6 месяцев - это нормально. Вам позвонят сразу после нового года :)))))
Dima, could you tell us what DBUG abbreviation stands for?
ОтветитьУдалитьWell, it is abbreviation for DataBase UpGrade. Migration is the term dedicated for migration to Oracle from others platforms, for example Microsoft SQL Server. Our event for this moment at least, is just about Upgrade.
ОтветитьУдалитьBut, for sales, marketing, and head staff people it easy to remember some fanny phrase - mir-rat-ion is more suitable for this. This simplify justification for visit out event for technical people.
The other reason i have in my memory, all other our events have 4-letter abbreviation, starting from D letter. D mean Danilov of course :) So i just continue this tradition.
Hope this help.
Добрый вечер, Дмитрий.
ОтветитьУдалитьСегодня на MIG-RAT-ION я обещал выслать логи от попытки мигрировать схему из 10g в 11g.
Вводная. Делается попытка сделать миграцию схемы примерно с 200 гигабайтами данных. Source - 10.2.0.3 (CP1251), destination - 11.1.0.7 (UTF8).
Метод exp-imp. Экспорт делает файл на 54 гигабайта, при попытке импорта где-то "в середине файла" получаю следующее:
IMP-00058: ORACLE error 12152 encountered
ORA-12152: TNS:unable to send break message
IMP-00058: ORACLE error 3114 encountered
ORA-03114: not connected to ORACLE
IMP-00000: Import terminated unsuccessfully
При попытке сделать impdp через network link (impdp запущен, разумеется, с 11.1.0.7), получаю следующее:
Processing object type SCHEMA_EXPORT/SYNONYM/SYNONYM
ORA-39126: Worker unexpected fatal error in KUPW$WORKER.UNLOAD_METADATA [SYNONYM:"MES"."CSYS_AUDIT"]
ORA-06502: PL/SQL: numeric or value error
ORA-02063: preceding line from MESSKU
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95
ORA-06512: at "SYS.KUPW$WORKER", line 7839
----- PL/SQL Call Stack -----
object line object
handle number name
0x3a0acc64 18237 package body SYS.KUPW$WORKER
0x3a0acc64 7866 package body SYS.KUPW$WORKER
0x3a0acc64 2744 package body SYS.KUPW$WORKER
0x3a0acc64 8504 package body SYS.KUPW$WORKER
0x3a0acc64 1545 package body SYS.KUPW$WORKER
0x35d89444 2 anonymous block
ORA-39126: Worker unexpected fatal error in KUPW$WORKER.UNLOAD_METADATA [SYNONYM:"MES"."CSYS_AUDIT"]
ORA-06502: PL/SQL: numeric or value error
ORA-02063: preceding line from MESSKU
ORA-06512: at "SYS.DBMS_SYS_ERROR", line 95
ORA-06512: at "SYS.KUPW$WORKER", line 7839
----- PL/SQL Call Stack -----
object line object
handle number name
0x3a0acc64 18237 package body SYS.KUPW$WORKER
0x3a0acc64 7866 package body SYS.KUPW$WORKER
0x3a0acc64 2744 package body SYS.KUPW$WORKER
0x3a0acc64 8504 package body SYS.KUPW$WORKER
0x3a0acc64 1545 package body SYS.KUPW$WORKER
0x35d89444 2 anonymous block
Job "SYSTEM"."SYS_IMPORT_SCHEMA_09" stopped due to fatal error at 20:48:52
Магическое version=10.2.0 в строку impdp не помогает абсолютно.
Вся надежда на штатный upgrade, который в общем тоже не идеален, ибо сначала надо мигрировать на 10.2.0.4 и после этого перетестировать приложение, не отъехало ли что...
Проблема 1. expdp через db link лечится в 10.2.0.4 или не используйте db link - просто в файл сложите.
ОтветитьУдалитьПроблема 2. impdp c 11.1 на 10.2 - согласно 553337.1 это не supported, или я чего-то не понимаю ?
Я бы делал эту процедуру так 10.2 -> 10.2 UTF8 (alter database)) -> 10.2.0.4 (opatch) -> 11.1 (dbua)
Дмитрий, спасибо за комментарий.
ОтветитьУдалитьНасчет проблемы 2 - возможно, я неверно выразился или неточно объяснил. В базе 11.1 (target) сделан network link на базу 10.2 (source), после чего я запускаю impdp 11.1, соединяюсь с базой 11.1 и пытаюсь сделать импорт схемы через network link, который указывает на 10-ю базу. Думаю, такое все-таки supported.
Попробую нескольькими путями. Попробую сделать штатный dbua, правда не всегда возможно патчить базу и потом мигрировать - заказчик боится миграции на 11 версию, а разработчики боятся ухудшения скорости работы приложения при миграции на 10.2.0.4. Надо будет за раз делать один большой "прыжок" 10.2.0.3-10.2.0.4-11.1.0.7, с обязательным тестированием.
Тем не менее, попытки "вытащить" схему через impdp не прекращу. Попробую разве что сделать базу для target в такой же кодировке как source. Должно работать - значит должно работать.
Спасибо.