:: Не фоксом единым
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Игорь, большое тебе спасибо!
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Извиняюсь, опять хотелось бы разъяснений.
Неполное восстановление SCN.
Database Backup and Recovery Reference
Example 3-35 Performing Incomplete Recovery to a Specified SCN
This example, which assumes a mounted database, recovers the database up to (but not including) the specified SCN:
STARTUP FORCE MOUNT
RUN
{
SET UNTIL SCN 1418901; # set to 1418901 to recover database through SCN 1418900
RESTORE DATABASE;
RECOVER DATABASE;
}
ALTER DATABASE OPEN RESETLOGS;
SCN номер берем из:
SELECT CURRENT_SCN FROM v$database;
?
До того как начинаем неправильные действия делать ? И хотим откатить назад.



Исправлено 1 раз(а). Последнее : ВладимирС, 16.05.17 13:28
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Смотря что "откатывать"... Проще не коммитить "неправильные действия", нежели заниматься восстановлением БД. А если без коммита никак, то проще использовать flashback database чем полновесный recovery.
А уж где взять SCN - ну можно и "зафиксировать" его на какой-то момент времени из того же v$database. Только надо понимать что это абсолютно глобальный временнОй счётчик - он отслеживает ВСЮ активность в БД, не только работу одной какой-то сессии...


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Igor Korolyov
Смотря что "откатывать"... Проще не коммитить "неправильные действия", нежели заниматься восстановлением БД. А если без коммита никак, то проще использовать flashback database чем полновесный recovery.
А уж где взять SCN - ну можно и "зафиксировать" его на какой-то момент времени из того же v$database. Только надо понимать что это абсолютно глобальный временнОй счётчик - он отслеживает ВСЮ активность в БД, не только работу одной какой-то сессии...
Тогда расскажу цель:
Предистория...
Как я ранее сообщал, что мы у заказчика ИНОГДА делаем ДЕПЛОЙ (накатывания всего нового и тестирование) ночью, чтобы он утром уже работал с норамальным приложением, которое нормально работает с БД.
У заказчика имеет место БД PRIMARY и STANDBY.
У нас для тестирования наших разработок работаем без STANDBY.
Накатывание новых скриптов заказчику делаем через LIQUIBASE.
Конечно у себя проверяем накатывание тоже через LIQUIBASE.
Времени на проведение ДЕПЛОЯ довольно значительное. И нехочется чтобы утром заказчик плохо работал.
Вот и решено перед ДЕПЛОЕМ сделать как бы точку восстановления. Вдруг что-то пойдет не так, чтобы было откатиться.
Рассматриваются варианты:
1. BackUp и откатывание
2. Гарантированная точка восстановления
3. Отключение STANDBY.

Отключение STANDBY - удобно, быстро, но в случае чего потребуется пересоздавать стендбай. Что нехорошо.
Гарантированная точка восстановления - удобно, перед ДЕПЛОЕМ потребуется время на ее создание (чего не хочется терять), и если ДЕПЛОЙ включает в себя большую миграцию данных (много реду сгенерируется), то может занять много места на диске под архивлоги.
BackUp и откатывание - удобная и не жрущая ресурсов, но откатываться возможно будет долго (но это только время админа, а не всего коллектива).

Решил попробовать "BackUp и откатывание" на нашей тестовой БД (но она без STANDBY).
Конечно весь ДЕПЛОЙ мне не провести. НО.
Сделал небольшой объем работ с созданием таблицы в схеме, заполнению данных в ней. Создание процедур и функций... ну и заполнение новых табличек с помощью их.
Как бы моделирование небольшого деплоя.
Ну и с помощью скрипта откатилось нормально, за 8 минут
RMAN> RUN
2> {set until time "to_date('16.05.2017 09:00:00','dd.mm.yyyy HH24:MI:SS')";
3> restore database;
4> recover database;
5> }
....
RMAN> ALTER DATABASE OPEN RESETLOGS;
И сомнения возникли... А не надежнее делать откатывание по SCN. Но где его взять ? Вот и возник у меня вопрос...
И еще вопрос: надо ли проводить откатывание на STANDBY ? Или оракл сам на STANDBY откатывание проведет ? в чем я сомневаюсь, т.к. работы через RMAN.
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Почитал про LIQUIBASE - там же есть свои возможности для отката Конечно, по сути это будут "компенсирующие SQL-и" со всеми вытекающими последствиями, но в принципе должно работать. И даже (если аккуратно всё прописано) может работать ПОСЛЕ того как пользователь попользовался новой БД и выкатил претензии и требование "вернуть всё взад". С любого рода бэкапом это, конечно, невозможно провернуть.

