Попадались мне за всю историю разные базы данных в совершенно разных вариантах, не буду называть имена, не этично, но крупные организации и машиностроения, и сотовой связи, и коммерческие проекты. Как правило, их объединяет одно - дикий бардак проектирования. Сейчас это еще все сильно усугубляется попытками импортозамещения, но из всех баз, которые я получал в руки, Oracle является действительно обеспечивающей серьезный подход к целостности данных. Я сдавал экзамены по db2 в свое время, очень симпатичная СУБД, поставил бы на второе место после Oracle, но никак не замена, Postgres в разных ипостасях и редакциях совершенно непригодна для промышленного использования, уж извините, детские болезни, ведущие к потере данных и недостаток функционала, вроде поблочного исправления базы или возможности открыть резервную в снапшоте... MS SQL несерьезна, потому, что работает только на Windows, а Windows я серверной ОС не рассматриваю. Мелочь всякую, вроде MySQL и всякие базы, которые притворяются Oracle, позвольте не будем о грустном.
Кто-то догадывается серьезные вещи на Windows делать, кто-то на полумертвых архитектурах без саппорта сервера поднимает, кто-то на бета-версиях Oracle ключевые версии поднимает... Диву даешься иногда, как это все работает. Попробую как-то сформулировать набор полезных советов, исходя из своего опыта.
У проекта должен быть архитектор, который его, собственно и проектирует, то есть определяет процессы, происходящие в базе и их взаимосвязь. Лоскутное проектирование, когда одна команда валит процессы другой, недопустимо для серьезной команды. Если в компании используется нищебродский подход и на архитекторе экономят, то с каждым годом проект будет ближе к коллапсу и сама СУБД тут будет не при чем.
Проектирование обязательно должно включать в себя планирование нагрузки. Это включает в себя уверенное понимание, сколько пользователей работает в базе в единицу времени и сколько ресурсов они каждый при этом потребляют. Сервер имеет вполне себе ощутимые границы процессора и носителя, поэтому, для предсказуемого поведения системы необходимо либо четко зафиксировать нагрузку, либо иметь двукратный запас мощностей от максимальной загрузки за полный цикл процессов. Пользователи должны быть обязательно ограничены, например, разделяясь на три профиля, каждый из которых будет лимитирован по CPU.
Например, мы знаем, что одновременно у нас будут работать 500 пользователей. Работать - это не просто количество лицензий, а именно одновременно запускают какой-то обсчет (не из сети что-то тащить, а именно работать CPU). То есть, это процессор. Нужно 500 ядер, которые будут этих пользователей обслуживать. И, ради всего святого, не ведитесь на всякий маркетинг, вроде Hyperthreading в x86_64, либо потоков в Solaris и AIX, нужны реальные ядра. Если обсчет связан с работой дисков, то это много дисков, очень много дисков и обязательно много IOPs на контроллере.
На практике бедную лошадь, коим является перегруженный и переоцененный сервер, нагружают сверх меры, наивно полагая, что каждый пришедший да и не уйдет обиженным. Не забывайте, что на 10 ядрах 500 потоков по времени - это совсем не то же, что на 10 ядрах 50 раз по 10 потоков... Сервер в единицу времени может обработать только одну операцию на ядро из одного потока, если потоков больше, чем ядер, то сервер будет тратить ресурсы на переключения контекста, разбираться, что ему надо делать, кому и куда сейчас идти. Это все тоже не бесплатно, и чем больше превысить нагрузку, тем больше будут накладные расходы. Аналогично и с дисками, как физическими устройствами, хотя и сложнее считается.
Выбирайте правильно операционную систему для базы и трижды подумайте над виртуализацией. Чтобы она достойно работала, необходимо, чтобы и админы виртуализации хорошо понимали, что такое база, и админы базы хорошо понимали, что такое виртуализация. Удобств море, но все это опять небесплатно и с кучей нюансов, которые необходимо учитывать. Если говорить про операционку, то по стабильности работы, наверное, больше всего мне понравился Solaris на Sparc. HP-UX уже благополучно закопали, там еще и Itanium мне попался, AIX был на PowerPC, и, надо сказать, это сочетание бесчеловечности Unix, как в случае Solaris, по отношению к админу, со слабостью процессора и относительной нестабильностью, чего в Solaris не было. Понятное дело, что та солярка уже тоже уходит в небытие, потому сейчас, пожалуй, единственное, что можно рассматривать - Oracle Linux на x86_64 хорошей конфигурации. Я работал на всех этих операционках в том числе и админом самой операционки, выводы сделал именно такие.
Не используйте базу данных, как клиент. Никогда. Мне попадались базы, в которых был встроен SMTP-клиент, опять же всякие шлюзы в другие базы и т.п. Поверьте на слово, все эти случаи плохо заканчивались. Весь транспорт, который может быть для одиночного клиента испытанием таймаутом, в случае с СУБД кончается кучей таймаутов и выходом базы из строя. Клиент вы можете перезагрузить по тихому, перезагрузка базы ставит под удар весь сервис. Просто поверьте, и никогда так не делайте.
Не используйте работу через db-линки. Ровно та же самая причина, что и в случае с клиентами, но усугубляется еще и очень нестабильной работой запросов через линки. Планы едут, толпы процессов через линк толпятся, начинается каша и бардак. Разово поработать руками через линк - одно, строить на этом процесс - не рекомендую категорически. Если встает вопрос синхронизаций и прочего - есть шины данных и прочие CDC (content data capture), у меня на памяти вполне нормально работал kafka, только определите количество его потоков и, понятное дело, он не должен работать на сервере с СУБД.
Не полагайтесь на штамповку бесконечного количества джобов. Попался случай, когда организация нашпингалетила в базу более 500 джобов, которые каждый запускался чуть ли не произвольно по времени, в итоге все это богатство сталкивалось, разбегалось, перезапускалось, убивало сервис и потребовалось очень много времени, чтобы переписать это все, объединяя до вменяемого количества и разнося по разным другим сервисам.
Обязательно предусматривайте архитектуру хранения. У меня были базы больше 230Тб, я знаю, о чем говорю. Были базы в которых творился ад, в виде возможности заводить собственные таблицы кому попало, были большие базы, которые целиком состояли чуть ли не из одной таблицы, из которой все подряд забирали данные, и запихивали дополнительные.
Каждый сегмент базы данных должен быть легко переварен имеющимся железом, например, при необходимости его реорганизовать или перенести, а, главное, все процессы, занимающиеся обсчетом и получением данных не должны повторяться в своих расчетах. Если клиент тратит время на выборку данных, выбирая 1000000 строчек, а потом суммируя, например, что-то из них, другой опять выбирает 1000000 строчек и опять суммирует, то налицо проблемы архитектуры хранения и прожигание процессорного времени. Заранее определите размер самых нагруженных сегментов через 20 лет.
Не рекомендую использовать result cache в Oracle, вещь достаточно глючная на текущий момент (19 версия), при неудачном стечении обстоятельств получите дичайшие блокировки и последовательный доступ к данным для кучи сессий.
Не рекомендую полагаться на resource manager, описать точно, что он делает и почему вдруг начинает блокировать сессии или джобы, практически невозможно. Глюк на глюке и связанные глюки, приводящие к простою процессов. Профили есть с ограничениями - используйте их. Понятно, что там достаточно убогие варианты порулить, но это лучше, чем получить совершенно непредсказуемое поведение базы. И любители придавить, поставить приоритеты и т.д. совершенно забывают, что вымывание кеша и накладные расходы переключения контекста никуда не пропадают. Не используйте, это плохо работает.
Заранее определите какого класса нагрузка будет на базу OLTP или DWH, в зависимости от этого будет настраиваться и база, и система. Не смешивайте эти нагрузки, поскольку разделить их потом будет крайне трудно, а DWH-нагрузка однозначно начнет сказываться на OLTP-запросах.
При проектировании инфраструктуры не забывайте, что серьезный подход подразумевает обязательно хотя бы один standby, то есть, резервную базу, обязательно тестовую базу, а, скорее всего, и не одну, а еще обязательно бекапы...