Теперь понятно почему вы велосипедите велосипеды

Из-за того, что не слышал про zstd? )

Спасибо за информацию, изучу на досуге

Начиная с того что Zstd это open source с реализацией на 30! языках

Заканчивая тем что есть официальный пакет

https://github.com/facebook/zstd/releases/download/v1.5.5/zstd-v1.5.5-win64.zip

Просто мы с коллегой из соседнего цеха обмениваемся знаниями и опытом, поэтому приходится приводить аналогии, которые, как известно, всегда ложны.

Я, собственно говоря, про это и писал, что каждая база для работы требуют инстанса приложения, который отъедает ЦП и память

И они не могут считаться отдельными БД, хотя бы потому что связаны и зависят друг от друга.

Они, конечно, не могут быть отдельными БД, тут я упростил, но независимыми вполне могут быть - это зависит только от архитектуры приложения. Если приложение располагается в одной схеме, то совершенно спокойно можно делать консистентный бекап данных схемы и восстанавливать ее из дампа без оглядки и влияния на другие схемы/данные

База данных - это набор файлов, которые содержат в себе данные, физически расположенные на диске

Инстанс(базы данных) - это набор процессов, которые обслуживают саму базу данных.

Соответственно Инстанс != БД. При использовании RAC у вас будет одна база данных и 2 и более инстанса, которые эту БД обслуживают.

В Postgres базой данных так же называется набор файлов, который содержит в себе данные, физически расположенные на диске. Логически база данных располагается в кластере. Для каждой базы данных в кластере существует подкаталог внутри PGDATA/base на диске

То что в оракле называется схемами - это созданная учетная запись пользователя и объекты, которые ей принадлежат. Служит чаще всего для логического разделения объектов одной базы данных и прав к ним. В частности в любой БД Oracle, есть как минимум 3 схемы - USERS(или любая другая польз.схема) и системные SYSTEM,SYS. И они не могут считаться отдельными БД, хотя бы потому что связаны и зависят друг от друга.

Если уж и проводить аналогию с Postgres, то ближайшим аналогом кластера и БД входящих в кластер, будет оракловая Multitenant архитектура, где в рамках одной CDB будет располагаться множество PDB использующие общие ресурсы и общую память.

AAIP в VBR-е, бэкап базы раз в сутки или раз в N часов, бэкап транзакшн логов раз в N часов/минут. И играйся с этим набором, как душе пожелается. Отресторить изолированный клон или выдрать из него саму БД - дело пары минут.

https://www.veeam.com/blog/how-to-backup-oracle-database-best-practices.html

То есть в оракл вы не можете склонировать базу, просто сделав full backup и отресторив на этом же или другом сервере под другим именем?

Но мне интересно, почему в вашем случае не работает простое решение: создать тыщу с чем-то баз и бэкапить ресторить из независимо

Вы мне доказываете, что мы все делаем неправильно и ничего не понимаем в базах. Потрудитесь доказать.

Про trasportable tablespace я в курсе, только этот функционал лично нам никак не полезен.

Бекап базы данных нужен для максимально быстрого восстановления работы БД при сбоях, а так же при максиммально быстром восстановлении базы данных на другой сервер, в случае отказа сервера. Но вы не можете восстановить часть данных из этого бекапа в другую базу. Потому RMAN про данные, по большому счету, ничего не знает. Он работает с блоками датафайлов. Поэтому бекап RMAN привязан к той базе, из которой он сделан. Нельзя в одну БД восстанавливать датафайлы или отдельные блоки данных, сделанных из другой БД.

Бекап данных снимается утилитами exp или expdp, вы можете выгрузить отдельные таблицы, пакеты и прочие объекты БД в дамп и загрузить из в другую базу данных. У бекапа данных нет привязки к той БД, из которой его сняли. Данные можно восстановить в любую БД, версией не ниже

Эта статья - она про бекап данных, не про бекап БД.

Вы упорно путаете дамп и бекап.

Нет, это вы упорно путаете бекап базы данных и бекап данных. Я даже в название статьи вынес, что речь про бекап данных. Вы так упорно мне грозитесь документацией по RMAN, но не понимаете разницы? Дамп, который делают утилиты exp и expdp - это бекап данных. Бекап базы данных в данном случае просто не нужен.

Ну и самоое главное, любой новый DBA придет увидит rman и восстановит вам БД или ее часть с закрытыми глазами. В вашем случае специалист со стороны за сколько?

Я уже сбился со счета, чколько раз я это сегодня писал, но нам не нужно восстанавливать БД, нам нужны данные) Если вы у вас есть опыт работы с Ораклом и вы внимательно читали статью, то вы должны увидеть, что данные снимаются родным оракловым механизмом Datapump (именно в таком забирает данные утилита expdp - она использует тот же самый API). Если новый DBA не знает, как загрузить данные из родного для Оракла формата, тогда дела плохи.

Ну и многопоточный rman полный бэкап 2-3 тб бэкапит максимум час. Мы 100 тб бэкапим без проблем. Но еще раз это не надо, можно бэкапить инкремнет. И сжатие там есть.