Что ты имеешь в виду под "Гарантированная точка восстановления" я не понимаю... Полный или инкрементный бэкап выполняемые перед проведением деплоя, и его восстановление "если чо" - это понятно.
И про "отключение STANDBY" не понял. Смысл в том чтобы если будет бида-бида просто перейти на этот стендбай? А primary потом восстанавливать? Ну да тут я тебе вообще ничего не подскажу, т.к. со стендбаями и вообще кластерами не работал

ВладимирС
И сомнения возникли... А не надежнее делать откатывание по SCN.
Так оракл всегда делает "частичное" восстановление по SCN (т.к. только SCN обеспечивает "согласованность" данных. НО SCN, если сильно упростить, присваивается ПОСЛЕ фиксации транзакции. Обычно это не проблема, т.к. в БД постоянно столько всякого происходит, включая принудительные чекпоинты, что SCN растёт постоянно - даже без участия пользовательских процессов. Т.е. "текущий SCN", хоть и присвоен уже некоторое время назад, но по абсолютному значению времени будет ну очень близок к тому SCN который оракл для очередной транзакции назначит). Оракл просто вычисляет "примерное" SCN соответствующее заданному времени (в определённых системных таблицах отслеживается процесс использования SCN-ов - в зависимости от версии это доступно через функции TIMESTAMP_TO_SCN/SCN_TO_TIMESTAMP или через системное представление smon_scn_time). Полагаю что RMAN нечто подобное использует для вычисления "соответствия" заданного времени и SCN. Потому и пишется везде что это "примерное время". Судя по докам временнАя разбежка (т.е. степень "примерности") не должна превышать 5 минут, а для более новых версий оракла и вовсе 3-х секунд.

ВладимирС
надо ли проводить откатывание на STANDBY?
Увы, не в курсе - кури доки.


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Igor Korolyov
Почитал про LIQUIBASE - там же есть свои возможности для отката ...
Да во многих случаях можно провести откат. Но есть случаи, в которых не всегда его можно поставить,
например выполнение процедуры из пакета, а там черти что написано, и удаление и ....
execute immediate <Выполнение процедуры из пакета>
--rollback not required
т.е. при возможном откате мы его пропускаем...
или удаление записей из таблицы, в которой имеют место связки с другими таблицами по CONSTRAINT причем каскадно...
DELETE FROM <Таблица> WHERE ....
--rollback not required
т.е. при возможном откате мы его пропускаем...
Поэтому используем LIQUIBASE только в одном направлении.

Igor Korolyov
Что ты имеешь в виду под "Гарантированная точка восстановления" я не понимаю...
из книги
Обычная точка восстановления предоставляет удобный способ для указания предыдущего SCN-номера или момента во времени при выполнении операции ретроспективного отката или восстановления.
Однако она не гарантирует, что база данных будет хранить все журналы Flashback Database, необходимые для успешного проведения операции ретроспективного отката базы данных при любых обстоятельствах.
Поэтому помимо обычной еще также разрешено создавать и гарантированную точку восстановления (guaranteed restore point), которая точно гарантирует возможность отката базы данных до указанного в ней SCN-номера или времени.
SQL> CREATE RESTORE POINT test_guarantee GUARANTEE FLASHBACK DATABASE;
Может быть ее и надо использовать. Но пока она будет строиться, коллектив будет сидеть и ждать.

