Вопросы истории ИТ и ОС

[zVlad]

Много значит больше одного. Я насчитал, думал сказать три как и говорил выше, но на самом то деле в Оракл есть именно один пул каждого типа. А речь идет о многих пулах одного и того де типа. Их в Оракл нет. Если есть покажите, я пока не увидел.

Значит таки документацию не осилил. Это три пула с разными названиями, но с одним и тем же алгоритмом.

Each buffer pool uses the same LRU replacement policy.

У вас 100ГБ "горячих" объектов, ну так создайте под них пул на 100ГБ. После нагрузки посмотрите оценки количества IO в завимимости от размера пула, и прыгайте дальше. Зачем делать 10 пулов по 10ГБ под горячие объекты?

я вот тут ссылочку подискал (их много на самом деле и при желании Вы можете найти свою):
http://enterprisesystemsmedia.com/artic ... 20qspwjefe" onclick="window.open(this.href);return false;)&ts=1446903806

Теперь понятно зачем в DB2 столько пулов. Исходите из того, что сразу в оракле 4ре пула: system, work и по большей части LOB/XML не нужны, эти функции выполняются другими специализированными кусками памяти.

Алгоритм LRU - это единственный алгоритм используемый в Оракл для БП?

К счастью да.
FIFO не нужен. Операции чтения\записи, которые подходят для FIFO, вообще до кэша (в вашем понимании) не доберутся. Для обычных операций, объект всё еще может наслаждаться LRU.

Осилить документацию Оракл не просто, мешает вольное обращение с терминологией. В одном абзаце может быть и "buffer pool" и "buffer caсhe" и еще что-нибудь. Но в принципе осилить не мудренно.

А вот сказаное мной и написанное в предложенной статье Вы точно не осилили. Опять домыслы и передергивания.
Причем здесь разные название и одинаковые алгоритмы? Назвали их по разному разработчики Оракл и имплементировали как разные области памяти с разным назначением оставленным на усмотрение Oracle DBA. И это все. И в большенстве случаев Oracle DBA не заморачивается и использует лишь один пул, DEFAULT, что и делает наш DBA.
Вы так не поделились тем что именно Вам понятно о том "зачем в DB2 столько пулов".
В DB2 v8 50 Buffer pools не считая тех что имеют иной чем 4К размер страницы. BP0 используется для таблиц каталога, BP1 умалчиваемый пул для таблиц, BP2 умалчиваемый для индексов. У нас несколько горячих таблиц/индексов имеют свои пулы такого размера как таблицы и часть из них даже зафиксированны в памяти.
Во время старта DB2 выполняется запрос с table scan/index scan на них что помещать их полностью в их пулы и они ничем из этих своих пулов вытеснены быть не могут. Прелесть такого конфигурирования в том что можно не только выделить горячие объекты в отдельные пулыб но и назначит пулам разные свойства. Для пулов где нет вытеснения лучше алгоритм FIFO потому что он менее ресурсоёмкий чем LRU. Кроме того можно учесть в параметрах BP свойства последовательного или случайного обращения.
В Оракле ничего такого просто нет. Поэтому Оракл надо больше памяти чтобы достичь того же уровня производительности что у DB2 с меньшим объемом памяти. Теперь Вам понятно? Просто в памяти DB2 больше порядка и как результат меньше ввод-вывод.

[Dmitry67]

В данном случае zVlad прав и точной настройкой пулов можно немного повысить эффективность их работы, то есть 16гиг пулов будут работать, допустим, как 24 у оракла или ms sql. Да вот только там за куда меньшие деньги можно поставить 240 гиг )

Так что данное решение описывается поговоркой "Голь на выдумки хитра". Именно поэтому я вспомнил домашнему мастеру советы. Не спешите выбрасывать старую велосипедную камеру...

[mskmel]

В данном случае zVlad прав и точной настройкой пулов можно немного повысить эффективность их работы, то есть 16гиг пулов будут работать, допустим, как 24 у оракла или ms sql

Не верю, что много народу сможет филигранно настроитьт все эти 50 пулов. Под какой-нить тест, еще верю что можно очень точно настроить размеры пулов и закрепить объекты за этими пулами. В реальной жизни в такую удачу не верю.
zVlad выше привелстатистику по своим15-16 пулам, там данные спрашивают, только из одного, остальные почти "спят".
Возможно (!) есть какие то архитектурные особенности DB2, которые исторически заставили сделать столько пулов. NUMA nodes какие-нибудь, отдельные writers процессы или еще что.