Дальше все засисит от вашей политики бекапа, хоть за 10 лет храните и востанавливайтесь на любую секунду из 10 лет. Хоть часть, хоть все. Судя по вашим вопросам Вы не понимаете как рабтает rman.

Ну и самоое главное, любой новый DBA придет увидит rman и восстановит вам БД или ее часть с закрытыми глазами. В вашем случае специалист со стороны за сколько?

Вы упорно путаете дамп и бекап.

В MSSQL бэкап можно восстановить на любом совершенно сервере (единственное требование, чтобы его версия была равна или выше той, на которой сделан бэкап)

Разве нет в Oracle бэкапа логов, которые потом можно накатывать двигаясь вперед? У нас FULL в викенд, далее transaction log раз в 15 мин, так что мы можем восстановиться на любое время

Можно, rman прекрасно умеет такое делать. Но нам не нужен бекап базы, нам нужен бекап данных, не привязанных к конкретному инстансу БД

В вашем случае было бы правильней использовать multi-tenant архитектуру с патчем до 12 версии и разворачивать отдельную PDB для каждой БД заказчика

Проблема только в том, что система разрабатывалась задолго до появления 12 версии, соответственно все процессы строились по техническим возможностям того времени.

Согласитесь, что администрировать штатными средствами удобнее, чем самописными?

Соглашусь. Согласитесь в ответ, что для решения проблем с одним нетипичным сервером совсем не хочется обновлять порядка 1000 серверов на поддержке в максимально короткие сроки и кардинально менять десятилетиями выстроенные процессы. То, что я сделал, в нашей ситуации было абсолютно оправданно. Да и хороший самописный инструмент в компании, занимающейся разработкой - вполне нормальная практика

База в дампе не согласована, PITR не возможен и куча всего, что вам еще написали

Нет, данные в дампе согласованы, так как разработаны соответствующим образом. Да, тут невозможно куча всего, только нам это все и не нужно. А нужно нам другое.

Итого нельзя назвать это бэкапом никак.

Я даже не знаю, как это комментировать. Мы 30 лет храним и восстанавливаем нужные данные, а вы говорите, что это не бекап. Я специально написал в статье - нам не нужен бекап базы, нам нужен бекап данных.

В чем проблема иметь один лвл0 бэкап, который пробегает за выходные и лвл1 каждый день. С учетом того, что рман может сразу и в компрессию и писать на сетевое хранилище.

+ в случае битого блока не придется дропать и перезаливать все данные. Тот же рман спокойно восстанавливает отдельный блок или последовательность.

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

Я не ораклист, поэтому интересно что там у конкурентов

БД организована с максимальным удобством для всех процессов

Максимальное удобство для всех процессов, наверное включает в том числе и процессы администрирования?

Согласитесь, что администрировать штатными средствами удобнее, чем самописными?

+ в случае битого блока не придется дропать и перезаливать все данные. Тот же рман спокойно восстанавливает отдельный блок или последовательность.

Что есть схема в вашей системе? Какова природа данных в них? Откуда появляются новые схемы?

Схема - это набор объектов БД (таблицы, пакеты, индексы и.т.д.) необходимый и достаточный для запуска нашей системы на сервере заказчика. Таким образом одна схема - это данные и настройки одного заказчика. Конкретно тот сервер, про который я пишу - не для реальной работы и реальных данных, там выполняются и тестируются настройки.

Я специально не вдаюсь в подробности, так это мой личный, а не корпоративный блог, поэтому открывать подробности кухни нашей организации не имею ни желания, ни полномочий.

Новая схема появляется с новым заказчиком.

 Вы пишите, что они не зависимы друг от друга

Да, они совершенно независимы.

То есть восстановление одной схемы всегда будет консистентно?

Не совсем понял вопрос. Если бекап данных сделали консистентным, то да. Конкретно на этом сервере в этом нет необходимости.

В случае восстановления схема импортируется в ту же БД с новым именем, тем самым увеличивая их количество?

Либо на этот сервер под другим именем, либо на другой сервер, либо на тестовую среду. Вариантов достаточно.

Это продуктивная или тестовая система?

Продуктивная, но не для заказчиков, а для наших сотрудников

 Вы пишите, что являетесь разработчиком продуктов, что предполагает наличие схем, которые скорее всего должны являться отдельными БД для клиента

Не понял

Oracle позволяет использовать редакцию EE бесплатно, включая все её фичи и возможности для разработчиков, если система не используется в продакшене. 

Тем не менее, это прод

Вы пишите, что у вас есть стендбай, и тут же пишите, что лицензия Standart Edition, для которой стендбаи в классическом виде недоступны. Так SE или EE? Какая версия БД?

А он и не в классическом виде) SE. 11

Вся эта история похожа на то, что ваша БД на самом деле является кучей разных БД слитых в одну базу. И если так, то все проблемы и велосипеды у вас из-за некорректной организации БД

С первой частью согласен, со второй нет. БД организована с максимальным удобством для всех процессов. Вроде так и нужно делать технические решения?

Вся эта история похожа на то, что ваша БД на самом деле является кучей разных БД слитых в одну базу. И если так, то все проблемы и велосипеды у вас из-за некорректной организации БД