Igor Korolyov
Так оракл всегда делает "частичное" восстановление по SCN (т.к. только SCN обеспечивает "согласованность" данных. НО SCN, если сильно упростить, присваивается ПОСЛЕ фиксации транзакции. Обычно это не проблема, т.к. в БД постоянно столько всякого происходит, включая принудительные чекпоинты, что SCN растёт постоянно - даже без участия пользовательских процессов. Т.е. "текущий SCN", хоть и присвоен уже некоторое время назад, но по абсолютному значению времени будет ну очень близок к тому SCN который оракл для очередной транзакции назначит). Оракл просто вычисляет "примерное" SCN соответствующее заданному времени (в определённых системных таблицах отслеживается процесс использования SCN-ов - в зависимости от версии это доступно через функции TIMESTAMP_TO_SCN/SCN_TO_TIMESTAMP или через системное представление smon_scn_time). Полагаю что RMAN нечто подобное использует для вычисления "соответствия" заданного времени и SCN. Потому и пишется везде что это "примерное время". Судя по докам временнАя разбежка (т.е. степень "примерности") не должна превышать 5 минут, а для более новых версий оракла и вовсе 3-х секунд.
Прочитаю еще раз про SCN...

Igor Korolyov
И про "отключение STANDBY" не понял. Смысл в том чтобы если будет бида-бида просто перейти на этот стендбай? А primary потом восстанавливать?
Да, primary потом сделать STANDBY-ем. Ну это я так представляю. Т.е. куча работы.

Igor Korolyov
ВладимирС
надо ли проводить откатывание на STANDBY?
Увы, не в курсе - кури доки.
Бум курить...


Исправлено 1 раз(а). Последнее : ВладимирС, 18.05.17 08:58
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
ВладимирС
Да во многих случаях можно провести откат. Но есть случаи, в которых не всегда его можно поставить
Ну это да, это вполне естественно
ВладимирС
Igor Korolyov
Что ты имеешь в виду под "Гарантированная точка восстановления" я не понимаю...
SQL> CREATE RESTORE POINT test_guarantee GUARANTEE FLASHBACK DATABASE;
Может быть ее и надо использовать. Но пока она будет строиться, коллектив будет сидеть и ждать.
А, ну да, я ж про flashback database писал, не понял что ты так это дело обозвал - по начальному шагу а не конечному
Как я понимаю, это НЕ занимает практически никакого времени для "создания" (по сути это вариант просто поименовать последний созданный SCN - ну или даже создать новый, хз как оно там реализовано внутри, чтобы не записывать его "на бумажку" для последующих целей отката). Ну и в версии "с гарантией" сервер просто не будет очищать flashback информацию в соответствии со своими настройками (т.е. распухнуть "область восстановления" может неиллюзорно, если деплой породит большой объём изменений в БД). Опять же есть вопросы административного характера - и физический размер этой самой области, и права на flashback да и вообще возможность делать такой "глобальный откат"...
Но если вопросы решаемы, то это IMHO всяко быстрее/лучше восстановления из дампа


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Игорь, спасибо за направление... FLASHBACK - надо смотреть в этом направлении. Надеюсь STANDBY примет все толкования работ что в PRIMARY.
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
У меня еще вопрос-проблема...
Для дальнейшего тестирования системы, использую снятие дампа нужных схем с боевого сервера и перенос дампа на наш тестовый сервер, с последующим его разворачиванием. При этом использую утилиты expdp/impdp.
Но на тестовом сервере не одна БД вертится... И на нем получается нехватка места в разделе /u01...
Я конечно попросил, чтобы увеличили раздел. Но видимо места больше НЕТ, да и начальство с кем-то посоветовалось. Короче предложили следующее. Из сообщения:
цитата
Вобщем есть пакет dbms_datapump, который в том числе умеет и работать через дблинки, не создавая физических файлов дампов.
Т.е. место под дампы как бы и не требуется.
Вот такое решение мне предложили.
Конечно пакетом ранее пользовался для создания дампа из процедуры с последующим созданием JOB-а. Но было замечено, что создается не полный лог дампа. И я эту затею бросил и использую утилиты expdp/impdp, которые с моей точки зрения более надежны.
Но как говорится приказ есть приказ, и надо рассмотреть выше предложенный случай.
Почитать бы где-то работу пакета dbms_datapump используя его на тестовом сервере, а работать через дблинки с боевым сервером, не создавая физических файлов дампов...