Да вот только там за куда меньшие деньги можно поставить 240 гиг )

Именно! 3 пула по 100ГБ в Оракле - всегда заборят 15 по 1ГБ в ДБ2

И чего до этих пулов привязались - не ясно. Одна из настроек, требующих меньше всего времени Памяти как правило больше, чем имеет смысл отводить под DB cache, да и advisor жизнь облегачет.

[mskmel]

У нас несколько горячих таблиц/индексов имеют свои пулы такого размера как таблицы и часть из них даже зафиксированны в памяти.

Начнём с того, что горячие таблицы итак по LRU будут в памяти оставаться.
И мне не ясно, чем 10 пулов по 10ГБ по 1 таблице в каждом, лучшем чем 1 пул на 100ГБ для этих же 10 таблиц.

Для пулов где нет вытеснения лучше алгоритм FIFO потому что он менее ресурсоёмкий чем LRU.

Сколько сотых процентов CPU уходит на управление пулами?

В Оракле ничего такого просто нет. Поэтому Оракл надо больше памяти чтобы достичь того же уровня производительности что у DB2 с меньшим объемом памяти. Теперь Вам понятно?

Имеющиеся паблик тесты этого факта не подверждают.

[Dmitry67]

Не верю, что много народу сможет филигранно настроитьт все эти 50 пулов. Под какой-нить тест, еще верю что можно очень точно настроить размеры пулов и закрепить объекты за этими пулами. В реальной жизни в такую удачу не верю.

Ну если 10 лет идет одна и та же нагрузка от атомной станции, то вполне можно 10 лет вылизывать конфигурацию
И показать, что оптимизация позволила отказаться от покупки еще одного гига памяти, а как мы помним, по стоимости это зарплата специалиста по МФ за год )
Так что DB2 DBA очень эффективны )))

[zVlad]

.....
Не верю, что много народу сможет филигранно настроитьт все эти 50 пулов. Под какой-нить тест, еще верю что можно очень точно настроить размеры пулов и закрепить объекты за этими пулами. В реальной жизни в такую удачу не верю.
zVlad выше привелстатистику по своим15-16 пулам, там данные спрашивают, только из одного, остальные почти "спят".
Возможно (!) есть какие то архитектурные особенности DB2, которые исторически заставили сделать столько пулов. NUMA nodes какие-нибудь, отдельные writers процессы или еще что.

....

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

Вы не верно читали данные по нашим пулам. Во первых это realtime monitor и он показывает данные за интервал между нажатиями на Enter. Во вторых активность показывается в Getpage rate столбце. Там нуль только для одного пула просматривается, это за интервал в несколько секунд.

То что надо больше одного пула понимают и в Оракл, можете прочитать то что Вы мне предложили и там все есть по проблематике. Вот только имплентация Оракл эту проблему решает плохо. Почему, не знаю. Writes в DB2 делаются асинхронно, т.е. во время выполнения UPDATE не входят, при условии что установленный порог не превышен тогда синхронно.

[zVlad]

У нас несколько горячих таблиц/индексов имеют свои пулы такого размера как таблицы и часть из них даже зафиксированны в памяти.

Начнём с того, что горячие таблицы итак по LRU будут в памяти оставаться.
И мне не ясно, чем 10 пулов по 10ГБ по 1 таблице в каждом, лучшем чем 1 пул на 100ГБ для этих же 10 таблиц.

Для пулов где нет вытеснения лучше алгоритм FIFO потому что он менее ресурсоёмкий чем LRU.

Сколько сотых процентов CPU уходит на управление пулами?

т.

Если все таблицы в одном пуле то LRU не поможет и страницы горячих таблиц время от времени будет вытесняться.

Ничем не лучше если все 10 таблиц размером в 10 GB. У нас есть пул где несколько небольших таблиц и его размер равен сумме размеров этих таблиц.

Согласно статьи про пулы, которую я приводил, экономия до 10%.

[zVlad]

....

В Оракле ничего такого просто нет. Поэтому Оракл надо больше памяти чтобы достичь того же уровня производительности что у DB2 с меньшим объемом памяти. Теперь Вам понятно?

Имеющиеся паблик тесты этого факта не подверждают.

