medoedУфф. Ну возьмем финансовый сектор или страховой, пусть даже Российский. Крупняк из СУБД выбирает как правило Oracle , мелкий и средний MSSQL. Я сейчас говорю исключительно о количестве, вы с этим будете спорить?
Нет, спорить не буду, обсуждение уже давно вышло за рамки этого раздела форума и место ей в холиварной песочнице пососедству. Свою позицию по вопросу оценки "уровня распростраенности современных СУБД" я уже высказал, но повторю еще раз - я считаю, что если такие оценки и проводить, то сугубо в разрезе заранее определенных метрик и областей применения (как это делает Гартнер со своими квадрантами, например), все остальные способы оценки, а так же выводы, построенные на результах их применения, считаю неприменимыми, порочными и вводящими в заблуждение.

Ну и чтобы вы не обвинили меня в уклоненнии от конкретно заданного вопроса - да, в России, в финансовом и страховом секторе, как впрочем и в любом другом, DB2 проигрывает своим конкурентам по распространенности. Замените Россию на другую страну - и результат может быть уже другой. О чем это говорит? Только лишь о том, что в конкретно взятом регионе, в конкретно взятом секторе деловой активности СУБД MSSQL и Oracle являются более предпочтительными вариантом, чем DB2. Ни на какие другие вопросы эта информация ответов не дает, а только лишь пораждает новые, но это уже совсем другая история.

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

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

n&nБлокировка табличного пространства сейчас может требоваться на операции типа реорганизации, загрузки.
Вовсе нет. Табличное пространство блокируется (выставляется intent lock) при доступе к таблице или индексу (даже если это обычное чтение). Так же оптимизатор может выбрать блокировку табличного пространства в результате lock promotion или lock escalation.

n&nхотел сказать, что пользовательские операции типа DML не блокируют тейблспейс на столько,
что другие DML не смогут обратиться к другим объектам этого пространства (из-за блокировки тейблспейса).
еще точнее, никогда такого не встречал.
Ну, на самом деле ничего удивительного. Да, блокировки при DML операциях на табличное пространство ставятся, но ставятся только intent locks, которые между собой совместимы. При этом повышения до non-intent locks при DML операциях не просиходит никогда. То есть по сути эти блокировки нужны для того, чтобы проверить, что табличное пространство доступно, ну и чтобы всякие возмутители спокойствия (вроде DDL, restore, load) спокойно ждали своего часа. Поэтому стратегия разнесения таблиц по разным табличным пространствам в качестве метода борьбы с блокировками выглядит заведомо выигрышной только в таких экзотических сценариях, как среды с большим количеством параллельных запросов, требующих non-intent locks на табличные пространства.

Гораздо более интересен другой аспект табличных пространств в контексте уменьшения количества блокировок (вы это назвали управление производительностью). Грамотно выбрав параметры табличного пространства (page size, extent size, prefetch size, overhead rate) и разместив контейнеры на отдельных физических носителях, а так же оптимально подобрав размер буфферпула, можно значительно повысить эффективность дисковой подсистемы, что в свою очередь увеличит производительность выполнения запросов, то есть уменьшится время удержания блокировок. При этом я бы так же отметил, что столь тонкая оптимизация нужна скорее для высоконагруженных систем, обрабатывающих большое количество данных, поэтому и была сделана ремарка, что все завист от конкретного приложения.

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

n&nlock escalation с уровня на таблицы на уровень тейблспейса - возможен при DML ?
Нет, прошу прощения, DB2 for LUW не использует табличные пространства вообще никогда при lock escalation, перепутал с Z. Спасибо, что поправили.