Комментарии 67
Хм, я думал что Оракл поддерживает инкрементальные бекапы. Зачем бекапить каждый день всю базу? Вроде ж классический подход - раз в неделю (на выходных) - полный бекап, в остальные дни - инкрементальный.
Конечно поддерживает, видимо лень было почитать про rman.
Ну и тут куча вопросов про восстановление и его время. Опять же такой бэкап подразумевает пересоздание индексов после восстановление а это время. Ну в итоге после этого новая БД получится, а не старая восстановленная. Другие идентификаторы в системных таблицах и все такое.
Из такого бэкапа получить клон бд скажем для стендбая тоже не реально.
Этот бекап не для восстановления всей базы в случае краха - для этого у нас есть стендбай. Этот бекап для того, чтобы иметь дамп каждой нужной схемы за каждый день.
О боже, стендбай - НЕ БЕКАП. Накатили левый патч на базу, изменения ушли на стэндбай и привет. А то по вашему и raid из дисков бекап.
Дамп - НЕ БЕКАП, ибо не защищает базу целиком, не может использоваться для полноценного восстановления. Не содержит системные прав и прочее. Время восстановления ужасно. И в итоге имеем другую БД начиная с ID и кончая настройками и идентификаторами в БД.
В Oracle есть нормальный механизм резервного копирования, но надо изобретать яйцо фаберже...
Подскажете, как рманом восстановить только одну схему за прошедший месяц?
Очень просто: если развести схемы по табличным пространствам, то Tablespace point in time recovery
Так нам нужно не откатить данные до определенного состояния, а иметь и текущее состояние, и месяц назад, и год назад. Иногда нужно одновременно несколько состояний данных.
Ну и кто мешает, rman позволяет получить базу или ее часть на каждую секунду или scn, а дальше вопрос сколько хранить
Как восстановить табличное пространство из бекапа RMAN в другую базу? Можете сценарий RMAN набросать?
Google rman trasportable tablespace
Подождите, я у вас совета не просил. Моя статья вообще не про то, как нужно бекапить базы. Она про то, что если у кого будет схожая проблема, то вот вам решение, сам написал, сам делюсь. Решение достаточно универсальное, данные восстановятся родными оракловыми утилитами.
Вы мне доказываете, что мы все делаем неправильно и ничего не понимаем в базах. Потрудитесь доказать.
Про trasportable tablespace я в курсе, только этот функционал лично нам никак не полезен.
А как используя дамп восстановиться на любую точку во времени? Плюсом вопрос, используется ли выставление consistent=y. И если да, какую доп нагрузку он даёт. Если сильно надо именно схему, а не тп с данными. То только дубликейт из бэкапа и потом экспорт схемы. Из плюсов, все ещё можно сделать дубликейт на конкретный момент времени
А как используя дамп восстановиться на любую точку во времени?
Ну, не на любой момент времени, только на момент снятия дампа. Дампы у нас есть за каждый день, такой точности нам достаточно.
используется ли выставление consistent=y. И если да, какую доп нагрузку он даёт.
На этом большом сервере не используем, так как там консистентность ни к чему. А на других используем - в зависимости от размера данных и интенсивности их изменения в момент бекапа может генерировать много сегментов отката в табличном пространстве UNDO. Поведение абсолютно идентично экспорту при помощи expdp с параметром консистентности - может потребоваться увеличение табличного пространства отмены и параметра undo_retention, если данных много и экспорт длится долго
тп с данными
Извините, не знаю, что такое тп
ТП - табличное пространство. База в дампе не согласована, PITR не возможен и куча всего, что вам еще написали. Итого нельзя назвать это бэкапом никак. В чем проблема иметь один лвл0 бэкап, который пробегает за выходные и лвл1 каждый день. С учетом того, что рман может сразу и в компрессию и писать на сетевое хранилище.
+ в случае битого блока не придется дропать и перезаливать все данные. Тот же рман спокойно восстанавливает отдельный блок или последовательность.
База в дампе не согласована, PITR не возможен и куча всего, что вам еще написали
Нет, данные в дампе согласованы, так как разработаны соответствующим образом. Да, тут невозможно куча всего, только нам это все и не нужно. А нужно нам другое.
Итого нельзя назвать это бэкапом никак.
Я даже не знаю, как это комментировать. Мы 30 лет храним и восстанавливаем нужные данные, а вы говорите, что это не бекап. Я специально написал в статье - нам не нужен бекап базы, нам нужен бекап данных.
В чем проблема иметь один лвл0 бэкап, который пробегает за выходные и лвл1 каждый день. С учетом того, что рман может сразу и в компрессию и писать на сетевое хранилище.
+ в случае битого блока не придется дропать и перезаливать все данные. Тот же рман спокойно восстанавливает отдельный блок или последовательность.
Проблема тут в том, что, что если нас просят восстановить нужную схему за нужное число на другой сервер (совсем небольшой), то это резко становится практически невозможным.
Вы, как и многие комментаторы, пытаетесь меня убедить, что это плохая идея для бекапа БД, у что у рмана куча возможностей для бекапа БД и ее лечения. Но в случае именно этого сервера, нам не нужен бекап БД, нам нужен бекап данных за каждый день. Которые еще и не привязаны к какой-то конкретной базе, эти данные можно быстро восстановить на других базах.
Только дошло, что тп - это табличное пространство)
Если сильно надо именно схему, а не тп с данными. То только дубликейт из бэкапа и потом экспорт схемы. Из плюсов, все ещё можно сделать дубликейт на конкретный момент времени
![]()
Это все достаточно трудозатратно при восстановлении.
Я специально в статьях не описываю в подробностях лишние детали, чтобы не отвелекать от основной схемы.
В большинстве сценариев использовании базы данных (не у нас) есть база, с которой все работают и от администраторов требуется иметь бекап на самый последний момент времени, чтобы все это восстановить. Опционально можно делать какие-то чекпойнты.
У нас восстановление данных какой-то схемы - рутинный ежедневный процесс. И сама база, в случае именно этого сервера, нам не особо дорога, а вот ежедневные данные дороги. И восстановить эти данные могут попросить на несколько серверов за различные числа. Такова данность. Поэтому мы и делаем именно бекап данных, не бэкап базы. И табличные пространства в таком случае - это лишняя нагрузка и лишняя сложность
Поддерживает, но бэкапить надо не все схемы, а только часть.
Я, конечно, не специалист по базам данных, но у меня возникло 3 рациональных предложения:
1. Почему бы большую базу не разделить на много маленьких, что упростило бы процессы администрирования и бэкапа + позволило бы горизонтально масштабировать всю нагрузку.
2. Зачем делать бэкап с основной базы данных и "тормозить" её дополнительной нагрузкой, если можно бэкапить с read-only реплики этой базы? Многие компания так и делают.
3. Зачем вообще держать такую большую базу, если можно старые данные переносить в архив. Например, биллинг у операторов связи генерирует за месяц около 10 ТБ данных в БД. Данные старше одного месяца уходят в архив, т.е. их запрос происходит из архивной базы данных, а не из основной базы биллинга. Таким образом основная база биллинга содержит данные только с начала месяца, а не увеличивается постоянно на 10 ТБ, пока не достигнет много Петабайт и не "порвёт" СХД своим размером.
Знаете, в мою бытность работы в иностранных компаниях, которые были не последними в мире, примерно так и делалось в промышленных решениях . Но, к сожалению, при попытке обсудить с коллегами такие подходы уже в российских компаниях не нахожу желания использовать такие методы и способы. Зато наблюдаю как не хватает места, деградирует скорость работы, увеличивается время на бэкапы и т.д. )
1) Это усложнило бы работу пользователей и администраторов, так как пришлось бы вести реестр схем на каждом сервере и следить за его актуальностью. Ну, и это деньги за еще одну лицензию
2) Нужна еще одна лицензия, что стоит денег. Плюс ко всему, у нас лицензия Standart Edition, что не подразумевает read-only реплики. Enterprise сильно дороже.
3) Все схемы находятся в постоянной работе, там нечего помещать в архив.
Осталось еще рассказать автору что вместо Zip можно взять Zstd
https://rhaas.blogspot.com/2022/05/parallel-server-side-backup-compression.html
И подобрать подходящее количество потоков и уровень сжатия под производительность сервера и пропускную способность сети
Википедия говорит, что реализация доступна на Линуксе, Маке и BSD. У нас файловый сервер на Винде. В решениях хочется чего-то универсального
Теперь понятно почему вы велосипедите велосипеды
Начиная с того что Zstd это open source с реализацией на 30! языках
Заканчивая тем что есть официальный пакет
https://github.com/facebook/zstd/releases/download/v1.5.5/zstd-v1.5.5-win64.zip
Rman все это делает и делал без проблем, 1.5ТБ к примеру бэкапит за 2-3 часа максимум, если добавить каналы + добавить сжатие.
Без проблем делает бекапы отдельных схем с возможностью развернуть на другой базе (без пересоздания базы) ? Подскажете, как из рмановского архива восстановить одну схему за прошлый месяц?
Ох, зациклились Вы на схемах, если умеешь пользоваться молотком, то все вокруг кажется гвоздями.
Еденица бекапа в Oracle - табличное пространство. Сделайте соответствие между схемой и табличным пространством/ми и будет вам счастье. Надо перенести в другую базу, так есть transportable tablespace.
Все уже есть в Оракле, не надо изобретать велосипед, надо просто прочитать документацию.
Опять же если грамотно выработана ILM стратегия. И старые данные лежат в отдельных табличных пространствах так их можно сделат read only и забекапить один раз.
Еденица бекапа в Oracle - табличное пространство
Это вам в документации Оракла написали? а они там не написали, для чего делают возможность бекапа схем и таблиц в своих инструментах?
Все уже есть в Оракле,
Не все есть в Оракле.
Начнем с того, что ваша идея не согласуется ни с опытом разработки, ни с рекомендациями Оракла. Если у вас есть опыт работы с Ораклом и в вашей ситуации ваша схема работала, то поверть
Но ок, мы сделали соответствие между схемой и табличным пространством, что дальше? Как это поможет нам забекапить половину табличных пространств из 1905 объемом 1594 ГБ за ночь? А что, если нам нужно восстановить несколько версий одной схемы за разные даты? Зачем вообще городить табличные пространства для каждой схемы без необходимости?
И старые данные лежат в отдельных табличных пространствах так их можно сделат read only и забекапить один раз
Да нет старых данных. Поверьте, догадались бы мы не бекапить неизменяемые данные впустую.
Ох, зациклились Вы на схемах, если умеешь пользоваться молотком, то все вокруг кажется гвоздями.
Это прекрасно, сходу и диагноз поставили
Что есть схема в вашей системе? Какова природа данных в них? Откуда появляются новые схемы? Вы пишите, что они не зависимы друг от друга. То есть восстановление одной схемы всегда будет консистентно? В случае восстановления схема импортируется в ту же БД с новым именем, тем самым увеличивая их количество? Это продуктивная или тестовая система? Вы пишите, что являетесь разработчиком продуктов, что предполагает наличие схем, которые скорее всего должны являться отдельными БД для клиента. Oracle позволяет использовать редакцию EE бесплатно, включая все её фичи и возможности для разработчиков, если система не используется в продакшене. Вы пишите, что у вас есть Standby, и тут же пишите, что лицензия Standart Edition, для которой Standby в классическом виде недоступны. Так SE или EE? Какая версия БД использутеся?
Вся эта история похожа на то, что ваша БД на самом деле является кучей разных БД слитых в одну базу. И если так, то все проблемы и велосипеды у вас из-за некорректной организации БД
Что есть схема в вашей системе? Какова природа данных в них? Откуда появляются новые схемы?
Схема - это набор объектов БД (таблицы, пакеты, индексы и.т.д.) необходимый и достаточный для запуска нашей системы на сервере заказчика. Таким образом одна схема - это данные и настройки одного заказчика. Конкретно тот сервер, про который я пишу - не для реальной работы и реальных данных, там выполняются и тестируются настройки.
Я специально не вдаюсь в подробности, так это мой личный, а не корпоративный блог, поэтому открывать подробности кухни нашей организации не имею ни желания, ни полномочий.
Новая схема появляется с новым заказчиком.
Вы пишите, что они не зависимы друг от друга
Да, они совершенно независимы.
То есть восстановление одной схемы всегда будет консистентно?
Не совсем понял вопрос. Если бекап данных сделали консистентным, то да. Конкретно на этом сервере в этом нет необходимости.
В случае восстановления схема импортируется в ту же БД с новым именем, тем самым увеличивая их количество?
Либо на этот сервер под другим именем, либо на другой сервер, либо на тестовую среду. Вариантов достаточно.
Это продуктивная или тестовая система?
Продуктивная, но не для заказчиков, а для наших сотрудников
Вы пишите, что являетесь разработчиком продуктов, что предполагает наличие схем, которые скорее всего должны являться отдельными БД для клиента
Не понял
Oracle позволяет использовать редакцию EE бесплатно, включая все её фичи и возможности для разработчиков, если система не используется в продакшене.
Тем не менее, это прод
Вы пишите, что у вас есть стендбай, и тут же пишите, что лицензия Standart Edition, для которой стендбаи в классическом виде недоступны. Так SE или EE? Какая версия БД?
А он и не в классическом виде) SE. 11
Вся эта история похожа на то, что ваша БД на самом деле является кучей разных БД слитых в одну базу. И если так, то все проблемы и велосипеды у вас из-за некорректной организации БД
С первой частью согласен, со второй нет. БД организована с максимальным удобством для всех процессов. Вроде так и нужно делать технические решения?
В вашем случае было бы правильней использовать multi-tenant архитектуру с патчем до 12 версии и разворачивать отдельную PDB для каждой БД заказчика. В таком случае можно было бы бэкапить только нужные PDB и стандартными средствами разворачивать их, стандартными же средствами восстанавливать хоть на текущий сервер, хоть на соседний и делать это довольно быстро.
БД организована с максимальным удобством для всех процессов
Максимальное удобство для всех процессов, наверное включает в том числе и процессы администрирования?
Согласитесь, что администрировать штатными средствами удобнее, чем самописными?
В вашем случае было бы правильней использовать multi-tenant архитектуру с патчем до 12 версии и разворачивать отдельную PDB для каждой БД заказчика
Проблема только в том, что система разрабатывалась задолго до появления 12 версии, соответственно все процессы строились по техническим возможностям того времени.
Согласитесь, что администрировать штатными средствами удобнее, чем самописными?
Соглашусь. Согласитесь в ответ, что для решения проблем с одним нетипичным сервером совсем не хочется обновлять порядка 1000 серверов на поддержке в максимально короткие сроки и кардинально менять десятилетиями выстроенные процессы. То, что я сделал, в нашей ситуации было абсолютно оправданно. Да и хороший самописный инструмент в компании, занимающейся разработкой - вполне нормальная практика
Кстати да хорошая идея.
Есть инкриментальй и камулятивный бэкап. Так что за ночь не надо бекапить терабайты.
Ну и многопоточный rman полный бэкап 2-3 тб бэкапит максимум час. Мы 100 тб бэкапим без проблем. Но еще раз это не надо, можно бэкапить инкремнет. И сжатие там есть.
Дальше все засисит от вашей политики бекапа, хоть за 10 лет храните и востанавливайтесь на любую секунду из 10 лет. Хоть часть, хоть все. Судя по вашим вопросам Вы не понимаете как рабтает rman.
Ну и самоое главное, любой новый DBA придет увидит rman и восстановит вам БД или ее часть с закрытыми глазами. В вашем случае специалист со стороны за сколько?
Вы упорно путаете дамп и бекап.
Вы упорно путаете дамп и бекап.
Нет, это вы упорно путаете бекап базы данных и бекап данных. Я даже в название статьи вынес, что речь про бекап данных. Вы так упорно мне грозитесь документацией по RMAN, но не понимаете разницы? Дамп, который делают утилиты exp и expdp - это бекап данных. Бекап базы данных в данном случае просто не нужен.
Ну и самоое главное, любой новый DBA придет увидит rman и восстановит вам БД или ее часть с закрытыми глазами. В вашем случае специалист со стороны за сколько?
Я уже сбился со счета, чколько раз я это сегодня писал, но нам не нужно восстанавливать БД, нам нужны данные) Если вы у вас есть опыт работы с Ораклом и вы внимательно читали статью, то вы должны увидеть, что данные снимаются родным оракловым механизмом Datapump (именно в таком забирает данные утилита expdp - она использует тот же самый API). Если новый DBA не знает, как загрузить данные из родного для Оракла формата, тогда дела плохи.
Если вся архитектура завязана на схемах и нужно восстановить определенную схему - то рман тут не в силах(если только каждая схема не имеет свою ТП). Но и создавать схемы в одно и то же ТП - ошибка. Тут уже к архитектору вопросы.
Но и создавать схемы в одно и то же ТП - ошибка. Тут уже к архитектору вопросы.
Касательно именно этого сервера - это не ошибка, там в них просто нет необходимости. Комментаторы предлагали все схемы располагать в отдельных табличных пространствах, но это никак не помогает в решении исходного вопроса - иметь ежедневный бекап данных каждой схемы.
Если каждая схема будет в своем ТП, то рман без проблем восстановит ТП на дату которая необходима с бэкапа.
в другую базу?
В эту же, рманом можно помимо самой БД бэкапить отдельные ТП и даже таблицы
Не вопрос и в другую
Да вопрос же, вопрос. Ну как вы так уверенно утверждаете, не зная нашей архитектуры и процессов?
Табличное пространство - это элемент базы данных, который реализует физическую структуру БД в виде файлов данных. Схема - это логическая структура, которая объединяет объекты в БД в одном пространстве имен. Схемы располагают в отдельных табличных пространствах там, где это оправданно. Лепить на каждую схему свое табличное пространство просто потому, что кому-то так кажется правильным - глупо. И привязывать данные к табличному пространству - тоже глупо.
Тем не менее, пожалуйста, напишите мне шаги по разворачиванию одного табличного пространства из RMAN в другой существующий инстанс БД. Хочется убедиться, что вы вообще понимаете, о чем речь.
Мы на MSSQL за сутки бэкапим 80 терабайт. 4 потока, компрессия. Все стандартной командой. Можно и быстрее, если бы больше сетевых карт
Неужели в оракл все так плохо?
Нет, в Оракл все хорошо) Просто у нас очень специфические условия и требования к бекапу
Какие именно? Из статьи не понял
Разве нет в Oracle бэкапа логов, которые потом можно накатывать двигаясь вперед? У нас FULL в викенд, далее transaction log раз в 15 мин, так что мы можем восстановиться на любое время
Я не ораклист, поэтому интересно что там у конкурентов
Разве нет в Oracle бэкапа логов, которые потом можно накатывать двигаясь вперед? У нас FULL в викенд, далее transaction log раз в 15 мин, так что мы можем восстановиться на любое время
Можно, rman прекрасно умеет такое делать. Но нам не нужен бекап базы, нам нужен бекап данных, не привязанных к конкретному инстансу БД
Извините за наивный вопрос от MSSQL DBA, что означает "не привязанных к конкретному инстансу БД"?
В MSSQL бэкап можно восстановить на любом совершенно сервере (единственное требование, чтобы его версия была равна или выше той, на которой сделан бэкап)
Я не знаком с MSSQL, но в Оракле ситуация такая: есть бекап базы данных, а есть бекап данных.
Бекап базы данных нужен для максимально быстрого восстановления работы БД при сбоях, а так же при максиммально быстром восстановлении базы данных на другой сервер, в случае отказа сервера. Но вы не можете восстановить часть данных из этого бекапа в другую базу. Потому RMAN про данные, по большому счету, ничего не знает. Он работает с блоками датафайлов. Поэтому бекап RMAN привязан к той базе, из которой он сделан. Нельзя в одну БД восстанавливать датафайлы или отдельные блоки данных, сделанных из другой БД.
Бекап данных снимается утилитами exp или expdp, вы можете выгрузить отдельные таблицы, пакеты и прочие объекты БД в дамп и загрузить из в другую базу данных. У бекапа данных нет привязки к той БД, из которой его сняли. Данные можно восстановить в любую БД, версией не ниже
Эта статья - она про бекап данных, не про бекап БД.
В MSSQL не делают бэкапы данных. Импорт экспорт считается ETL. Если вы экспортнете данные, почистите таблицы и импортируете все назад, то в общем случае вы не получите того же состояния базы. Как минимум поедут все значения колонок timestamp, если они есть, а о таблицах с change tracking и говорить нечего
Но мне интересно, почему в вашем случае не работает простое решение: создать тыщу с чем-то баз и бэкапить ресторить из независимо
База в терминологии Оракла - это инстанс БД. То есть нужно запускать множество экземпляров приложения, каждый из которых потребует памяти. Про MSSQL я не знаю, но если провести аналогию, то то, что в MySQL или Postgres называется база, в Оракле называется схема. Возможно, в MSSQL примерно то же самое, поэтому для вас все и выглядит странновато). По сути именно так и делается, каждая схема (читай, база в остальных СУБД) бекапится и ресторится независимо
Вы плаваете в терминологии.
База данных - это набор файлов, которые содержат в себе данные, физически расположенные на диске
Инстанс(базы данных) - это набор процессов, которые обслуживают саму базу данных.
Соответственно Инстанс != БД. При использовании RAC у вас будет одна база данных и 2 и более инстанса, которые эту БД обслуживают.
В Postgres базой данных так же называется набор файлов, который содержит в себе данные, физически расположенные на диске. Логически база данных располагается в кластере. Для каждой базы данных в кластере существует подкаталог внутри PGDATA/base на диске
То что в оракле называется схемами - это созданная учетная запись пользователя и объекты, которые ей принадлежат. Служит чаще всего для логического разделения объектов одной базы данных и прав к ним. В частности в любой БД Oracle, есть как минимум 3 схемы - USERS(или любая другая польз.схема) и системные SYSTEM,SYS. И они не могут считаться отдельными БД, хотя бы потому что связаны и зависят друг от друга.
Если уж и проводить аналогию с Postgres, то ближайшим аналогом кластера и БД входящих в кластер, будет оракловая Multitenant архитектура, где в рамках одной CDB будет располагаться множество PDB использующие общие ресурсы и общую память.
Вы совершенно правы, только небольшое уточнение (справедливо для Oralce 11 и 19, может, в других версиях изменения) схемы USERS по умолчанию нет, есть табличное пространство USERS. Схем/пользователей же при создании базы создается несколько больше.
Просто мы с коллегой из соседнего цеха обмениваемся знаниями и опытом, поэтому приходится приводить аналогии, которые, как известно, всегда ложны.
Я, собственно говоря, про это и писал, что каждая база для работы требуют инстанса приложения, который отъедает ЦП и память
И они не могут считаться отдельными БД, хотя бы потому что связаны и зависят друг от друга.
Они, конечно, не могут быть отдельными БД, тут я упростил, но независимыми вполне могут быть - это зависит только от архитектуры приложения. Если приложение располагается в одной схеме, то совершенно спокойно можно делать консистентный бекап данных схемы и восстанавливать ее из дампа без оглядки и влияния на другие схемы/данные
Нельзя в одну БД восстанавливать датафайлы или отдельные блоки данных, сделанных из другой БД.
То есть в оракл вы не можете склонировать базу, просто сделав full backup и отресторив на этом же или другом сервере под другим именем?
Можно восстановить базу на другом компьютере из бекапа базы, но нет смысла делать бекап базы (несколько гигабайт), если нужны только данные (100-300 МБ). Я выше вам ответил, скорее всего непонимание из-за разницы терминологий. Так, например, в Оракле нет отдельной сущности "пользователь", как есть в тех же MySQL или Postgres. Создавая пользователя в Оракл, вы создаете его схему и пространство имен, что для других СУБД аналогично понятию базы.
~23 Тб с компрессией до ~3 Тб за двое суток, но там железо уже совсем унылое и БД почти не бывает в простое
Veeam BR зашел в чат.
Veeam BR не умеет в бекап данных Оракла. Он про бекап БД, работает по логике RMAN'а
Какой-то странный и крайне непонятный кейс. Какую проблему то решаем?
AAIP в VBR-е, бэкап базы раз в сутки или раз в N часов, бэкап транзакшн логов раз в N часов/минут. И играйся с этим набором, как душе пожелается. Отресторить изолированный клон или выдрать из него саму БД - дело пары минут.
https://www.veeam.com/blog/how-to-backup-oracle-database-best-practices.html
Как ускорить бекап данных из OracleDB в 5 раз? Или в 10. Можно и больше…