DB2 for zOS в тех паблик тестах не участвует. Участвует DB2 for LUW и насколько я знаю выглядит не хуже Оракл при сопоставимых мощностях серверов на которых делаются тесты. Те тесте вообще малосодержательны. Посколько платформы одинаковы то разница тестов в основном определяется разницей мощности серверов. Это и без тестов понятно и предсказуемо.

[zVlad]

Не верю, что много народу сможет филигранно настроитьт все эти 50 пулов. Под какой-нить тест, еще верю что можно очень точно настроить размеры пулов и закрепить объекты за этими пулами. В реальной жизни в такую удачу не верю.

Ну если 10 лет идет одна и та же нагрузка от атомной станции, то вполне можно 10 лет вылизывать конфигурацию
И показать, что оптимизация позволила отказаться от покупки еще одного гига памяти, а как мы помним, по стоимости это зарплата специалиста по МФ за год )
Так что DB2 DBA очень эффективны )))

Дима, не надо нагнетать. Гиг памяти на МФ стоит вполне разумные деньги.

[mskmel]

Если все таблицы в одном пуле то LRU не поможет и страницы горячих таблиц время от времени будет вытесняться.

Чем? Размер пула равен размеру таблиц.

Горячие блоки не вытеснятся, потому что LRU. В таком пуле держат таблицы\индексы, используемые редко, но по которым нужен быстрый ответ.

[zVlad]

Если все таблицы в одном пуле то LRU не поможет и страницы горячих таблиц время от времени будет вытесняться.

Чем? Размер пула равен размеру таблиц.

Горячие блоки не вытеснятся, потому что LRU. В таком пуле держат таблицы\индексы, используемые редко, но по которым нужен быстрый ответ.

Если размер пула равен размеру таблиц в нем то алгоритм LRU это пятое колесо в телеге, это корове седло. Поэтому в DB2 сохранен алгоритм FIFO, простой и не накладный. Но алгоритм FIFO имеет смысл только для тех пулов в которых ввода-вывода нет вообще или он незначителен.

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

[mskmel]

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

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

Вы натягиваете архитектуру и приёмы настройки ДБ2 на оракл, они разные внутри, 1к1 их сранивать неблагодарное занятие. Линка про настройку пулов ДБ2 это ощущение усилило, такой "закат солнца в ручную" в Оракле не делают. Не знаю где бы нашел время, чтобы ковырят статистику использования отдельных таблиц, размазывать их по кэшам, определять параметры... мне что заняться не чем?! Это напоминает времена каменного века, когда еще датафайлы по разным дискам раскладывали...

[zVlad]

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

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

Вы натягиваете архитектуру и приёмы настройки ДБ2 на оракл, они разные внутри, 1к1 их сранивать неблагодарное занятие. Линка про настройку пулов ДБ2 это ощущение усилило, такой "закат солнца в ручную" в Оракле не делают. Не знаю где бы нашел время, чтобы ковырят статистику использования отдельных таблиц, размазывать их по кэшам, определять параметры... мне что заняться не чем?! Это напоминает времена каменного века, когда еще датафайлы по разным дискам раскладывали...

"Бешенный" обычно значит table scan. Если таблица большая то она может заполонить, скажем так, небольшой кэш (или пул?) и вутеснить горячие страницы.

То что Oracle и DB2 разные это факт. Но непонимаем этой разницы вовсе не основания для оценок и фраз которые люди вашей специализации в ИТ очень любят "блистать".

Если для Вас в Орацле это составляет проблему получить статиску использования отдельных таблиц, то в DB2 нескольколькими кликами я получил вот такий список (несколько первых табличных пространств) таблиц у которых BP1 (это мгновенные значаении, не надоо на них сильно рефлексировать):

Code: Select all

           Pageset     Use    Open  VP Pgs            VP Pgs
           Type        Count  DS    Current           Changed
---------  ----------  -----  ----  -------           -------
TISQUVNM   TABLESPACE      0     1    10108                 0
TISPPCMW   TABLESPACE      0     1     5458                 0
TOSXB021   TABLESPACE      0     1     2837                 0
TOSXB255   TABLESPACE      0     1     2255                 0
TOSXB039   TABLESPACE      0     1     1700                 0
TOSXB360   TABLESPACE      0     1     1188              1127
TOSXB126   TABLESPACE      0     1      762                 0
TOSXB445   TABLESPACE      0     1      754                 0
TOSXB070   TABLESPACE      0     1      604                 0
TOSXB231   TABLESPACE      0     1      536                 0
TOSXB147   TABLESPACE      0     1      529                 0
TOSXB080   TABLESPACE      0     1      466                14
TOSXB396   TABLESPACE      0     1      336               155