Нашел что-то :
Datapump with Database Link examples

Тихо сам с собою...
Хм... Сейчас размер TABLESPACE USERS 205Gb (здесь все наши схемы)... И это все будет тянуться через сетку. Это сколько времени надо будет ? А zip дампа весит всего 23Gb.
Да, его распаковывать надо будет и импортировать схемы.



Исправлено 3 раз(а). Последнее : ВладимирС, 26.06.17 11:48
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
ВладимирС
Тихо сам с собою...
Любая подобная информация полезна Я не работал с этим, т.к. у нас физически сервера продуктива и наши тестовые/девелоперские не связаны.
ВладимирС
Хм... Сейчас размер TABLESPACE USERS 205Gb (здесь все наши схемы)... И это все будет тянуться через сетку. Это сколько времени надо будет ?
На самом деле сам размер TS не говорит об объёме данных. Во-первых в TS может быть куча свободного места. Во-вторых в TS живут ещё и индексы, а их не надо перекачивать в дамп (они всё одно пересоздаются - берется только описание из метаданных). Конечно же если не используется механизм "транспортируемых TS" - но я полагаю что это не твой случай

Сколько займёт "физический" процесс трансфера 200Гб вопрос несложный. По свободной гигабитной сети - порядка получаса. Сколько займёт "времени CPU сервера" создание такого потока данных - это уже куда как сложнее вопрос. Полагаю что вполне может занять и БОЛЬШЕ чем полчаса.


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Igor Korolyov
ВладимирС
Тихо сам с собою...
Любая подобная информация полезна Я не работал с этим, т.к. у нас физически сервера продуктива и наши тестовые/девелоперские не связаны.
Нам просто заказчик в их сетке выделил сервер виртуальный для тестирования... Про него речь как бы.
Igor Korolyov
ВладимирС
Хм... Сейчас размер TABLESPACE USERS 205Gb (здесь все наши схемы)... И это все будет тянуться через сетку. Это сколько времени надо будет ?
На самом деле сам размер TS не говорит об объёме данных. Во-первых в TS может быть куча свободного места. Во-вторых в TS живут ещё и индексы, а их не надо перекачивать в дамп (они всё одно пересоздаются - берется только описание из метаданных). Конечно же если не используется механизм "транспортируемых TS" - но я полагаю что это не твой случай
Про дыры как бы помним...
select ROUND(SUM(BYTES)/1024/1024/1024, 1) "SIZE (GB)"
from dba_segments
where TABLESPACE_NAME in ('USERS')
205.4Gb Я понимаю, что и сегмент не полностью м.б. заполнен. Но как бы это ориентир.
Индексы в дампах как бы живут в метаданных...
Igor Korolyov
Сколько займёт "физический" процесс трансфера 200Гб вопрос несложный. По свободной гигабитной сети - порядка получаса. Сколько займёт "времени CPU сервера" создание такого потока данных - это уже куда как сложнее вопрос. Полагаю что вполне может занять и БОЛЬШЕ чем полчаса.
Т.е. меня интересует, что я могу не вписаться в отведенное для дампа время. Мне дано полчаса. Потом JOB-ы пойдут работать...
А так, на боевом сервере, я дамп в 4 потока делаю. И то идет 30 минут. Потом зипую файлы. Ну а потом, не мешая работе, на следующий день я по сетке кидаю зипованный файл на тестовый сервер и далее работа...



