База данных - это набор файлов, которые содержат в себе данные, физически расположенные на диске
Инстанс(базы данных) - это набор процессов, которые обслуживают саму базу данных.
Соответственно Инстанс != БД. При использовании RAC у вас будет одна база данных и 2 и более инстанса, которые эту БД обслуживают.
В Postgres базой данных так же называется набор файлов, который содержит в себе данные, физически расположенные на диске. Логически база данных располагается в кластере. Для каждой базы данных в кластере существует подкаталог внутри PGDATA/base на диске
То что в оракле называется схемами - это созданная учетная запись пользователя и объекты, которые ей принадлежат. Служит чаще всего для логического разделения объектов одной базы данных и прав к ним. В частности в любой БД Oracle, есть как минимум 3 схемы - USERS(или любая другая польз.схема) и системные SYSTEM,SYS. И они не могут считаться отдельными БД, хотя бы потому что связаны и зависят друг от друга.
Если уж и проводить аналогию с Postgres, то ближайшим аналогом кластера и БД входящих в кластер, будет оракловая Multitenant архитектура, где в рамках одной CDB будет располагаться множество PDB использующие общие ресурсы и общую память.
В вашем случае было бы правильней использовать multi-tenant архитектуру с патчем до 12 версии и разворачивать отдельную PDB для каждой БД заказчика. В таком случае можно было бы бэкапить только нужные PDB и стандартными средствами разворачивать их, стандартными же средствами восстанавливать хоть на текущий сервер, хоть на соседний и делать это довольно быстро.
БД организована с максимальным удобством для всех процессов
Максимальное удобство для всех процессов, наверное включает в том числе и процессы администрирования?
Согласитесь, что администрировать штатными средствами удобнее, чем самописными?
Что есть схема в вашей системе? Какова природа данных в них? Откуда появляются новые схемы? Вы пишите, что они не зависимы друг от друга. То есть восстановление одной схемы всегда будет консистентно? В случае восстановления схема импортируется в ту же БД с новым именем, тем самым увеличивая их количество? Это продуктивная или тестовая система? Вы пишите, что являетесь разработчиком продуктов, что предполагает наличие схем, которые скорее всего должны являться отдельными БД для клиента. Oracle позволяет использовать редакцию EE бесплатно, включая все её фичи и возможности для разработчиков, если система не используется в продакшене. Вы пишите, что у вас есть Standby, и тут же пишите, что лицензия Standart Edition, для которой Standby в классическом виде недоступны. Так SE или EE? Какая версия БД использутеся?
Вся эта история похожа на то, что ваша БД на самом деле является кучей разных БД слитых в одну базу. И если так, то все проблемы и велосипеды у вас из-за некорректной организации БД
Спасибо за статью, познавательно.
Скажите, а как утилита справляется с переносом пакетов, хранимых процедур? В том числе, интересно возможно ли вообще этой штукой переносить очень большие пакеты, размерами больше 100к строк?
Согласен. Заведомо делать архитектуру, где необходимо слать внешний запрос на каждый проезд авто — такое себе решение.
Камера точно может прочитать номер. Наверняка может хранить в себе одну табличку, с парой даже не «дата истечения страховки-номер», а «флаг наличия страховки-номер»
Раз в день эту таблицу обновлять на всех камерах. То есть номер — 10 байт+флаг 1 байт
итого 11млн байт~1050мб. Более того, можно еще упростить и хранить таблицу с одними лишь номерами, у которых нет страховки. и искать совпадение по ним. Размер будет еще меньше.
С другой стороны, если известно что отправляются все факты проезда автомобиля под камеру, то обработку можно проводить не он-лайн, а так же раз в сутки — запросили ту же табличку номеров, у которых нет страховки, сверили с дневными данными, убрали дубли за день от разных камер, выслали штрафы
Вы плаваете в терминологии.
База данных - это набор файлов, которые содержат в себе данные, физически расположенные на диске
Инстанс(базы данных) - это набор процессов, которые обслуживают саму базу данных.
Соответственно Инстанс != БД. При использовании RAC у вас будет одна база данных и 2 и более инстанса, которые эту БД обслуживают.
В Postgres базой данных так же называется набор файлов, который содержит в себе данные, физически расположенные на диске. Логически база данных располагается в кластере. Для каждой базы данных в кластере существует подкаталог внутри
PGDATA/baseна дискеТо что в оракле называется схемами - это созданная учетная запись пользователя и объекты, которые ей принадлежат. Служит чаще всего для логического разделения объектов одной базы данных и прав к ним. В частности в любой БД Oracle, есть как минимум 3 схемы - USERS(или любая другая польз.схема) и системные SYSTEM,SYS. И они не могут считаться отдельными БД, хотя бы потому что связаны и зависят друг от друга.
Если уж и проводить аналогию с Postgres, то ближайшим аналогом кластера и БД входящих в кластер, будет оракловая Multitenant архитектура, где в рамках одной CDB будет располагаться множество PDB использующие общие ресурсы и общую память.
В вашем случае было бы правильней использовать multi-tenant архитектуру с патчем до 12 версии и разворачивать отдельную PDB для каждой БД заказчика. В таком случае можно было бы бэкапить только нужные PDB и стандартными средствами разворачивать их, стандартными же средствами восстанавливать хоть на текущий сервер, хоть на соседний и делать это довольно быстро.
Максимальное удобство для всех процессов, наверное включает в том числе и процессы администрирования?
Согласитесь, что администрировать штатными средствами удобнее, чем самописными?
Что есть схема в вашей системе? Какова природа данных в них? Откуда появляются новые схемы? Вы пишите, что они не зависимы друг от друга. То есть восстановление одной схемы всегда будет консистентно? В случае восстановления схема импортируется в ту же БД с новым именем, тем самым увеличивая их количество? Это продуктивная или тестовая система? Вы пишите, что являетесь разработчиком продуктов, что предполагает наличие схем, которые скорее всего должны являться отдельными БД для клиента. Oracle позволяет использовать редакцию EE бесплатно, включая все её фичи и возможности для разработчиков, если система не используется в продакшене. Вы пишите, что у вас есть Standby, и тут же пишите, что лицензия Standart Edition, для которой Standby в классическом виде недоступны. Так SE или EE? Какая версия БД использутеся?
Вся эта история похожа на то, что ваша БД на самом деле является кучей разных БД слитых в одну базу. И если так, то все проблемы и велосипеды у вас из-за некорректной организации БД
Скажите, а как утилита справляется с переносом пакетов, хранимых процедур? В том числе, интересно возможно ли вообще этой штукой переносить очень большие пакеты, размерами больше 100к строк?
Камера точно может прочитать номер. Наверняка может хранить в себе одну табличку, с парой даже не «дата истечения страховки-номер», а «флаг наличия страховки-номер»
Раз в день эту таблицу обновлять на всех камерах. То есть номер — 10 байт+флаг 1 байт
итого 11млн байт~1050мб. Более того, можно еще упростить и хранить таблицу с одними лишь номерами, у которых нет страховки. и искать совпадение по ним. Размер будет еще меньше.
С другой стороны, если известно что отправляются все факты проезда автомобиля под камеру, то обработку можно проводить не он-лайн, а так же раз в сутки — запросили ту же табличку номеров, у которых нет страховки, сверили с дневными данными, убрали дубли за день от разных камер, выслали штрафы