Вы совершенно правы, только небольшое уточнение (справедливо для Oralce 11 и 19, может, в других версиях изменения) схемы USERS по умолчанию нет, есть табличное пространство USERS. Схем/пользователей же при создании базы создается несколько больше.
Просто мы с коллегой из соседнего цеха обмениваемся знаниями и опытом, поэтому приходится приводить аналогии, которые, как известно, всегда ложны.
Я, собственно говоря, про это и писал, что каждая база для работы требуют инстанса приложения, который отъедает ЦП и память
И они не могут считаться отдельными БД, хотя бы потому что связаны и зависят друг от друга.
Они, конечно, не могут быть отдельными БД, тут я упростил, но независимыми вполне могут быть - это зависит только от архитектуры приложения. Если приложение располагается в одной схеме, то совершенно спокойно можно делать консистентный бекап данных схемы и восстанавливать ее из дампа без оглядки и влияния на другие схемы/данные
Это действительно очень странный кейс, который, возможно, больше никому и не понадобится) Проблему я описал в статье. Бекап базы не нужен, нужно бекапить данные
Можно восстановить базу на другом компьютере из бекапа базы, но нет смысла делать бекап базы (несколько гигабайт), если нужны только данные (100-300 МБ). Я выше вам ответил, скорее всего непонимание из-за разницы терминологий. Так, например, в Оракле нет отдельной сущности "пользователь", как есть в тех же MySQL или Postgres. Создавая пользователя в Оракл, вы создаете его схему и пространство имен, что для других СУБД аналогично понятию базы.
База в терминологии Оракла - это инстанс БД. То есть нужно запускать множество экземпляров приложения, каждый из которых потребует памяти. Про MSSQL я не знаю, но если провести аналогию, то то, что в MySQL или Postgres называется база, в Оракле называется схема. Возможно, в MSSQL примерно то же самое, поэтому для вас все и выглядит странновато). По сути именно так и делается, каждая схема (читай, база в остальных СУБД) бекапится и ресторится независимо
Подождите, я у вас совета не просил. Моя статья вообще не про то, как нужно бекапить базы. Она про то, что если у кого будет схожая проблема, то вот вам решение, сам написал, сам делюсь. Решение достаточно универсальное, данные восстановятся родными оракловыми утилитами.
Вы мне доказываете, что мы все делаем неправильно и ничего не понимаем в базах. Потрудитесь доказать.
Про trasportable tablespace я в курсе, только этот функционал лично нам никак не полезен.
Я не знаком с MSSQL, но в Оракле ситуация такая: есть бекап базы данных, а есть бекап данных.
Бекап базы данных нужен для максимально быстрого восстановления работы БД при сбоях, а так же при максиммально быстром восстановлении базы данных на другой сервер, в случае отказа сервера. Но вы не можете восстановить часть данных из этого бекапа в другую базу. Потому RMAN про данные, по большому счету, ничего не знает. Он работает с блоками датафайлов. Поэтому бекап RMAN привязан к той базе, из которой он сделан. Нельзя в одну БД восстанавливать датафайлы или отдельные блоки данных, сделанных из другой БД.
Бекап данных снимается утилитами exp или expdp, вы можете выгрузить отдельные таблицы, пакеты и прочие объекты БД в дамп и загрузить из в другую базу данных. У бекапа данных нет привязки к той БД, из которой его сняли. Данные можно восстановить в любую БД, версией не ниже
Эта статья - она про бекап данных, не про бекап БД.
Да вопрос же, вопрос. Ну как вы так уверенно утверждаете, не зная нашей архитектуры и процессов? Табличное пространство - это элемент базы данных, который реализует физическую структуру БД в виде файлов данных. Схема - это логическая структура, которая объединяет объекты в БД в одном пространстве имен. Схемы располагают в отдельных табличных пространствах там, где это оправданно. Лепить на каждую схему свое табличное пространство просто потому, что кому-то так кажется правильным - глупо. И привязывать данные к табличному пространству - тоже глупо. Тем не менее, пожалуйста, напишите мне шаги по разворачиванию одного табличного пространства из RMAN в другой существующий инстанс БД. Хочется убедиться, что вы вообще понимаете, о чем речь.
Нет, это вы упорно путаете бекап базы данных и бекап данных. Я даже в название статьи вынес, что речь про бекап данных. Вы так упорно мне грозитесь документацией по RMAN, но не понимаете разницы? Дамп, который делают утилиты exp и expdp - это бекап данных. Бекап базы данных в данном случае просто не нужен.
Ну и самоое главное, любой новый DBA придет увидит rman и восстановит вам БД или ее часть с закрытыми глазами. В вашем случае специалист со стороны за сколько?
Я уже сбился со счета, чколько раз я это сегодня писал, но нам не нужно восстанавливать БД, нам нужны данные) Если вы у вас есть опыт работы с Ораклом и вы внимательно читали статью, то вы должны увидеть, что данные снимаются родным оракловым механизмом Datapump (именно в таком забирает данные утилита expdp - она использует тот же самый API). Если новый DBA не знает, как загрузить данные из родного для Оракла формата, тогда дела плохи.
Разве нет в Oracle бэкапа логов, которые потом можно накатывать двигаясь вперед? У нас FULL в викенд, далее transaction log раз в 15 мин, так что мы можем восстановиться на любое время
Можно, rman прекрасно умеет такое делать. Но нам не нужен бекап базы, нам нужен бекап данных, не привязанных к конкретному инстансу БД
В вашем случае было бы правильней использовать multi-tenant архитектуру с патчем до 12 версии и разворачивать отдельную PDB для каждой БД заказчика
Проблема только в том, что система разрабатывалась задолго до появления 12 версии, соответственно все процессы строились по техническим возможностям того времени.
Согласитесь, что администрировать штатными средствами удобнее, чем самописными?
Соглашусь. Согласитесь в ответ, что для решения проблем с одним нетипичным сервером совсем не хочется обновлять порядка 1000 серверов на поддержке в максимально короткие сроки и кардинально менять десятилетиями выстроенные процессы. То, что я сделал, в нашей ситуации было абсолютно оправданно. Да и хороший самописный инструмент в компании, занимающейся разработкой - вполне нормальная практика
База в дампе не согласована, PITR не возможен и куча всего, что вам еще написали
Нет, данные в дампе согласованы, так как разработаны соответствующим образом. Да, тут невозможно куча всего, только нам это все и не нужно. А нужно нам другое.
Итого нельзя назвать это бэкапом никак.
Я даже не знаю, как это комментировать. Мы 30 лет храним и восстанавливаем нужные данные, а вы говорите, что это не бекап. Я специально написал в статье - нам не нужен бекап базы, нам нужен бекап данных.
В чем проблема иметь один лвл0 бэкап, который пробегает за выходные и лвл1 каждый день. С учетом того, что рман может сразу и в компрессию и писать на сетевое хранилище.
+ в случае битого блока не придется дропать и перезаливать все данные. Тот же рман спокойно восстанавливает отдельный блок или последовательность.
Проблема тут в том, что, что если нас просят восстановить нужную схему за нужное число на другой сервер (совсем небольшой), то это резко становится практически невозможным. Вы, как и многие комментаторы, пытаетесь меня убедить, что это плохая идея для бекапа БД, у что у рмана куча возможностей для бекапа БД и ее лечения. Но в случае именно этого сервера, нам не нужен бекап БД, нам нужен бекап данных за каждый день. Которые еще и не привязаны к какой-то конкретной базе, эти данные можно быстро восстановить на других базах.
Что есть схема в вашей системе? Какова природа данных в них? Откуда появляются новые схемы?
Схема - это набор объектов БД (таблицы, пакеты, индексы и.т.д.) необходимый и достаточный для запуска нашей системы на сервере заказчика. Таким образом одна схема - это данные и настройки одного заказчика. Конкретно тот сервер, про который я пишу - не для реальной работы и реальных данных, там выполняются и тестируются настройки.
Я специально не вдаюсь в подробности, так это мой личный, а не корпоративный блог, поэтому открывать подробности кухни нашей организации не имею ни желания, ни полномочий.
Новая схема появляется с новым заказчиком.
Вы пишите, что они не зависимы друг от друга
Да, они совершенно независимы.
То есть восстановление одной схемы всегда будет консистентно?
Не совсем понял вопрос. Если бекап данных сделали консистентным, то да. Конкретно на этом сервере в этом нет необходимости.
В случае восстановления схема импортируется в ту же БД с новым именем, тем самым увеличивая их количество?
Либо на этот сервер под другим именем, либо на другой сервер, либо на тестовую среду. Вариантов достаточно.
Это продуктивная или тестовая система?
Продуктивная, но не для заказчиков, а для наших сотрудников
Вы пишите, что являетесь разработчиком продуктов, что предполагает наличие схем, которые скорее всего должны являться отдельными БД для клиента
Не понял
Oracle позволяет использовать редакцию EE бесплатно, включая все её фичи и возможности для разработчиков, если система не используется в продакшене.
Тем не менее, это прод
Вы пишите, что у вас есть стендбай, и тут же пишите, что лицензия Standart Edition, для которой стендбаи в классическом виде недоступны. Так SE или EE? Какая версия БД?
А он и не в классическом виде) SE. 11
Вся эта история похожа на то, что ваша БД на самом деле является кучей разных БД слитых в одну базу. И если так, то все проблемы и велосипеды у вас из-за некорректной организации БД
С первой частью согласен, со второй нет. БД организована с максимальным удобством для всех процессов. Вроде так и нужно делать технические решения?
Спасибо!
Из-за того, что не слышал про zstd? )
Спасибо за информацию, изучу на досуге
Вы совершенно правы, только небольшое уточнение (справедливо для Oralce 11 и 19, может, в других версиях изменения) схемы USERS по умолчанию нет, есть табличное пространство USERS. Схем/пользователей же при создании базы создается несколько больше.
Просто мы с коллегой из соседнего цеха обмениваемся знаниями и опытом, поэтому приходится приводить аналогии, которые, как известно, всегда ложны.
Я, собственно говоря, про это и писал, что каждая база для работы требуют инстанса приложения, который отъедает ЦП и память
Они, конечно, не могут быть отдельными БД, тут я упростил, но независимыми вполне могут быть - это зависит только от архитектуры приложения. Если приложение располагается в одной схеме, то совершенно спокойно можно делать консистентный бекап данных схемы и восстанавливать ее из дампа без оглядки и влияния на другие схемы/данные
Да, если есть права на чтение обеих таблиц
Это действительно очень странный кейс, который, возможно, больше никому и не понадобится) Проблему я описал в статье. Бекап базы не нужен, нужно бекапить данные
Можно восстановить базу на другом компьютере из бекапа базы, но нет смысла делать бекап базы (несколько гигабайт), если нужны только данные (100-300 МБ). Я выше вам ответил, скорее всего непонимание из-за разницы терминологий. Так, например, в Оракле нет отдельной сущности "пользователь", как есть в тех же MySQL или Postgres. Создавая пользователя в Оракл, вы создаете его схему и пространство имен, что для других СУБД аналогично понятию базы.
База в терминологии Оракла - это инстанс БД. То есть нужно запускать множество экземпляров приложения, каждый из которых потребует памяти. Про MSSQL я не знаю, но если провести аналогию, то то, что в MySQL или Postgres называется база, в Оракле называется схема. Возможно, в MSSQL примерно то же самое, поэтому для вас все и выглядит странновато). По сути именно так и делается, каждая схема (читай, база в остальных СУБД) бекапится и ресторится независимо
Подождите, я у вас совета не просил. Моя статья вообще не про то, как нужно бекапить базы. Она про то, что если у кого будет схожая проблема, то вот вам решение, сам написал, сам делюсь. Решение достаточно универсальное, данные восстановятся родными оракловыми утилитами.
Вы мне доказываете, что мы все делаем неправильно и ничего не понимаем в базах. Потрудитесь доказать.
Про trasportable tablespace я в курсе, только этот функционал лично нам никак не полезен.
Veeam BR не умеет в бекап данных Оракла. Он про бекап БД, работает по логике RMAN'а
Как восстановить табличное пространство из бекапа RMAN в другую базу? Можете сценарий RMAN набросать?
Я не знаком с MSSQL, но в Оракле ситуация такая: есть бекап базы данных, а есть бекап данных.
Бекап базы данных нужен для максимально быстрого восстановления работы БД при сбоях, а так же при максиммально быстром восстановлении базы данных на другой сервер, в случае отказа сервера. Но вы не можете восстановить часть данных из этого бекапа в другую базу. Потому RMAN про данные, по большому счету, ничего не знает. Он работает с блоками датафайлов. Поэтому бекап RMAN привязан к той базе, из которой он сделан. Нельзя в одну БД восстанавливать датафайлы или отдельные блоки данных, сделанных из другой БД.
Бекап данных снимается утилитами exp или expdp, вы можете выгрузить отдельные таблицы, пакеты и прочие объекты БД в дамп и загрузить из в другую базу данных. У бекапа данных нет привязки к той БД, из которой его сняли. Данные можно восстановить в любую БД, версией не ниже
Эта статья - она про бекап данных, не про бекап БД.
Скорость в любом случае упрется в железо, а не в ограничения логики бекапа
Да вопрос же, вопрос. Ну как вы так уверенно утверждаете, не зная нашей архитектуры и процессов?
Табличное пространство - это элемент базы данных, который реализует физическую структуру БД в виде файлов данных. Схема - это логическая структура, которая объединяет объекты в БД в одном пространстве имен. Схемы располагают в отдельных табличных пространствах там, где это оправданно. Лепить на каждую схему свое табличное пространство просто потому, что кому-то так кажется правильным - глупо. И привязывать данные к табличному пространству - тоже глупо.
Тем не менее, пожалуйста, напишите мне шаги по разворачиванию одного табличного пространства из RMAN в другой существующий инстанс БД. Хочется убедиться, что вы вообще понимаете, о чем речь.
Нет, это вы упорно путаете бекап базы данных и бекап данных. Я даже в название статьи вынес, что речь про бекап данных. Вы так упорно мне грозитесь документацией по RMAN, но не понимаете разницы? Дамп, который делают утилиты exp и expdp - это бекап данных. Бекап базы данных в данном случае просто не нужен.
Я уже сбился со счета, чколько раз я это сегодня писал, но нам не нужно восстанавливать БД, нам нужны данные) Если вы у вас есть опыт работы с Ораклом и вы внимательно читали статью, то вы должны увидеть, что данные снимаются родным оракловым механизмом Datapump (именно в таком забирает данные утилита expdp - она использует тот же самый API). Если новый DBA не знает, как загрузить данные из родного для Оракла формата, тогда дела плохи.
Можно, rman прекрасно умеет такое делать. Но нам не нужен бекап базы, нам нужен бекап данных, не привязанных к конкретному инстансу БД
так нам нужно иметь возможность и в другую базу)
Проблема только в том, что система разрабатывалась задолго до появления 12 версии, соответственно все процессы строились по техническим возможностям того времени.
Соглашусь. Согласитесь в ответ, что для решения проблем с одним нетипичным сервером совсем не хочется обновлять порядка 1000 серверов на поддержке в максимально короткие сроки и кардинально менять десятилетиями выстроенные процессы. То, что я сделал, в нашей ситуации было абсолютно оправданно. Да и хороший самописный инструмент в компании, занимающейся разработкой - вполне нормальная практика
Нет, данные в дампе согласованы, так как разработаны соответствующим образом. Да, тут невозможно куча всего, только нам это все и не нужно. А нужно нам другое.
Я даже не знаю, как это комментировать. Мы 30 лет храним и восстанавливаем нужные данные, а вы говорите, что это не бекап. Я специально написал в статье - нам не нужен бекап базы, нам нужен бекап данных.
Проблема тут в том, что, что если нас просят восстановить нужную схему за нужное число на другой сервер (совсем небольшой), то это резко становится практически невозможным.
Вы, как и многие комментаторы, пытаетесь меня убедить, что это плохая идея для бекапа БД, у что у рмана куча возможностей для бекапа БД и ее лечения. Но в случае именно этого сервера, нам не нужен бекап БД, нам нужен бекап данных за каждый день. Которые еще и не привязаны к какой-то конкретной базе, эти данные можно быстро восстановить на других базах.
Схема - это набор объектов БД (таблицы, пакеты, индексы и.т.д.) необходимый и достаточный для запуска нашей системы на сервере заказчика. Таким образом одна схема - это данные и настройки одного заказчика. Конкретно тот сервер, про который я пишу - не для реальной работы и реальных данных, там выполняются и тестируются настройки.
Я специально не вдаюсь в подробности, так это мой личный, а не корпоративный блог, поэтому открывать подробности кухни нашей организации не имею ни желания, ни полномочий.
Новая схема появляется с новым заказчиком.
Да, они совершенно независимы.
Не совсем понял вопрос. Если бекап данных сделали консистентным, то да. Конкретно на этом сервере в этом нет необходимости.
Либо на этот сервер под другим именем, либо на другой сервер, либо на тестовую среду. Вариантов достаточно.
Продуктивная, но не для заказчиков, а для наших сотрудников
Не понял
Тем не менее, это прод
А он и не в классическом виде) SE. 11
С первой частью согласен, со второй нет. БД организована с максимальным удобством для всех процессов. Вроде так и нужно делать технические решения?
в другую базу?