[mskmel]

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

"Бешенный" обычно значит table scan. Если таблица большая то она может заполонить, скажем так, небольшой кэш (или пул?) и вутеснить горячие страницы.

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

Если для Вас в Орацле это составляет проблему получить статиску использования отдельных таблиц

Проблема не в получении статистики, а в мартышкином труде по сортировке простыней списков таблиц и их партиций по разным пулам каждый релиз нового приложения. А что делать если ночью одна нагрузка, а днём другая? А если в конце месяца одни таблицы активны, а в средине другие? Каждый раз их двигать туда-сюда напевая "I like to move it, move it" ?

[zVlad]

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

"Бешенный" обычно значит table scan. Если таблица большая то она может заполонить, скажем так, небольшой кэш (или пул?) и вутеснить горячие страницы.

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

Если для Вас в Орацле это составляет проблему получить статиску использования отдельных таблиц

Проблема не в получении статистики, а в мартышкином труде по сортировке простыней списков таблиц и их партиций по разным пулам каждый релиз нового приложения. А что делать если ночью одна нагрузка, а днём другая? А если в конце месяца одни таблицы активны, а в средине другие? Каждый раз их двигать туда-сюда напевая "I like to move it, move it" ?

Как то Вы с теорией небрежно обращаетесь. То говорите что страницы нужные для table scan не дойдут до кэша (а до куда они тогда дойдут?), то вдруг оказывается что могут и дойти, но ... "база только и делает что сканирует эту таблицу" - а это о чем?

Да, чего только не выдумаешь чтобы защищить любимый продукт от намерений очернить его. Напридумаешь с три короба всяких небылиц и пугалок для самого себя.
Я Вам еще раз говорю; выбросьте из головы что Оракл идеальная база данных. Не идеальная она, далеко не идеальная и отсутствие определенных (известных) механизмов управлениями данными в памяти делает ее прожорливой как свинья. Вам остается только кормить ее дешевыми ресурсами: памятью и корами. Вот и кормите, только не думайте и все остальные RDBMS такие же отсталые.

Кстати, для DB2 for zOS есть функция WLM которая позволяет динамически изменять размер буферных пулов подстраивая их под текущую нагрузку. А у Оракл что-нибудь такое есть?

[mskmel]

Как то Вы с теорией небрежно обращаетесь. То говорите что страницы нужные для table scan не дойдут до кэша (а до куда они тогда дойдут?), то вдруг оказывается что могут и дойти, но ... "база только и делает что сканирует эту таблицу" - а это о чем?

Вы сравниваете разные модели работы с данными и кэшем, отсюда некоторое недопонимание, переходящее в необоснованные наезды. ДБ2 видимо сначало кэширует ненужные данные, выбивает при этом горячие из пула, потом ДБА ищут как бы это побороть. Оракл же понимая, что сканирует большую таблицу\секцию - её в кэш складывать не будет, сразу отправит нужному процессу-потребителю.

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

A direct read is a physical I/O from a data file that bypasses the buffer cache and reads the data block directly into process-private memory.

Про то что это отключаемо и настраиваемо зря видимо сказал, еще больше вопросов получилось.

[mskmel]

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

Вот чего хамить то безосновательно? Ну не знаешь как работают другие продукты, чего помои то мимо лить?

[zVlad]

Как то Вы с теорией небрежно обращаетесь. То говорите что страницы нужные для table scan не дойдут до кэша (а до куда они тогда дойдут?), то вдруг оказывается что могут и дойти, но ... "база только и делает что сканирует эту таблицу" - а это о чем?

Вы сравниваете разные модели работы с данными и кэшем, отсюда некоторое недопонимание, переходящее в необоснованные наезды. ДБ2 видимо сначало кэширует ненужные данные, выбивает при этом горячие из пула, потом ДБА ищут как бы это побороть. Оракл же понимая, что сканирует большую таблицу\секцию - её в кэш складывать не будет, сразу отправит нужному процессу-потребителю.

.

