Задача перехвата DML-запросов и как она решается разными DB

[zVlad]

Да, людской фактор в большиз фирмах вещь еще та
Что касается памяти то я вот что имел ввиду конкретно
Пусть stored procedure делает ref=malloc(1024*1024*1024), то есть аллокирует доЯя чего то один гиг памяти. Откуда он возьмется ?

Для примера допустим что у вас всего полтора гига. Естественно база, точнее ее кеш занимает почти всю оперативку. В случае managed code SQL server поймет что ситуация конфликтная и будет пытаться поджаться, это лучше чем page faults от него и stored procedures. Как жто построено в IBM ?

Это видимо будет зависить от платформы. На МФ такими вопросами ведает не сервер базы данных (хранимые процедуры вообще не в адресном пространстве сервера БД выполняются), а ОС. Считается нормальным что на МФ одновременно выполняются много серверов, сервисов, приложений, пакетов и т.д.. Если бы было возможным, что один жадный процесс захватил память, то работать вообще было бы не возможно.
В системе VM, например, еще в 80-е существовало такое понятие как рабочий набор - количество реальной памяти, которое может окупировать отдельная ВМ, если она окупирует больше, то система начинает "свапать" ее же страницы.

А что в случае MS SQL хранимые процедуры выполняются в том же адрессном пространстве (или как там это называется) что и сам сервер? Это должно быть не безопасно.

[Dmitry67]

zVlad, обычные stored procedures написанные на TSQL выполняются в адресном пространстве сервера, но это не C, а TSQL, то есть только сервер их и может выполнять.

Тем не менее Ваше беспокойство совершенно справедливо, новая технология CLR предполагает исполнение кода написанного пользователем как stored procedure. Правда код жто является managed, то есть safe, так как все операции проверяются системой .Net, но тем не менее. Юконовцы убеждали меня что все безопастно, но полностью до конца я не поверил

Я понял что sp в DB2 выполняются в другом адресном пространстве; если отведение памяти в них работает на общих основаниях то если процедура будет неожиданно много отводать памяти начнутся page faults, который можно было бы избежать если SQL server 'aware' относительно выделений памяти. Так построено в Yukon.

Другое дело что выделение больших объемов памяти наверное редкая задача

[dzher]

А как в ДБ2 ц хранением ХМЛ в базе ? Не как длинный текст, а с индексацией ХМЛ полей ?

ХМЛ ехтендер

сторед процедурес, которые пишутся в ДБ2 представляют с точки зрения Мицрософт, ьунманагедь цоде ?

