Терминология SQL Server и Oracle

Много работая с SQL Server в прошлом, я сочувствую попыткам выяснить, как Oracle организует вещи, когда я боролся с тем же самым. Мои комментарии ниже относятся к SQL Server 2000 и 2003, поэтому простите меня, если с тех пор что-то изменилось.

Предыдущие ответчики были полезны. Я думаю, что одно проблематичное предположение здесь заключается в том, что между SQL Server и Oracle существует точная эквивалентность «уровня». Под «уровнем» я подразумеваю то, что занимает то же место в иерархии, что вы нарисовали выше (и, кстати, я думаю, что это хорошее место для начала, но может потребоваться небольшое редактирование в нескольких местах, для например, как вы изобразили «пользователя» и «схему» в иерархии Oracle, я мог бы поставить их рядом.) Я не думаю, что эти концепции «уровни» точно совпадают между платформами БД.

Схема в Oracle несколько эквивалентна отдельной базе данных в SQL Server, но не полностью.

Я бы сказал, что «стены» — не совсем точный технический термин, но да ладно — между базами данных в SQL-сервере немного выше, чем «стены» между схемами в Oracle. Другие могут не согласиться, но вот мое рассуждение:

а. Схема в Oracle — это чисто логическая конструкция. Он указывает, кому принадлежит право собственности на объекты. Это не имеет ничего общего с физическим расположением или расположением объектов. Табличное пространство (прямоугольная концепция, как отмечалось в предыдущем постере) указывает физическое расположение объектов. Табличное пространство может содержать объекты, находящиеся в нескольких схемах, и наоборот. В SQL Server эти две концепции как бы объединены в одну — база данных является и табличным пространством, и схемой, более или менее, хотя в некоторых отношениях в БД в SQL Server у вас есть несколько владельцев с разными владельцами объектов. Это может немного сбить с толку, потому что, насколько я помню (прошло пару лет), если не используется аутентификация NT, пользователи определяются на уровне сервера, а затем должны «связываться» с пользователями в отдельных БД.

б. Я помню, что мне было проще или, по крайней мере, немного проще убедиться, что пользователи двух отдельных БД в SQL Server не имеют доступа к относительной БД другого пользователя, чем я нашел это в Oracle.

в. Поскольку БД на сервере SQL представляет собой как физическое хранилище, так и логическое владение, вы можете отсоединить БД, переместить ее в другой экземпляр SQL Server и присоединить. Вы не можете сделать это со схемой в Oracle. Я имею в виду, что вы можете выкачивать данные или делать их резервную копию или что-то еще на другой сервер и другую схему, но все это требует, по крайней мере, некоторых сценариев и тому подобного или, по крайней мере, достаточного количества кликов в Enterprise Manager. Это не дает вам возможность одним щелчком мыши «Отсоединить БД», которая есть в SQL Server, что значительно упрощает понимание того, что БД SQL Server — это единицы, которые вы можете более или менее перемещать туда и обратно между базы данных.

Подводя итог, я думаю, что любой вариант будет работать. То есть 1) Создайте два отдельных экземпляра Oracle с одной схемой в каждом экземпляре для каждого приложения или 2) Создайте две отдельные схемы в одном экземпляре Oracle.

Есть плюсы и минусы для каждого варианта. Вариант 1, вероятно, потребует больше усилий для настройки и настройки, но также даст вам больше разделения, независимости, возможности иметь отдельное оборудование и т. д. для каждой БД. Вариант 2 будет немного проще, но даст вам меньшее разделение между данными и больший риск ошибок конфигурации или других вещей, позволяющих пользователям одной схемы получить доступ к другой. Это также означает, что вы должны быть немного более осторожными, чтобы кто-то, пишущий запрос для доступа к данным в одной схеме, не использовал все ресурсы ЦП и ввода-вывода и не лишал пользователя другой схемы.

Кроме того, да, вы можете использовать подключаемые базы данных в 12c. Однако, учитывая тот факт, что вам нужно задавать эти вопросы (не стыдно, просто указывая, где вы находитесь), я не решаюсь рекомендовать то, что может легко быть более сложной настройкой.

TL;DR — SQL Server — это не Oracle, а Oracle — это не SQL Server. Любой вариант работает, и у каждого есть свои плюсы и минусы.

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

Создание базы данных

Если вы создадите отдельную базу данных, вы получите полностью отдельные структуры памяти (т. е. SGA и PGA для каждой базы данных будут отдельными), а также совершенно отдельный набор фоновых процессов (каждая база данных будет иметь свой собственный процесс записи журнала). (а) например). Это очень тяжелый вариант — у вас не может быть слишком много баз данных на одном сервере, прежде чем вы начнете сильно конкурировать за ОЗУ, за планирование всех фоновых процессов и т. д. Он обеспечивает максимальное разделение между различными приложениями. -- на каждой базе данных может работать другая версия Oracle с другим набором параметров инициализации, -- но это также приводит к усложнению управления средой. Как правило, это имеет смысл только в том случае, если у вас есть сторонние приложения, которым требуется определенная версия базы данных или определенный набор параметров инициализации.

Создание схемы

Если вы создаете отдельную схему, у вас по-прежнему будет одна база данных, поэтому две схемы совместно используют одни и те же структуры памяти (например, конкурируя друг с другом за место в буферном кеше SGA), параметры инициализации и т. д. немного планирования, чтобы гарантировать, что эти два не мешают друг другу - вы, вероятно, захотите убедиться, что нижнее приложение создает общедоступные синонимы или, по крайней мере, что они не захотят создавать тот же общедоступный синоним, что и другой application-- но это, как правило, довольно тривиально.

Создание подключаемой базы данных

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

Вы должны создать новый экземпляр (схему) в той же базе данных, где схема в оракуле такая же, как в базе данных SQL-сервера.