В DB2, благодаря особенностям архитектуры ввода-вывода МФ есть такая возможность уже на уровне диска отфильтровать ненужные запросу страницы. Это делается на стадии I (Stage I) выполнения запроса, далее данные поступают на вторую стадии фильтрации (Stage II), это уже происходит в памяти, видимо в пуле, но вряд ли ненужные страницы "отбракованые" на второй стадии, они остаются в пуле (это хорошо бы уточнить). С соответствии с этими двумя стадиями различают предикаты Stage I и Stage II. Это очень важный момент для понимания как нужно писать запросы для DB2 чтобы дружить с производительностью.
Ни в Оракл ни в MS SQL ничего такого нет.
Вот ведь Вы опять нарываетесь на грубость. Ведь Вы сами корите меня будто бы я не зная продукта Оракл о нем сужу. И тут же сами начинаете делать то в чем меня упрекаете на голубом глазу. "ДБ2 кэширует не нужные данные", а Оракл "отправит нужному процессу-потребителю" без кэширования. Если этот процесс-потребитель на том же сервере то это значит фактически в той же памяти что и кэш Оракла. А если процесс-потребитель на другом сервере, то Оракл тем самым засрет сеть и память процесса. Поэтому Оракл документация говорит:

"Avoid requerying the same data by caching frequently accessed data in the client program or middle tier."

Т.e. переводит проблему с БД уровня на другой. С больной головы на еще более больную.

И вот еще что советуется consider:


"Consider poor hit ratios when large full table scans are occurring.

Database blocks accessed during a long full table scan are placed on the tail end of the Least Recently Used (LRU) list and not on the head of the list. Therefore, the blocks age out faster than blocks read when performing indexed lookups or small table scans"

Вообще чтение оракловской документации очень скучное дело. Говорится не много, но что имеется в виду помоему даже те кто писал плохо понимают. Одни только рассуждения о размерах блока чего стоит.

[zVlad]

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

Вот чего хамить то безосновательно? Ну не знаешь как работают другие продукты, чего помои то мимо лить?

Когда берешься кого-либо поучать надо быть уверенным что сам ты в таких поучениях не нуждаешься. Вы уверены что не делаете того от чего меня предостерегаете?

[Dmitry67]

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

Вот чего хамить то безосновательно? Ну не знаешь как работают другие продукты, чего помои то мимо лить?

Вы еще не привыкли? )))
Это его обычный стиль

[zVlad]

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

Вот чего хамить то безосновательно? Ну не знаешь как работают другие продукты, чего помои то мимо лить?

Вы еще не привыкли? )))
Это его обычный стиль

Я бы ввел правило, на форуме, наказывать подсерающих. В жизни это более менее понятно, а в анонимном общении нет.

[zVlad]

Вчера у меня был интересный день.
Сначала проект мэнеджер свел меня с представителем фирмы которая нам помогает установить и начать работать с приложением (identity managment) в которое я ввязался ( на старости лет) в качестве администратора WebSphere. Зовут его Mike и он наш, торонтовский.

Так вот, Mike, узнав что на самом деле мэйнфрэймщик сказал что сейчас многое банки возвращаются на МФ. Так он и сказал дословно, но на английском. Особенно он остановился на Sunlife, где как я понял он работал ранее, и рассказал что ранее Sunlife начал работу с веб на Wintel, а теперь работает над тем чтобы перенести веб на МФ. Вообще то Sunlife всегда была и остается с МФ (это мне уже сказал человек из ИБМ, плановая встреча с которыми состоялась тоже вчера и я спросил их о Sunlife). Я стал объяснять Mike-у о прелестях размещения DB2 и WebSphere не МФ, а еще лучше в одном и том же zOS. Это его заинтересовало.

Далее на встрече с ИБМ прозвучало что оказывается ИБМ делает нам саппорт по Оракл, я переспросил, да говорят делаем и добавили "мы все делаем". Уверен, Оракл если что-то и делает по ДБ2, то только убеждает что надо переходить с ДБ2 на Оракл, потому то и потому. Тоже конечно делает и ИБМ, но в данном случае это действительно саппорт Оракл.