Дмитрий, Мицрософт здесь несколько слукавила - партия (ИБМ) рекомендует ДБ2 СП писАть на Ява - что таки является [managed code] (Java/JVM vs .C#/NET)

[oMoses]

Наоборот, oMoses своими рассуждениями в этом топике добавил повод лишний раз убедиться что DB2 в этом разрезе ни чем не уступает Ораклу и более того ощутить преимущество DB2, хотя бы в вопросе возможности доступа к записям журнала транзакций. Никаких ограничений и неудобств в этом у DB2 нет. Читать можно не только архивный журнал, но и активный никак не влияя на работу самого DB2. На этом как раз, как правило, базируются средства репликаций. Хотя для последнего имеются и другие возможности, как то DataCapture, который перехватывает все DML и пишит в специальные для этого созданные таблицы DB2 всю необходимую для воспроизведения изменений информацию.

Влад, привет! Знаете, вот если в этом Вашем пассаже заменить DB2 на Oracle, а Oracle - на DB2, то справедливость этих высказываний - не изменится. Это сродне тому, как кто-то в наполненом наполовину стакане склонен видеть наполовину полный стакан, а кто-то - наполовину пустой. Нюансы начинают проявляться лишь при непосредственной и продолжительной работе по решению конкретных задач. Думаю, что как в Oracle, как и в DB2 (не говоря уж и про MS SQL) достаточно мест, сделанных через ж....

[zVlad]

.........

Влад, привет! Знаете, вот если в этом Вашем пассаже заменить DB2 на Oracle, а Oracle - на DB2, то справедливость этих высказываний - не изменится. Это сродне тому, как кто-то в наполненом наполовину стакане склонен видеть наполовину полный стакан, а кто-то - наполовину пустой. Нюансы начинают проявляться лишь при непосредственной и продолжительной работе по решению конкретных задач. Думаю, что как в Oracle, как и в DB2 (не говоря уж и про MS SQL) достаточно мест, сделанных через ж....

Если это так, то что же означает это:

.....Logminer, кажется, наиболее подходящим для решения поставленной задачи, поскольку позволяет читать и анализировать абсолютно все запросы сделанные к базе через архивные логи, генерируемые последней. Однако, и эта технология не лишена своих ограничений и неудобств. Во-первых, база должна быть в archivelog mode. Более того, этот режим должен быть включенным c опцией Force, дабы гарантированно защититься от direct-INSERTs (SQL*Loader, DIRECT=Y)......"

В чем неудобство нахождения Оракле в archivelog mode? Значит ли это что обычно Оракл не архивирует журнал? Что ж тогда происходит, когда активный журанл заполняется?

[zVlad]

.........
Я понял что sp в DB2 выполняются в другом адресном пространстве; если отведение памяти в них работает на общих основаниях то если процедура будет неожиданно много отводать памяти начнутся page faults, который можно было бы избежать если SQL server 'aware' относительно выделений памяти. Так построено в Yukon.

Другое дело что выделение больших объемов памяти наверное редкая задача

Управление памятью завсегда считалось функцией операционной системы. И это почти закон. Что, Microsoft открыл новый закон и теперь это функция сервера баз данных? Или все таки ОС тоже ведает памятью?
Видимо, в случае с Yukon, ОС ведает памятью Yukon-а, в то время как последний дублирует эту функцию для выполняющихся в его рамках хранимых процедур. Я не прав?

В ДБ2 на МФ хр. процедура выполняется в отдельном адресном пространстве, каждая в своем. Выделение им ресурсов - задача ОС.
Таким образом, хр. процедура есть ничто иное как приложение, запускаемое в той же системе, где находится сервер. И отличие хр. процедур от классических приложений лишь в том, что хр. процедуры определенным образом готовятся, инициируются через оператор SQL СALL, и выполняются как за пределами вызвавшего ХП-дуру приложения так за пределами сервера баз данных.
Все механизмы аутентификации и авторизации остаются теми же что и для приложений запущенных любым другим способом.
Следовательно, хр. процедура может быть написана на каком угодно языке (хоть на русском матершинном) это никоим образом не уменьшит как безопасности сервера баз данных, так и контролируемости использования ресурсов. Что и наблюдается на практике.
В ДБ2 для Unix, Window имелись понятия "fenced SP" и "not-fenced SP", последние выполняются в том же адрессном пространстве что и сервер баз данных. Но эта информация у меня очень устаревшая, как там сейчас дела с этим обстоят не знаю

Интересно, а как с этой точки зрения выглядят ХП-дуры в Оракл?

[Lazy44]

Управление памятью завсегда считалось функцией операционной системы. И это почти закон. Что, Microsoft открыл новый закон и теперь это функция сервера баз данных?

Позвольте с вами не согласится. Оракл дает полную свободу или не-свободу по управлению ресурсами вне зависимости от ограничений на уровне ОС. Я не берусь судить об управлении памятью под зОС, но при работе ХП написанных на SQL PL под UDB 7.1 under AIX у меня были проблемы при аллокировании больших кусков памяти под массивы. При этом памяти было больше чем достаточно в разы. Было такое чувство, что база хватает первый кусок памяти из heap и не смотрит на его размер. Проблема была не повторяемая. Видать, эту проблему для SQL PL в ИБМ еще не решили. В оракле можно динамически менять размеры почти всех пулов, и , боюсь соврать, но тут поправят, по моему можно отдать все на откуп базе для ленивых

[zVlad]

Управление памятью завсегда считалось функцией операционной системы. И это почти закон. Что, Microsoft открыл новый закон и теперь это функция сервера баз данных?

1. Позвольте с вами не согласится. Оракл дает полную свободу или не-свободу по управлению ресурсами вне зависимости от ограничений на уровне ОС.
2. Я не берусь судить об управлении памятью под зОС, но при работе ХП написанных на SQL PL под UDB 7.1 under AIX у меня были проблемы при аллокировании больших кусков памяти под массивы. При этом памяти было больше чем достаточно в разы. Было такое чувство, что база хватает первый кусок памяти из heap и не смотрит на его размер. Проблема была не повторяемая. Видать, эту проблему для SQL PL в ИБМ еще не решили.
3. В оракле можно динамически менять размеры почти всех пулов, и , боюсь соврать, но тут поправят, по моему можно отдать все на откуп базе для ленивых

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

2. Если можно приведите больше деталей. Какой вид процедуры, каким образом происходит распределение памяти, какое сообщение (код) получает процедура. Догабываюсь, что Вы работаете на уровне написания прикладных программ и Вам просто нужна помощь DBA в этом вопросе. Сама UDB здесь скорее всего не причем - у ИБМ достаточно было времени и опыта, чтобы увидеть и устранить проблему, которую Вы полагаете UDB имеет. Я имею в виду: "...Было такое чувство, что база хватает первый кусок памяти из heap и не смотрит на его размер." Ну не может этого быть.

3. Руководство DBA для UDB содержит множество параметров которые можно менять, имеются также автоматически настраиваемые параметры. Чтобы что-то утверждать в этой части конкретно нужно перелопатить очень много информации, или иметь одинаково интенсивную практику в обеих системах. Боюсь не Вы ни я не отвечаем ни тому ни другому требованию.

[Dmitry67]

zVlad, Вы все время говорите о том как классно что сама ОС ведает памятью и для sp, и для сервера. Однако это очень неоптимальное решение c точки зрения performance. Потмоу что возникает авто(само)конкуренция за ресурс

Пример. У меня есть таблица 1G. памяти на сервере 1G. База берет 1G для кеша (само ядро маленькое и его не считаем). Есть sp которая делает очень сложную обработку и для этого временно аллокирует 512M.

Последовательность действий: table scan, вызов процедуры, table scan.
Разбираем по шагам. 1 table scan - при люой архитиектуре чиатется таблица последовательным чтением и помещается в кеш. Я обозначу это так: seqread(1024);

Далее вызывается sp; она делает malloc(512*1024) и чтото то там делает. ОС вынуждена вытолкнуть половину кеша сервера в виде страниц, то есть pagewrite(512).

Далее снова делаем table scan. Сервер думает что вся таблица у него в кеше. На самом деле при обращении к половине страниц кеша произойдет page faults: randomread(512). Вот здесь мы сильно попадаем потому что чтение идет не большими кусками а по страничке и возможно вразнобой

Итого: seqread(1024) + pagewrite(512) + randomread(512)

Теперь ситуация если server 'aware' отнсоительно sp. В момент malloc он поджимается, сознательно разрушая половину кеша и отдает память процедуре. Никакого IO не происходит

Далее, при table scan ему надо будет взять половину из кеша а половину снова прочитать с диска. Итого seqread(512)

Получили seqread(1024) + seqread(512) - значительно меньше !

Я сильно упростил, однако принцип именно такой

[verzlo]

Расскажу, как это может быть сделано средствами Oracle9i. Возможны несколько путей, как-то:
- auditing
- triggers
- streams
- CDC
- tracing
- logminer

Вы пропустили logical standby - по моему он должен удовлетворить условиям задачи...

[oMoses]

Вы пропустили logical standby - по моему он должен удовлетворить условиям задачи...

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

[zVlad]

zVlad, Вы все время говорите о том как классно что сама ОС ведает памятью и для sp, и для сервера. Однако это очень неоптимальное решение c точки зрения performance. Потмоу что возникает авто(само)конкуренция за ресурс

.....

Scenario, you are describing, is a very common and unavoidable problem when you have limits. And solutions could be:

1. If you want to guaranty that, at any time, responce times for either table scan, or SP runs must be the same regardless SP ran or not, then you have to either increase memory on your computer, or reduce cash for tables.

2. If you can afford to have different responce time you mignt not need to do anything and relay on OS paging mechanism. This scenario is more common, just because you would never know all requirments. By the way, it could happen for other than SP memory requests. What should happen here? Looks like MS SQL will now not be aware about it?

In MF world, we initially calculate all memory requirments, and perform step called capacity planning. Then we monitor how system works, do we have any paging? If "Yes" we either add more memory or reduce space used for different pools (cashes).
Also, I susspect that scenario, you gave at the end of your last message, is not applicable to describe how DB2 and zOS would work together. I don't have enough to say for sure, but most likelly they will work like DB2 is "aware" about its pages are stolen, and zOS will not write data pages to the page data sets if those pages were not cnahged. I'll try to find more about it, it seems interesting to know.

[Dmitry67]

zVlad, я только что рассказал как это решает MS
Поэтому слово unavoidable я с Вашего позволения отнесу к DB2

[zVlad]

zVlad, я только что рассказал как это решает MS
Поэтому слово unavoidable я с Вашего позволения отнесу к DB2

Don't be hurry. First, explain what happen if pages will be stolen from memory by some other than MS SQL processes running on the same system?

I've found that in case of DB2 and zOS there is no co-operations. If zOS decides to stole page allocated for DB2 it will do it without having to let DB2 know about it.

Of course, DB2 will control all memory requests caming from within its own address space. But, SP for DB2 on zOS never executed in DB2 memory.

[Dmitry67]

Объясняю
Да, SQL server страдает от page faults если другой процесс будет отбирать память
Если другой процесс или другие процессы расходуют примерно постоянное количество памяти то можно все рассчитать и ограничить SQL server по памяти
Если он сконфигурирован с выделением памяти по умлочанию то он сам попытается это сделать. Однако только задним числом, и, если процесс периодический (набухает и сдувается) то ничего хорошего из этого не выйдет
Именно поэтому Microsoft рекомендует для SQL server выделенный сервер для production, и не ставить более одной инстанции на сервер

Однако с sp другая вещь. Вы можете разнести аппликации на другие сервера... но не sp... без узерба производительности. Поэтому в отношении памяти sp сервер ДОЛЖЕН быть aware и не должен полагаться на os