Dmitry67 wrote:......
1. А как в DB2 c хранением XML в базе ? Не как длинный текст, а с индексацией XML полей ?
2. stored procedures, которые пишутся в DB2 представляют с точки зрения Microsoft, 'unmanaged' code ? то есть не котролируются утечки памяти, 'run aways' по ресурсам... Как построена конкуренция за память кода процедур и самого ядра DB2 (с кешем)
1. К сожалению приложение, для которого я DBA, не использует ничего кроме голых таблиц с индексами. Недавно стали использоваться триггеры. В своих приложениях (автоматизации задач DBA) я еще использую первичные и внешние ключи и другие мелочи. Поэтому сказать что-либо о XML, базирующеся на моем личном опыте и знаниях я не могу. Из статей и аннонсов у меня сложилось впечатление что у ИБМ в этом вопросе все в порядке и они едва ли не лидеры в стандарте xSQL или как это там называется. Спекулировать не буду.
2. Первый раз слышу о таких недостатках. У Вас есть примеры?
Такие проблемы как "утечка памяти", "не контролируемое использование ресурсов" были открыты, изучены и "сняты" на МФ ИБМ-ом годах так в 70х. На ЕС ЭВМ это еще проявлялось в 80х, то есть до того как появился Мicrosoft (не в обиду будет сказано). Не думаю что на других платформах ИБМ забыл про этот опыт.
Мне кажется ни один DB2 DBA не сможет рассказать как работает механизм конкуренции за память в DB2 по той простой причине что они никогда не испытывают проблем с этим. А раз так - зачем это знать. Правильно?
Я пропустил несколько дискуссий на эту тему, просто потому что мне было ничего не известно о подобных проблемах в ДБ2. Если я не прав прошу других ДБ2-шников меня поправить.
А вообще, уже давно мне не приходится разрешать проблем ДБ2 как такового. За последние 4 года это было всего может быть два раза и каждый раз оказывалось что ИБМ уже имеет решение - просто мы были не в курсе.
Главной моей проблемой, как DB2 DBA, на сегодня являются люди окружающие DB2. В двух словах: за последние месяцы я обнаружил больше чем два десятка мест в приложении работающих не эффективно и предложил меры по исправлению, практически без изменения кода. И не могу "продавить" это через людей, кто принимает решение о внедрении. Большинство предложений протестированно, доказана их эффективность, каким то чудом два-три были внедренны, были восторги СOOL!!!, но вот с основными предложениями - вилы. Людской фактор.
Другая проблема - это приложения написаные либо для Оракл, либо для Windows и желающие соединяться с нашей базой на DB2. Это тоже ночной кошмар. Решения на уровне 2-ого класса, никакого понятия о реальных нагрузках и проблемах. Розовые очки, и удивленные глаза.
Наверное месяц объяснять пришлось, что когда ресурс занят, то запрос ставится в очередь, а когда ожидание в очереди превышает определенное время, то запрос терминируется и его просто нужно повторить. Нет говорят там у вас в ДБ2 что-то не так. Да я согласен, что что-то не так, но не в ДБ2, а опять же в том как приложение для этого ДБ2 написано. Но в свою очередь попробуйте докажите что-нибудь тем кто пишет это приложение.
Другой пример. Создатели приложения используют кодировку представленную кодовой страницей 1034, а говорят в документации что у них страница номер 37. Никакие доказательства (официальные документы) так и не были признаны. А проблема "всплыла" когда приложение из-под Windows начало соединяться и брать информацию из ДБ2. Поскольку мы, на основании документации приложения, установили номер 37 в ДБ2, а на самом деле несколько символов кодировались иначе, то и получился "сыр-бор". И так почти всегда. Люди - это самая большая проблема в моей практике.
