Доброго времени суток всем.

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

Есть ли у кого-то не обоснованные на методе научного тыка подходы к конфигурированию
необходимого количества временных пространств не связанные с количеством дисков ?

DrGonzo

вопросы по вашему ответу:
1. интенсивность работы с временным пространством
Что именно и как нужно измерять?
onstat -D, iostat - не годятся - по ним нет пиков в моменты проблем

2. Спецификация железа.
диски - отпадают, так как я писал именно о множественности а не о распределении нагрузки
ЦПУ, память - возникает вопрос к качеству ПО - на 11.50 проблем не было

3. какие у вас критерии для определения загруженности?
Здесь, думаю, сможете назвать какие-то цифры.

Andron,

Как снимать статистику onstat -D, iostat - я знаю.
Я говорю о том, что эта статистика в моем случае не годится - она не показывает увеличения активности в проблемные моменты.
и, следовательно, исходить из этой статистики при определении количества временных таблиц я не могу.

DrGonzo...
- частоту создания временных таблиц и тд
...

Вот и добрались.
И как ее измерять-то предлагаете?

DrGonzoяфшуеі,

Регулярно делайте срезы по мониторингу мютексов (onstat -g lmx, onstat -g wmx). Если очередь к соотв. мутексу растет - повод к добавлению пространства.


a) Мы не знаем, менялось ли Ваша система/окружение или нет. Мы не знаем, мониторили ли Вы ее адекватно на 11.50 или нет.
б) 11.50 - слишком широкое понятие. Пишите конкретно на какой версии у Вас проблем не было, а на какой появились.
в) Если Вы можете продемонстрировать "проблему" на 11.70 и ее отсутствие на 11.50 при прочих равных - обращайтесь в поддержку.
г) В лиц. соглашении пользователь информируется о потенциальных рисках. Если Вы обнаружили эту проблему только в процессе работы сервера в "боевом" режиме - здесь вопрос к качеству Вашего предмиграционного тестирования.




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

б) была миграция 11.50fc5w2 -> 11.70fc4
в) в поддержке довольно давно уже открыто 2 обращения, но далее как рекомендации установки
нескольких пространств дело не продвинулось
Мы не враги себе - выставили несколько пространств и проблема ушла.
Вернуть все назад и заниматься изучением проблемы на боевом сервере - это не для нас.
Тем более, что сохранение дампа не гарантирует, что корень проблемы будет найден.

г) мы не претендуем на то, что у нас было полноценное тестирование
его если и могут провести в многопользовательской среде - то только единицы
Правда, еще дао может провести - у него довольно простая специфика приложения.

Да что говорить - такую явную проблему как неосвобождение памяти при репликации RSS - решили только в хС5.
Т.е. закидоны только на наше тестирование не проходят.

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

Если вам так нравятся мьютексы, возьмем ситуацию:
1. Проблема связана только с временными таблицами
2. Все таблицы создаются как select ... into temp .. with no log;

при одинаковом "тестировании" ситуации
при 1м временном пространстве мы имеем Н обращений к мьютексу
при 5 - 5Н - т.е. к каждому мьютексу Н раз и желаемого расспараллеливания обращений к мьютексам нет
и соответстенно рекомендации о нескольких пространствах под вопросом

А запросов select ... into temp .. with no log, которые выбирают всего несколько записей - наверное большинство.

Еще момент - есть такой АПАР
http://www-01.ibm.com/support/docview.wss?uid=swg1IC61072
связанный с dbs_partn_
для версии 10.00 оно попал в defect fixes который поставляется с сервером, для 11.50 - нет,
хотя и сказано что он пофиксен в xC4 но рекомендуют обновиться до хС6
то, что в описании ошибки есть упоминание о 11.50, рекомендация не совпадает с фиксом и ошибки
нет в дефектах, которые идут с 11.50 - настораживает.



Относительно "частоту создания временных таблиц и тд"
я в первом своем сообщении не указывал что это таблицы - я указал _temptable
По AF, которые есть, _temptable создаются в подзапросах.
на нескольких тысячах сессий промониторить интенсивность вызовов подзапросов - даже не представляю как.
лазание по сисмастеру - небыстрое да и может быть в данном случае с последствиями - например с мьютексом session

DrGonzoяфшуеіпри одинаковом "тестировании" ситуации
при 1м временном пространстве мы имеем Н обращений к мьютексу
при 5 - 5Н - т.е. к каждому мьютексу Н раз и желаемого расспараллеливания обращений к мьютексам нет
и соответстенно рекомендации о нескольких пространствах под вопросом


На основании чего сделан такой вывод? В моем понимании, каждому пространству должен соответствовать свой мютекс. Соотв. при наличии нескольких временных пространств, доступ к ним будет в режиме "карусели". Отсюда должно следовать, что при увеличении количества пространств количество запросов на конкретный мютекс снизится, т.к. конкурировать за конкретный мютекс будет меньшее число сессий. Что, как я понимаю, и было подтверждено практикой в Вашем случае - проблема ушла.

одно дело - частное решение с головы. ( "как-то так" оно работает)
другое дело - системный подход

относительно карусели - карусель не касается select into temp ... with no log;
в приведенном случае будет вместо 1 карусели - несколько, которые быдут накладываться.
Запрос на управление параллелизмо into temp ... with no log сделали - но реализуют ли - пока неизвестно.

Еще раз - имеем select into temp ... with no log;
Поведение оператора в документации описано біло неправильно - на самом деле работает параллелизм.
Соответствующий АПАР документации открыт и должны исправить или уже исправили.
Если определено 1 пространство - оператор создаст 1 таблицу - запрос будет к 1 мьютексу.
Если определено Н пространств - оператор создаст фрагментированную таблицу с Н фрагментами и обращение будет к Н мьютексам.
Да, у нас увеличилось количество учавствовавших мьютексов, но в предлагаемой ситуации
очередь от этого не уменьшилась а только создалось Н таких же очередей - т.е. при одновременном обращении
к защелке 100 сессий раньше была очередь к 1 защелке длиною 100, то теперь Н очередей с такой же длиной - т.е. Н каруселей.

В реальности такая ситуация вряд ли возможна - но в жизни всякое бывает - может найтись разработчик, которому
в лом каждый раз создавать временную таблицу как create table. До определенного момента все будет хорошо,
а потом стрельнет и саппорт скажет - переписівайте софт или меняйте ЦПУ и шину.

фиг с мьютексом - его то как-раз опосредованно можно мониторить.
Рассматриваем то вариант не только с мьютексом.

Ответьте все-таки вопрос - как мониторить и измерять "частоту создания временных таблиц и т.д."
Интересует только интенсивность создания/удаления временных объектов, возможно еще и интенсивность віделения для них экстентов.

:)

Относительно того, почему стояло 1 временное пространство в параметре DBSPACETEMP.
На днях вышел 11.70хC5W1 , второй исправленной ошибкой стоит та моя ситуация или похожая на нее:
IC79310: CREATING AN INDEX ON A FRAGMENTED TEMP TABLE THROWS -212/-113 AS DOES CREATING A FRAGMENTED INDEX ON A TEMP TABLE

212 ошибка у заказчиков возникала на 9.21 и лечили ее именно установкой 1 временного пространства - схожие
ошибки видимо ходят по кругу.
С тех пор, не видя реальной потребности в нескольких пространствах - больше одного пространства не устанавливал.