Исправлено 1 раз(а). Последнее : ВладимирС, 26.06.17 15:08
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Полагаю что за полчаса ты даже в варианте "локального" хранилища для дампа можешь не управиться
А в чём проблема то - дамп вроде как можно делать в "согласованном" режиме - т.е. запустил процесс и всё - делай дальше с БД что угодно - процесс создания дампа этого не увидит - будет работать с той копией данных (и метаинформации тоже) которая существовала на момент запуска. Лишь бы хватило места в undo для хранения ДО-образов блоков.

Я как-то увеличивал даже специально undo_retention, а то наш обычный клиентский (даже не datapump) дамп не успевал создаться за 2 часа (и это ночью, с минимальной активностью в БД). Ну и вылетал по известной snapshot too old


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Igor Korolyov
...дамп вроде как можно делать в "согласованном" режиме - т.е. запустил процесс и всё - делай дальше с БД что угодно - процесс создания дампа этого не увидит - будет работать с той копией данных (и метаинформации тоже) которая существовала на момент запуска....
Хм... и как запустить дамп в согласованном режиме ?
Я просто создаю дамп в специально отведенное окно времени, когда пользователи не работают и JOB-ы еще не начали работать (время работы 31 мин.). Но один сервис работает все время... При создании дампа ошибок в логе не показывает (да и понятно почему, CONSTRAINT прописаны в метабазе). А вот при импорте выскакивает всегда ошибка:
ORA-02298: cannot validate (ZAGS_EXTERNAL_DATA.FK_LNK_SOAP_REQUEST) - parent keys not found
Failing sql is:
ALTER TABLE "ZAGS_EXTERNAL_DATA"."LNK_SOAP_CERTIFICATES_REQUEST" ADD CONSTRAINT "FK_LNK_SOAP_REQUEST" FOREIGN KEY ("ID_REQUEST") REFERENCES "ZAGS_EXTERNAL_DATA"."T_SOAP_LOG" ("ID") ENABLE
Это как раз из-за работы сервиса.
Т.к. на тестовом сервере эти данные нас особо не интересуют, то я удаляю несоответсвующие данные. И CONSTRAINT создаю заново. Т.к. на тестовом сервере сервис тоже работает и его работу тестируют.
Кстати из лога импорта:
Цитата:
Import: Release 11.2.0.3.0 - Production on Thu Jun 22 08:08:15 2017
....
Job "SYSTEM"."SYS_IMPORT_FULL_01" completed with 1 error(s) at 12:33:27
Видим, что импорт длится в пределах 4.5 часов...
А вот теперь возможна проблема:
Пусть начал работу создания/переноса схем через дблинк. И если принять во внимание, что работа будет продолжаться в течении 4.5 часов, то вероятность целостности данных очень будет мала и ошибок на CONSTRAINT повалится скорее всего куча. Главное что это очень плохо будет, да и разгребать их - практически невозможно. Схемы здоровые на количество таблиц и соответсвенно на связи.
Да и где такое окно по времени взять.



Исправлено 7 раз(а). Последнее : ВладимирС, 27.06.17 07:10
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
ВладимирС
Хм... и как запустить дамп в согласованном режиме ?
FLASHBACK_* параметр задать для этого джоба (один из 2 возможных). Но почитай прежде про undo_retention - иначе сам экспорт может "слететь" из-за того что к его окончанию сервер выкинет "слишком старые" блоки undo, а без них согласованное состояние "на момент начала процесса" не получить. Ну и, естественно, если правится это самое время, то может быть надо и размер undo пространств подкорректировать - чтобы хватило места эту самую "информацию отката" держать.
ВладимирС
А вот теперь возможна проблема:
Да, если весь процесс будет растягиваться на 4-5 часов - это проблема. Либо придётся "играться" с undo_retention - ставя его на 5 часов лишь на время создания дампа, либо прилично так раздувать undo-пространство, чтобы и в "рабочее время" его хватало на хранение 5 часов "данных отката".
Может быть проще будет делить сам процесс создания дампа на более мелкие части - по несколько связанных схем "за раз". Конечно это не даст возможности иметь согласованные данные (а значит и включаемые без ошибок констрейны) между разными такими наборами/подсистемами. Т.е. не факт что это применимо к вашей реальной ситуации...


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Спасибо за ответ...
Похоже этот вариант не подойдет.
Большие риски чего-либо... И это на боевом сервере. Да нас просто убьют за это. В договоре прописаны такие большие штрафные санкции, что мама не горюй.
Предложу руководству на наш сервер кидать дамп с боевого сервера (что долго по времени, да и дальнейшее импортирование). Но по кране мере сбоя на боевом сервере из-за наших хотелок не будет.

