Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Игорь, большое тебе спасибо!
|
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Извиняюсь, опять хотелось бы разъяснений.
Неполное восстановление SCN. Database Backup and Recovery Reference
До того как начинаем неправильные действия делать ? И хотим откатить назад. Исправлено 1 раз(а). Последнее : ВладимирС, 16.05.17 13:28 |
Re: Oracle. Администрирование. | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Смотря что "откатывать"... Проще не коммитить "неправильные действия", нежели заниматься восстановлением БД. А если без коммита никак, то проще использовать flashback database чем полновесный recovery.
А уж где взять SCN - ну можно и "зафиксировать" его на какой-то момент времени из того же v$database. Только надо понимать что это абсолютно глобальный временнОй счётчик - он отслеживает ВСЮ активность в БД, не только работу одной какой-то сессии... ------------------ WBR, Igor |
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Тогда расскажу цель: Предистория... Как я ранее сообщал, что мы у заказчика ИНОГДА делаем ДЕПЛОЙ (накатывания всего нового и тестирование) ночью, чтобы он утром уже работал с норамальным приложением, которое нормально работает с БД. У заказчика имеет место БД PRIMARY и STANDBY. У нас для тестирования наших разработок работаем без STANDBY. Накатывание новых скриптов заказчику делаем через LIQUIBASE. Конечно у себя проверяем накатывание тоже через LIQUIBASE. Времени на проведение ДЕПЛОЯ довольно значительное. И нехочется чтобы утром заказчик плохо работал. Вот и решено перед ДЕПЛОЕМ сделать как бы точку восстановления. Вдруг что-то пойдет не так, чтобы было откатиться. Рассматриваются варианты: 1. BackUp и откатывание 2. Гарантированная точка восстановления 3. Отключение STANDBY. Отключение STANDBY - удобно, быстро, но в случае чего потребуется пересоздавать стендбай. Что нехорошо. Гарантированная точка восстановления - удобно, перед ДЕПЛОЕМ потребуется время на ее создание (чего не хочется терять), и если ДЕПЛОЙ включает в себя большую миграцию данных (много реду сгенерируется), то может занять много места на диске под архивлоги. BackUp и откатывание - удобная и не жрущая ресурсов, но откатываться возможно будет долго (но это только время админа, а не всего коллектива). Решил попробовать "BackUp и откатывание" на нашей тестовой БД (но она без STANDBY). Конечно весь ДЕПЛОЙ мне не провести. НО. Сделал небольшой объем работ с созданием таблицы в схеме, заполнению данных в ней. Создание процедур и функций... ну и заполнение новых табличек с помощью их. Как бы моделирование небольшого деплоя. Ну и с помощью скрипта откатилось нормально, за 8 минут
И еще вопрос: надо ли проводить откатывание на STANDBY ? Или оракл сам на STANDBY откатывание проведет ? в чем я сомневаюсь, т.к. работы через RMAN. |
Re: Oracle. Администрирование. | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Почитал про LIQUIBASE - там же есть свои возможности для отката Конечно, по сути это будут "компенсирующие SQL-и" со всеми вытекающими последствиями, но в принципе должно работать. И даже (если аккуратно всё прописано) может работать ПОСЛЕ того как пользователь попользовался новой БД и выкатил претензии и требование "вернуть всё взад". С любого рода бэкапом это, конечно, невозможно провернуть.
Что ты имеешь в виду под "Гарантированная точка восстановления" я не понимаю... Полный или инкрементный бэкап выполняемые перед проведением деплоя, и его восстановление "если чо" - это понятно. И про "отключение STANDBY" не понял. Смысл в том чтобы если будет бида-бида просто перейти на этот стендбай? А primary потом восстанавливать? Ну да тут я тебе вообще ничего не подскажу, т.к. со стендбаями и вообще кластерами не работал Так оракл всегда делает "частичное" восстановление по SCN (т.к. только SCN обеспечивает "согласованность" данных. НО SCN, если сильно упростить, присваивается ПОСЛЕ фиксации транзакции. Обычно это не проблема, т.к. в БД постоянно столько всякого происходит, включая принудительные чекпоинты, что SCN растёт постоянно - даже без участия пользовательских процессов. Т.е. "текущий SCN", хоть и присвоен уже некоторое время назад, но по абсолютному значению времени будет ну очень близок к тому SCN который оракл для очередной транзакции назначит). Оракл просто вычисляет "примерное" SCN соответствующее заданному времени (в определённых системных таблицах отслеживается процесс использования SCN-ов - в зависимости от версии это доступно через функции TIMESTAMP_TO_SCN/SCN_TO_TIMESTAMP или через системное представление smon_scn_time). Полагаю что RMAN нечто подобное использует для вычисления "соответствия" заданного времени и SCN. Потому и пишется везде что это "примерное время". Судя по докам временнАя разбежка (т.е. степень "примерности") не должна превышать 5 минут, а для более новых версий оракла и вовсе 3-х секунд. Увы, не в курсе - кури доки. ------------------ WBR, Igor |
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Да во многих случаях можно провести откат. Но есть случаи, в которых не всегда его можно поставить, например выполнение процедуры из пакета, а там черти что написано, и удаление и ....
или удаление записей из таблицы, в которой имеют место связки с другими таблицами по CONSTRAINT причем каскадно...
Поэтому используем LIQUIBASE только в одном направлении.
Прочитаю еще раз про SCN... Да, primary потом сделать STANDBY-ем. Ну это я так представляю. Т.е. куча работы. Бум курить... Исправлено 1 раз(а). Последнее : ВладимирС, 18.05.17 08:58 |
Re: Oracle. Администрирование. | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Ну это да, это вполне естественно А, ну да, я ж про flashback database писал, не понял что ты так это дело обозвал - по начальному шагу а не конечному Как я понимаю, это НЕ занимает практически никакого времени для "создания" (по сути это вариант просто поименовать последний созданный SCN - ну или даже создать новый, хз как оно там реализовано внутри, чтобы не записывать его "на бумажку" для последующих целей отката). Ну и в версии "с гарантией" сервер просто не будет очищать flashback информацию в соответствии со своими настройками (т.е. распухнуть "область восстановления" может неиллюзорно, если деплой породит большой объём изменений в БД). Опять же есть вопросы административного характера - и физический размер этой самой области, и права на flashback да и вообще возможность делать такой "глобальный откат"... Но если вопросы решаемы, то это IMHO всяко быстрее/лучше восстановления из дампа ------------------ WBR, Igor |
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Игорь, спасибо за направление... FLASHBACK - надо смотреть в этом направлении. Надеюсь STANDBY примет все толкования работ что в PRIMARY.
|
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
У меня еще вопрос-проблема...
Для дальнейшего тестирования системы, использую снятие дампа нужных схем с боевого сервера и перенос дампа на наш тестовый сервер, с последующим его разворачиванием. При этом использую утилиты expdp/impdp. Но на тестовом сервере не одна БД вертится... И на нем получается нехватка места в разделе /u01... Я конечно попросил, чтобы увеличили раздел. Но видимо места больше НЕТ, да и начальство с кем-то посоветовалось. Короче предложили следующее. Из сообщения: Т.е. место под дампы как бы и не требуется. Вот такое решение мне предложили. Конечно пакетом ранее пользовался для создания дампа из процедуры с последующим созданием JOB-а. Но было замечено, что создается не полный лог дампа. И я эту затею бросил и использую утилиты expdp/impdp, которые с моей точки зрения более надежны. Но как говорится приказ есть приказ, и надо рассмотреть выше предложенный случай. Почитать бы где-то работу пакета dbms_datapump используя его на тестовом сервере, а работать через дблинки с боевым сервером, не создавая физических файлов дампов... Нашел что-то : Datapump with Database Link examples Тихо сам с собою... Хм... Сейчас размер TABLESPACE USERS 205Gb (здесь все наши схемы)... И это все будет тянуться через сетку. Это сколько времени надо будет ? А zip дампа весит всего 23Gb. Да, его распаковывать надо будет и импортировать схемы. Исправлено 3 раз(а). Последнее : ВладимирС, 26.06.17 11:48 |
Re: Oracle. Администрирование. | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Любая подобная информация полезна Я не работал с этим, т.к. у нас физически сервера продуктива и наши тестовые/девелоперские не связаны. На самом деле сам размер TS не говорит об объёме данных. Во-первых в TS может быть куча свободного места. Во-вторых в TS живут ещё и индексы, а их не надо перекачивать в дамп (они всё одно пересоздаются - берется только описание из метаданных). Конечно же если не используется механизм "транспортируемых TS" - но я полагаю что это не твой случай Сколько займёт "физический" процесс трансфера 200Гб вопрос несложный. По свободной гигабитной сети - порядка получаса. Сколько займёт "времени CPU сервера" создание такого потока данных - это уже куда как сложнее вопрос. Полагаю что вполне может занять и БОЛЬШЕ чем полчаса. ------------------ WBR, Igor |
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Нам просто заказчик в их сетке выделил сервер виртуальный для тестирования... Про него речь как бы. Про дыры как бы помним...
Индексы в дампах как бы живут в метаданных... Т.е. меня интересует, что я могу не вписаться в отведенное для дампа время. Мне дано полчаса. Потом JOB-ы пойдут работать... А так, на боевом сервере, я дамп в 4 потока делаю. И то идет 30 минут. Потом зипую файлы. Ну а потом, не мешая работе, на следующий день я по сетке кидаю зипованный файл на тестовый сервер и далее работа... Исправлено 1 раз(а). Последнее : ВладимирС, 26.06.17 15:08 |
Re: Oracle. Администрирование. | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Полагаю что за полчаса ты даже в варианте "локального" хранилища для дампа можешь не управиться
А в чём проблема то - дамп вроде как можно делать в "согласованном" режиме - т.е. запустил процесс и всё - делай дальше с БД что угодно - процесс создания дампа этого не увидит - будет работать с той копией данных (и метаинформации тоже) которая существовала на момент запуска. Лишь бы хватило места в undo для хранения ДО-образов блоков. Я как-то увеличивал даже специально undo_retention, а то наш обычный клиентский (даже не datapump) дамп не успевал создаться за 2 часа (и это ночью, с минимальной активностью в БД). Ну и вылетал по известной snapshot too old ------------------ WBR, Igor |
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Хм... и как запустить дамп в согласованном режиме ? Я просто создаю дамп в специально отведенное окно времени, когда пользователи не работают и JOB-ы еще не начали работать (время работы 31 мин.). Но один сервис работает все время... При создании дампа ошибок в логе не показывает (да и понятно почему, CONSTRAINT прописаны в метабазе). А вот при импорте выскакивает всегда ошибка:
Т.к. на тестовом сервере эти данные нас особо не интересуют, то я удаляю несоответсвующие данные. И CONSTRAINT создаю заново. Т.к. на тестовом сервере сервис тоже работает и его работу тестируют. Кстати из лога импорта: Цитата:Видим, что импорт длится в пределах 4.5 часов... А вот теперь возможна проблема: Пусть начал работу создания/переноса схем через дблинк. И если принять во внимание, что работа будет продолжаться в течении 4.5 часов, то вероятность целостности данных очень будет мала и ошибок на CONSTRAINT повалится скорее всего куча. Главное что это очень плохо будет, да и разгребать их - практически невозможно. Схемы здоровые на количество таблиц и соответсвенно на связи. Да и где такое окно по времени взять. Исправлено 7 раз(а). Последнее : ВладимирС, 27.06.17 07:10 |
Re: Oracle. Администрирование. | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
FLASHBACK_* параметр задать для этого джоба (один из 2 возможных). Но почитай прежде про undo_retention - иначе сам экспорт может "слететь" из-за того что к его окончанию сервер выкинет "слишком старые" блоки undo, а без них согласованное состояние "на момент начала процесса" не получить. Ну и, естественно, если правится это самое время, то может быть надо и размер undo пространств подкорректировать - чтобы хватило места эту самую "информацию отката" держать. Да, если весь процесс будет растягиваться на 4-5 часов - это проблема. Либо придётся "играться" с undo_retention - ставя его на 5 часов лишь на время создания дампа, либо прилично так раздувать undo-пространство, чтобы и в "рабочее время" его хватало на хранение 5 часов "данных отката". Может быть проще будет делить сам процесс создания дампа на более мелкие части - по несколько связанных схем "за раз". Конечно это не даст возможности иметь согласованные данные (а значит и включаемые без ошибок констрейны) между разными такими наборами/подсистемами. Т.е. не факт что это применимо к вашей реальной ситуации... ------------------ WBR, Igor |
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Спасибо за ответ...
Похоже этот вариант не подойдет. Большие риски чего-либо... И это на боевом сервере. Да нас просто убьют за это. В договоре прописаны такие большие штрафные санкции, что мама не горюй. Предложу руководству на наш сервер кидать дамп с боевого сервера (что долго по времени, да и дальнейшее импортирование). Но по кране мере сбоя на боевом сервере из-за наших хотелок не будет. Конечно, я не такой профи как ты. Как я понимаю, надо будет FLASHBACK еще включать. А его включение будет, по-моему, на заполнение области FRA влиять, в сторону его увеличения. Хотя часть инфы от тебя мне непонятны: Хм... Я ничего ведь откатывать не собираюсь. Из-за чего может понадобится откат ? Дык это как раз все наши схемы... Они связаны между собой. Я как-то ранее об этом писал. Но это не моя идея была (делать множество схем, причем таблицы связаны между схемами). Я об это руководству говорил. Но прочитать про все это мне надо. Как то надо показать руководству, что этот путь тернист и возможны риски. |
Re: Oracle. Администрирование. | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Так версионник обеспечивает согласованность данных - когда идёт запрос блока который уже изменён транзакцией и даже зафиксирован, а нам нужно его состояние "на 0:00" - т.к. именно тогда стартовал наш "долгоиграющий" запрос, или началась транзакция в режиме Serializable (т.е. как раз то что и нужно для "полностью согласованного снимка данных" - но уже на время нескольких запросов а не одного). P.S. Мне всегда казалась насколько странной идея таскать на тест/дев базы ПОЛНУЮ копию продуктива (я вообще выступаю за СПЕЦИАЛЬНЫЙ тестовый набор данных - или даже не один такой набор). Для изоляции бага нужен тесткейс, а не "живые данные" с этим багом... Но увы - у нас тоже не могут без этого... Т.к. помимо вылова косяков своего кода ещё и зачастую занимаются выловом косяков "тупых юзеров" невесть что невесть куда навводивших и не могущих концы с концами свести... P.P.S. Я ещё сложнее дамп делаю - т.к. в структуре есть под 50Гб данных блобов со всякой не нужной для работы чухнёй (документы/принтформы/картинки - их все замечательно заменяет 10Кб файл-заглушка с буковками типа "реальные данные только на продуктиве, а тут вам не там!"), то приходится сначала делать дамп "только таблиц", при том за исключением таблиц с блобами - потом генерится dat файл для sqlldr с id, name ну и прочими не-LOB реквизитами этих таблиц документов (т.к. связи то на них есть по любому - "пустыми" нельзя оставить), а потом ещё один дамп уже "чисто по структурам" - чтобы вью/хп/констрейны воссоздать. И потому проблему
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 |
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Игорь, спасибо тебе за ответы, советы...
Отвечу, почему нам надо полную копию продуктива? У нас тяжелые отношения с заказчиком. Заказчик ранее использовал и во многих местах использует старый продукт. Мы влезли и предложили свое детище. Внедрили свой продукт порядка в 150 отделах. Все данные у нас хранятся в одном месте. Но другие отделы работают на старом продукте и предыдущий исполнитель делал софт (БД mssql), что данные отдела хранятся в отделах и с периодичностью кидают на общий сервер. Там делаются отчеты. Наша концепция, сразу на одном сервере все данные. Но, как я и указал, только часть отделов перешло на наше ПО. Приходится ежедневно экспортировать записи, сделанные у нас, в старую систему. Сделан сервис у нас. Но и их данные сделанные на старом ПО должные перекочевать в нашу систему. То же сделан сервис. И возможен (да он и есть) случай, что записи сделанные в одном ПО качуют в другое и потом обратно возвращаются в наше. Это надо отлавливать и не допускать повтора. Да и записи сделанные в старом ПО при кочевании в наше ПО имеют ошибки. Их тоже отлавливаем, отсылаем обратно. Короче муторная работа. Ну и для правильного анализа всего этого, нам нужен полный дамп на тест и анализ как нашей отправки данных, так и приход их данных. Тут сделал маленький эксперимент. Вот такой есть результат...Может и хреновый анализ, но я хочу его отдать. |
Re: Oracle. Администрирование. | |
---|---|
Igor Korolyov Сообщений: 34580 Дата регистрации: 28.05.2002 |
Единственное замечание - при тесте на 1 физическом сервере (даже если это 2 отдельных виртуальных сервера) может оказаться ОЧЕНЬ узким местом CPU и дисковая подсистема - т.е. надо сопровождать такой тест анализом/контролем загрузки CPU/Storage.
Впрочем, я полагаю что в любом случае работа через dblink будет не быстрее чем дамп в файл. А по поводу "места для дампа" - что мешает подключить к обоим серверам быстрый сетевой диск? Исключается и забивание основного диска сервера, и затраты на "копирование" дампа... ------------------ WBR, Igor |
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Спасибо за замечание, учту.
Самое главное, когда начинали, именно к продуктиву серверу и был подключен сетевой диск. Я туда складывал дампы, причем автоматически в имя файла вписывался день. Дампы держались неделю. Потом самый старый удалялся и замещался вновь пришедшим. Но потом, что-то они отсоединили его и теперь единственный/ежедневный дамп хранится в основном разделе. Да и ихние BackUp-ы тоже смотрю хранятся в основном разделе. Конечно может их дублируют в другие места, но я об это не знаю. |
Re: Oracle. Администрирование. | |
---|---|
ВладимирС Автор Сообщений: 1693 Дата регистрации: 03.11.2005 |
Спрошу в этом топике, хотя уже вопрос не про администрирование, но по ораклу.
Прикрепили к другому проекту... И вот проблема вытащить данные через dblink... Поставили задачу, вытаскивать данные с другого сервера... Сначала просто составлял запросы в которых join-ил таблицы через dblink. Но вижу, что это идеологически неправильно, т.к. на сервере с которого запускаю такой запрос выполняется очень долго, если таблицы большие. План создастся не может... вытаскивание скорее всего всех данных из таблиц dblink-а... Ну и соответственно зависание. Решил на dblink-овском сервере создать пакет и в нем процедуру которая на выходе выдает курсор. типа:
Решил с другого сервера вытащить данные этого курсора через dblink (мне же эти данные нужны на боевом сервере):
Порыскал в инете: Tom Kyte refcursors may not be returned over a dblink Решил попробовать создать табличную функцию и вытащить ее тоже через dblink (в надежде, что в табличную функцию впихну результаты курсора) создаю на dblink-овском сервере к которому буду обращаться:
Но если ее вызвать через dblink с другого сервера
Исправлено 1 раз(а). Последнее : ВладимирС, 28.09.17 08:11 |
© 2000-2024 Fox Club  |