Еще вчера меня поразили наши Оракл DBA. На проект этот назначен был не тот о котором я упоминал выше и который говорит на русском, наш он иными словами - из Москвы. Разговор с ними состоялся потому что проект мэнеджер притащил меня с Майком к ним. Те другие Оракл DBA, их два почему оказалось (может один босс другого, не знаю), явно включили дурочку. Во первых они не давали параметры Оракл для настройки JDBC, потом вроде дали имя сервера и базы данных, хотя я просил и порт и, согласно документации, Оракл System ID (SID) так написано в документации. По порту они сказали ну мол это обычный для Оракл порт. Я им говорю пришлите мне по e-mail номер обычного Оракл порта потому что я вечером буду конфигурировать JDBC data sources ( так и не прислали). Потом шлет мне PM e-mail мол дай знать тем оралам когда я начну грузить данные в Оракл они хотят мониторить этот процесс. Не вопрос отвечают. Потом ДВА шлет мне мыло со своим селл номером, мол позвони как начнешь, и в итоге сам приходит к моему столу и говорит что они решили что-то там переделать и как закончат мне позвонят, скажи мол свой селл номер. Я говорю пишите e-mail, я все равно буду работать вечером и увижу его. Он еще спросил, ты что будешь проверять мыло, да говорю потому что мне кроме JDBC есть еще что делать.
Хрен, ничего они мне не прислали и эти доделки все выдумка, какая и зачем я не понял, но сегодня разберусь.

Вот такой интересный день был вчера, ехать было лень остался до утра, как поется в песне.

[sp123]

Далее на встрече с ИБМ прозвучало что оказывается ИБМ делает нам саппорт по Оракл, я переспросил, да говорят делаем и добавили "мы все делаем". Уверен, Оракл если что-то и делает по ДБ2, то только убеждает что надо переходить с ДБ2 на Оракл, потому то и потому. Тоже конечно делает и ИБМ, но в данном случае это действительно саппорт Оракл.

Ничего необычного. У нас компания завязана на IBM, очень много чего крутится на DB2, но и на Oracle тоже что-то есть. Инфраструктурой, относящейся к релиз-процессам на Oracle, заведует IBM. Oracle DBA, правда, свои. Никаких разговоров о переходе с того на это или наоборот нет в принципе ни на каком уровне. Дискуссий что лучше/хуже тоже не наблюдается. Обе платформы мирно сидят в одной лодке, именуемой legacy, и обе медленно и верно идут ко дну.

А насчет коропоративных приколов вроде ваших смешных Oracle DBA могу привести совсем недавний, только в другую сторону. IBM ребята случайно похерили Oracle deployment box, относящийся к нашему проекту. Просто взяли и "decommission" его по простоте душевной. Ну бывает, что тут поделать, все люди ошибаются. Восстановление по-хорошему должно было занять полчаса, там всего-то и нужно было поставить Oracle client, создать пару директорий, раздать привилегии и открыть порт. Ну ладно, в условиях корпоративной бюрократии можно накинуть дня три на разговоры и согласования. Но почему-то вокруг этого несчастного бокса ребята ходили и тупили две недели. Две недели, Карл!

[Easbayguy]

Ничего необычного. У нас компания завязана на IBM, очень много чего крутится на DB2, но и на Oracle тоже что-то есть. Инфраструктурой, относящейся к релиз-процессам на Oracle, заведует IBM. Oracle DBA, правда, свои. Никаких разговоров о переходе с того на это или наоборот нет в принципе ни на каком уровне. Дискуссий что лучше/хуже тоже не наблюдается. Обе платформы мирно сидят в одной лодке, именуемой legacy, и обе медленно и верно идут ко дну.

А насчет коропоративных приколов вроде ваших смешных Oracle DBA могу привести совсем недавний, только в другую сторону. IBM ребята случайно похерили Oracle deployment box, относящийся к нашему проекту. Просто взяли и "decommission" его по простоте душевной. Ну бывает, что тут поделать, все люди ошибаются. Восстановление по-хорошему должно было занять полчаса, там всего-то и нужно было поставить Oracle client, создать пару директорий, раздать привилегии и открыть порт. Ну ладно, в условиях корпоративной бюрократии можно накинуть дня три на разговоры и согласования. Но почему-то вокруг этого несчастного бокса ребята ходили и тупили две недели. Две недели, Карл!

Что не выдержал?

[iDesperado]

все немного проще. процы МФ настолько слабые, что просто не вытягивают менеджмент больших buffer cache, при этом и zOS сильно отставала "Unfortunately, we have to wait for DB2 X to use the 1MB large page frames that are available with z/OS v1.9+ on z10 hardware"
http://performancetroubleshooting.com/i ... 2-for-zos/" onclick="window.open(this.href);return false;

вот и приходиться извращаться нарезкой и FIFO.

P.S. первые oracle DBA у Влада не могли настроить примитивный стендбай, эти уже не могут jdbc, чую к 80 годам Влад начнет рассказывать об oracle DBA не нашедших кнопку вкл. на корпусе.