Конечно, я не такой профи как ты.
Как я понимаю, надо будет FLASHBACK еще включать. А его включение будет, по-моему, на заполнение области FRA влиять, в сторону его увеличения.

Хотя часть инфы от тебя мне непонятны:
Igor Korolyov
Да, если весь процесс будет растягиваться на 4-5 часов - это проблема. Либо придётся "играться" с undo_retention - ставя его на 5 часов лишь на время создания дампа, либо прилично так раздувать undo-пространство, чтобы и в "рабочее время" его хватало на хранение 5 часов "данных отката".
Хм... Я ничего ведь откатывать не собираюсь. Из-за чего может понадобится откат ?
Igor Korolyov
Может быть проще будет делить сам процесс создания дампа на более мелкие части - по несколько связанных схем "за раз". Конечно это не даст возможности иметь согласованные данные (а значит и включаемые без ошибок констрейны) между разными такими наборами/подсистемами. Т.е. не факт что это применимо к вашей реальной ситуации...
Дык это как раз все наши схемы... Они связаны между собой. Я как-то ранее об этом писал. Но это не моя идея была (делать множество схем, причем таблицы связаны между схемами). Я об это руководству говорил.
Но прочитать про все это мне надо. Как то надо показать руководству, что этот путь тернист и возможны риски.
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
ВладимирС
Хм... Я ничего ведь откатывать не собираюсь. Из-за чего может понадобится откат ?
Так версионник обеспечивает согласованность данных - когда идёт запрос блока который уже изменён транзакцией и даже зафиксирован, а нам нужно его состояние "на 0:00" - т.к. именно тогда стартовал наш "долгоиграющий" запрос, или началась транзакция в режиме Serializable (т.е. как раз то что и нужно для "полностью согласованного снимка данных" - но уже на время нескольких запросов а не одного).

P.S. Мне всегда казалась насколько странной идея таскать на тест/дев базы ПОЛНУЮ копию продуктива (я вообще выступаю за СПЕЦИАЛЬНЫЙ тестовый набор данных - или даже не один такой набор). Для изоляции бага нужен тесткейс, а не "живые данные" с этим багом... Но увы - у нас тоже не могут без этого... Т.к. помимо вылова косяков своего кода ещё и зачастую занимаются выловом косяков "тупых юзеров" невесть что невесть куда навводивших и не могущих концы с концами свести...

P.P.S. Я ещё сложнее дамп делаю - т.к. в структуре есть под 50Гб данных блобов со всякой не нужной для работы чухнёй (документы/принтформы/картинки - их все замечательно заменяет 10Кб файл-заглушка с буковками типа "реальные данные только на продуктиве, а тут вам не там!"), то приходится сначала делать дамп "только таблиц", при том за исключением таблиц с блобами - потом генерится dat файл для sqlldr с id, name ну и прочими не-LOB реквизитами этих таблиц документов (т.к. связи то на них есть по любому - "пустыми" нельзя оставить), а потом ещё один дамп уже "чисто по структурам" - чтобы вью/хп/констрейны воссоздать. И потому проблему
DELETE FROM DOCUMENT_RELATION
WHERE DOCUMENT_ID NOT IN (SELECT ID FROM DOCUMENT) OR
RELATED_DOCUMENT_ID NOT IN (SELECT ID FROM DOCUMENT);
...
Прекрасно себе представляю...

P.P.P.S. У нас процесс заливки сильно осложняли:
1) Автостартующие/регулярные джобы - они начинают колбасить таблицы ещё до того как завершится заливка, построятся и проанализируются индексы - и даже елси сами по себе "сломаются", но 100% нагрузки на сервер могут дать на полчаса а то и больше. Т.к. это были "старые добрые job" решил вопрос просто вручную создавая "выключенные" job с теми же id-номерами. Да, это лишние 3-4 ошибки в логе загрузки, но что поделать...
2) Собственно вышеуказанные DELETE - при их выполнении над "свежезалитыми" таблицами без индексов можно было "курить" часа 3-4. Потому в этом скрипте delete_extra_records.sql вначале создаются абсолютно нужные этим запросам индексы, и проводится "анализ" (сбор статистики) по участвующим таблицам.

Конечно, это вряд-ли всё применимо напрямую при заливке FULL дампа. У нас то это обычный "пользовательский" дамп всего нескольких схем... Но может какие идеи и пригодятся.


------------------
WBR, Igor




Исправлено 1 раз(а). Последнее : Igor Korolyov, 27.06.17 16:18
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Игорь, спасибо тебе за ответы, советы...
Отвечу, почему нам надо полную копию продуктива?
У нас тяжелые отношения с заказчиком. Заказчик ранее использовал и во многих местах использует старый продукт. Мы влезли и предложили свое детище. Внедрили свой продукт порядка в 150 отделах. Все данные у нас хранятся в одном месте. Но другие отделы работают на старом продукте и предыдущий исполнитель делал софт (БД mssql), что данные отдела хранятся в отделах и с периодичностью кидают на общий сервер. Там делаются отчеты. Наша концепция, сразу на одном сервере все данные. Но, как я и указал, только часть отделов перешло на наше ПО. Приходится ежедневно экспортировать записи, сделанные у нас, в старую систему. Сделан сервис у нас. Но и их данные сделанные на старом ПО должные перекочевать в нашу систему. То же сделан сервис. И возможен (да он и есть) случай, что записи сделанные в одном ПО качуют в другое и потом обратно возвращаются в наше. Это надо отлавливать и не допускать повтора. Да и записи сделанные в старом ПО при кочевании в наше ПО имеют ошибки. Их тоже отлавливаем, отсылаем обратно. Короче муторная работа. Ну и для правильного анализа всего этого, нам нужен полный дамп на тест и анализ как нашей отправки данных, так и приход их данных.
Тут сделал маленький эксперимент.
Вот такой есть результат...Может и хреновый анализ, но я хочу его отдать.
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
Igor Korolyov

Сообщений: 34580
Дата регистрации: 28.05.2002
Единственное замечание - при тесте на 1 физическом сервере (даже если это 2 отдельных виртуальных сервера) может оказаться ОЧЕНЬ узким местом CPU и дисковая подсистема - т.е. надо сопровождать такой тест анализом/контролем загрузки CPU/Storage.
Впрочем, я полагаю что в любом случае работа через dblink будет не быстрее чем дамп в файл. А по поводу "места для дампа" - что мешает подключить к обоим серверам быстрый сетевой диск? Исключается и забивание основного диска сервера, и затраты на "копирование" дампа...


------------------
WBR, Igor
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Спасибо за замечание, учту.
Igor Korolyov
что мешает подключить к обоим серверам быстрый сетевой диск?
Самое главное, когда начинали, именно к продуктиву серверу и был подключен сетевой диск. Я туда складывал дампы, причем автоматически в имя файла вписывался день. Дампы держались неделю. Потом самый старый удалялся и замещался вновь пришедшим. Но потом, что-то они отсоединили его и теперь единственный/ежедневный дамп хранится в основном разделе. Да и ихние BackUp-ы тоже смотрю хранятся в основном разделе. Конечно может их дублируют в другие места, но я об это не знаю.
Ratings: 0 negative/0 positive
Re: Oracle. Администрирование.
ВладимирС
Автор

Сообщений: 1693
Дата регистрации: 03.11.2005
Спрошу в этом топике, хотя уже вопрос не про администрирование, но по ораклу.
Прикрепили к другому проекту...
И вот проблема вытащить данные через dblink...
Поставили задачу, вытаскивать данные с другого сервера...
Сначала просто составлял запросы в которых join-ил таблицы через dblink. Но вижу, что это идеологически неправильно, т.к. на сервере с которого запускаю такой запрос выполняется очень долго, если таблицы большие. План создастся не может... вытаскивание скорее всего всех данных из таблиц dblink-а... Ну и соответственно зависание.

Решил на dblink-овском сервере создать пакет и в нем процедуру которая на выходе выдает курсор. типа:
CREATE OR REPLACE package EGRIP_IMPORT.egrip_view is
-- Данные о ИП с разбивкой по ОГРНИП
procedure get_ogrnip_info(p_inn varchar2, p_cursor out sys_refcursor);
end;
/
CREATE OR REPLACE package body EGRIP_IMPORT.egrip_view is
-- Данные о ИП с разбивкой по ОГРНИП
procedure get_ogrnip_info(p_inn varchar2,p_cursor out sys_refcursor) is
begin
open p_cursor for
select ...
...
...
where eg.INNFL = p_inn
)
order by to_date(OGRNIP_DATE, 'dd.mm.yyyy') desc;
end;
end;
/
Протестировал на dblink-овском сервере:
DECLARE
p_inn varchar2(50) := '772976281908';
BEGIN
egrip_view.get_ogrnip_info(p_inn,:p_cursor);
END;
Все работает ОК.
Решил с другого сервера вытащить данные этого курсора через dblink (мне же эти данные нужны на боевом сервере):
DECLARE
p_inn varchar2(50) := '771603983483';
BEGIN
egrip_view.get_ogrnip_info@EGRIPDB(p_inn,:p_cursor);
END;
ORA-24338: указатель оператора не выполнен
Да не тут-то и было...
Порыскал в инете:
Tom Kyte
refcursors may not be returned over a dblink

Решил попробовать создать табличную функцию и вытащить ее тоже через dblink
(в надежде, что в табличную функцию впихну результаты курсора)
создаю на dblink-овском сервере к которому буду обращаться:
CREATE OR REPLACE package EGRIP_IMPORT.p_test is
type test_rowGet is record (fnum numeric, fvar varchar2(100 char), fdate date);
type test_table is table of test_rowGet;
function get_test_table RETURN test_table pipelined;
end;
CREATE OR REPLACE PACKAGE BODY EGRIP_IMPORT.p_test
AS
function get_test_table RETURN test_table pipelined
is
begin
for curr in
(
---- fnum numeric, fvar varchar2(100 char), fdate date
select 12 as fnum, 'qwerqwerqwer' as fvar, to_date('12.01.2017','dd.mm.yyyy') as fdate from dual
union all
select 4 as fnum, 'zxcvzxvzxv' as fvar, to_date('05.01.2014','dd.mm.yyyy') as fdate from dual
)
loop pipe row(curr);
end loop;
end;
end;
Тестирую:
SELECT * FROM TABLE(P_TEST.get_test_table);
Работает, все ок.

Но если ее вызвать через dblink с другого сервера
SELECT * FROM TABLE(P_TEST.get_test_table@EGRIPDB);
ORA-06553: PLS-752: Табличная функция GET_TEST_TABLE находится в противоречивом состоянии.
Как вытащить данные ?



Исправлено 1 раз(а). Последнее : ВладимирС, 28.09.17 08:11
Ratings: 0 negative/0 positive


Извините, только зарегистрированные пользователи могут оставлять сообщения в этом форуме.

On-line: 15 (Гостей: 15)

© 2000-2024 Fox Club 
Яндекс.Метрика