курсоры... и вообще MS SQL vs Oracle

[egorych]

********* Выделено отсюда Регламентные процедуры. Кто использует и какие? ********

Цитата:

Сообщение от mazzy

Читайте what's news

Я имел ввиду не функционал, а техническую сторону! Вернее что касаемо общения СУБД.
В этом плане полный абзац...

Цитата:

Сообщение от mazzy

Работа через курсоры не изменится. И не только для MS SQL.

С Ораклом работает не через курсоры, а "человечьим" языком SQL! И даже (о боже!!!) без участия ODBC!

[mazzy]

Цитата:

Сообщение от egorych

С Ораклом работает не через курсоры, а "человечьим" языком SQL! И даже (о боже!!!) без участия ODBC!

А курсоры - не на SQL?
OCI: да... это не ODBC

[egorych]

Цитата:

Сообщение от mazzy

А курсоры - не на SQL?
OCI: да... это не ODBC

1. Нет. На сервер уходит обычный "текстовый" SQL запрос, а не дебильная конструкция вида sp_createcursor(...), sp_fetchcursor ну и т.д.
2. Да, это не ODBC - это стандартный Oracle Client API, самый низкоуровневый (а значит с меньшими накладными расходами) метод доступа. Кстати MS тоже такое имеет, и причем начиная с 2005 работает по своему протоколу, ну очень шустрому! ТОлько вот использовать его видимо религия не позволяет!

[mazzy]

Цитата:

Сообщение от egorych

1. Нет. На сервер уходит обычный "текстовый" SQL запрос, а не дебильная конструкция вида sp_createcursor(...), sp_fetchcursor ну и т.д.

И оракл компилит каждый раз этот текстовый запрос, бедняжка...
Может стоит почитать почему сделано так "дебильно"? Про кэширование, про оптимизацию и прочий дебилизм...

Цитата:

Сообщение от egorych

2. Да, это не ODBC - это стандартный Oracle Client API, самый низкоуровневый (а значит с меньшими накладными расходами) метод доступа. Кстати MS тоже такое имеет, и причем начиная с 2005 работает по своему протоколу, ну очень шустрому! ТОлько вот использовать его видимо религия не позволяет!

[egorych]

Цитата:

Сообщение от mazzy

И оракл компилит каждый раз этот текстовый запрос, бедняжка...
Может стоит почитать почему сделано так "дебильно"? Про кэширование, про оптимизацию и прочий дебилизм...

С какого перепуга он компилить будет? Вполне нормально используется кэш запросов и планов!
Покажите, где почитать, может просветление на меня сойдет ;-) Только вряд-ли там будет написано - "дети, используйте курсоры на сервере и будет вам щасте"
Попробуйте на любом форуме по MSSQL показать трассировку запросов и послушайте, что вам скажут на счет разработчиков.

[mazzy]

Цитата:

Сообщение от egorych

С какого перепуга он компилить будет? Вполне нормально используется кэш запросов и планов!
Покажите, где почитать, может просветление на меня сойдет ;-)

начните отсюда http://axapta.mazzy.ru/lib/literals_vs_placeholders/
далее http://msdn.microsoft.com/en-us/libr...8VS.85%29.aspx
далее везде http://social.msdn.microsoft.com/Sea...execution&ac=8

Цитата:

Сообщение от egorych

Попробуйте на любом форуме по MSSQL показать трассировку запросов и послушайте, что вам скажут на счет разработчиков.

здесь? http://sql.ru/forum/actualthread.asp...d=650982&pg=10
вы случайно не Volochkova?

[egorych]

Цитата:

Сообщение от mazzy

начните отсюда...

Не вижу связи с Prepared execution. Все это прекрасно работает и без использования серверных курсоров, через то-же ADO

Цитата:

Сообщение от mazzy

здесь? http://sql.ru/forum/actualthread.asp...d=650982&pg=10
вы случайно не Volochkova?

Не, это не я!

Цитата:

Сообщение от ena_ax

Я спрашивал скорее про администрирование, а не про разработку.

Настройте ночной reindex - в инете полно примеров скриптов.

[fed]

Цитата:

Сообщение от egorych

Я имел ввиду не функционал, а техническую сторону! Вернее что касаемо общения СУБД.
В этом плане полный абзац...

С Ораклом работает не через курсоры, а "человечьим" языком SQL! И даже (о боже!!!) без участия ODBC!

Во первых, хочу заметить, что в DAX2009 работает не через ODBC.
Во вторых - далеко не всегда ODBC означает медленный доступ. Просто во первых часть СУБД (не буду пальцем показывать на чужие логотипы группы ) была разработана задолго до появления стандарта ODBC, соответственно реализация ODBC-драйвера содержит очень заметный накладняк и соответственно тормоза. Во вторых - часть "СУБД" (типа dBase или Acess), хотя и имеет ODBC-драйвера, плохо укладывается в SQLную идеологию и драйвера там неприлично тормозят по сравнению с прямым (ISAM) доступом.
А в SQL Server ODBC-драйвер конечно не идеальный и от перехода на Native Client в версии 2009 Аксапта выиграла, но выигрыш был не очень существенным. То есть - если с секундомером замерять - то явно выше погрешности измерения, но с другой стороны - не настолько большой чтобы пользователям в глаза бросаться.

[egorych]

Цитата:

Сообщение от fed

Во первых...

Тут возможно меня неправильно понимают в некоторых вопросах!!!
Попытаюсь объяснить свою позицию. Я отнюдь не против MSSQL, тем более я с ним довно-давно работаю (и сейчас тоже). Мне он очень нравится! С Ораклом я относительно недавно - год где-то. Поэтому я могу сравнить как они работают применительно к Аксапте.
Извините, но я опять повторю - работа с MS через курсор есть АФИГЕННОЕ ЗЛО! Т.е. я считаю, что то, как разработчики работают ( ;-) ) с MS в ядре - есть в корне неверно, что ведет к большим накладным расходам и т.д. и т.п. причем режим snapshot в корне эту ситуацию не спасает!
Один пример - у нас стоит для БД 4 проц. сервер, ну в общем весьма неплохой. На MS была загрузка ~50-60 % - уже думали менять. После перехода на Оракл нагрузка стала 25-40% (средняя есс-но)! Это о чем-то говорит? ИМХО очень красноречиво!
Посему я считаю, что для Аксапты лучший выбор - Оракл! Решаются многие проблемы и производительности и другие.
Причем, поскольку Аксапта не использует ни в MS ни в Оракл хранимки, триггеры и т.д. то администрирование Оракла сводится почти к нулю! Често! И глюки, (коих много, судя по форумам) ну никак не влияют на работу! Имеется ввиду версия 10G R2 и выше есс-но, с 9 придется шаманить что-то но не много!
В общем как-то вот так в кратце!

[fed]

Цитата:

Сообщение от egorych

Только вряд-ли там будет написано - "дети, используйте курсоры на сервере и будет вам щасте"
Попробуйте на любом форуме по MSSQL показать трассировку запросов и послушайте, что вам скажут на счет разработчиков.

Когда-то давно, когда я только начинал Аксаптой заниматься, SQLные админы фыркали, мол "Эта ваша аксапта курсорами пользуется". У меня, надо сказать, это фырканье вызывало некоторое недоумение и вот почему: Моим первым SQL-базой данных был Informix, после этого я с Oracle работал и достаточно мало с MS SQL. А в Informix, курсор был просто некой внутренней переменной (на самом деле структурой сишной), которая в прикладной программе использовалась для доступа к результатам выборки. Ну то есть - кроме как через курсор до результатов выборки никак не добраться. При этом где-то в документации говорилось, что мол скорее всего под курсор будет создана временная таблица на сервере, но если запрос простенький (типа select * from table where indexField=константа) или курсор не навигационный (fast forward), то сервер постарается временную таблицу не создавать. И я сначала просто не понимал о чем эти сиквельные админы говорят. Потом выяснилось что в MS SQL есть, грубо говоря, два метода доступа к данным. В первом из них (без использования курсоров) на сервер просто отправляется запрос, и потом клиент должен прочитать выборку сверху-вниз (естественно можно прервать процесс и не читать выборку до конца). Во втором из них (как раз с курсорами) - сервер создает временную таблицу, в которую результаты запроса и складываются. В этом случае - возможно применение навигационных операций к результатам запроса, ценой большей нагрузки на сервер.
Тут надо сделать некоторую интерлюдию, заметив что во времена проталкивания на рынок клиент-серверной архитектуры, отцы-основатели рассказывали что в светлом комму^H^H^H^H^H клиент-серверном будущем, с системой будут работать исключительно сферические пользователи в вакууме, которые перед каждым открытием, ну например, формы номенклатурного справочника, будут весело и радостно указывать номенклатурную группу, фильтр по коду и названию номенклатуры, в общем прилагать все усилия для того чтобы выборка не превышала пары экранов. А любые предположения о том чтобы побровситься по таблице будут вызывать у этих пользователей гневное отторжение, и они будут устраивать демонстрации у местного представительства провинившегося вендора, крича "Курсоры - геть !" и размахивая транспарантами с надписью "FORWARD_ONLY".
Естественно, при столкновении с реальной жизнью всем вендорам пришлось рано или поздно обзавестись навигационным доступом (у оракла он, кстати, только в версии 9 появился). Естественно - у всех СУБД навигационный доступ обходиться дороже чем ненавигационный, но иначе пользователей не удовлетворить.
В принципе, я могу согласиться с тем, что для небольших таблиц (скажем - настроек профилей разноски) можно было бы не использовать курсоры, а просто вытаскивать таблицы в кэш напрямую. Но поскольку таблицы эти и так небольшие, большого накладяка от курсорного доступа к ним нету. В общем - могу предположить, что в будущих версиях аксапты, для таблиц с fullTable cache сделают выборку без курсора (поскольку курсор там и вправду смысла не имеет). С другой стороны - есть сильнейшее подозрение что заметного выигрыша это не даст...

Теперь немножко о том, что было бы если бы аксапта ПОЛНОСТЬЮ отказалась бы от использования курсоров. Я когда-то занимался развертыванием версий 2.5 и 3.0 на Оракле. Поскольку и та и другая версия должны были поддерживать Оракл 8ой версии, scrollable курсоры, появившиеся в версии 9i в них не использовались (Кстати - не знаю, используются ли они в более поздних версиях Аксапты, сам на оракле не внедрял, а спросить не у кого ). Последствия применения чистого ненавигационного доступа в этих версиях аксапты на оракле можно было простейшим экспериментом. Надо было открыть какую-нить достаточно большую таблицу (ну скажем inventTable), нажать на кнопку PgDn и подержать достаточно долго, чтобы система отлистала страничек 30-40. Далее надо было нажать кнопочку PgUp и попытаться отскроллиться назад на начало таблицы. При этом возникал любопытный эффект: Странички на 3-4-5 назад можно было отскроллиться быстро, после чего система впадала в спячку секунд на 10, снова быстро скроллила 3-4-5 страничек назад и тд. Происходило при этом следующее: Система доставала из буфера несколько страничек, потом буфер кончался. Ну а поскольку оракл в те времена не поддерживал навигационного доступа, аксапта просто переоткрывала запрос с ноля и фетчила те 25 страниц, которые отделяли ее от нужной записи таблицы. Хотя, конечно, пользователи на этот эффект натыкались не очень часто, но время от времени, случались жалобы на тему того что система вдруг заткнулась на 10-15 секунд.
Ну и наконец - где-то в документации Оракла, английским по белому сказано что при использовании scrollable cursor, сервер БД сохраняет результаты выборки в области памяти, а если выборка большая, то во временной таблице. Что в общем, мало отличается от поведения серверных курсоров SQL Server.

Так что избавиться от курсоров, на самом деле, можно но только
1. Для случая маленьких таблиц и нормальных пользователей.
2. Для случая любых таблиц и сферических пользователей в вакууме.

P.S. Просьба модераторам дискуссию по поводу курсоров и вообще MS SQL vs Oracle вынести в новый топик.

[fed]

Цитата:

Сообщение от egorych

Тут возможно меня неправильно понимают в некоторых вопросах!!!
Попытаюсь объяснить свою позицию. Я отнюдь не против MSSQL, тем более я с ним довно-давно работаю (и сейчас тоже). Мне он очень нравится! С Ораклом я относительно недавно - год где-то. Поэтому я могу сравнить как они работают применительно к Аксапте.
Извините, но я опять повторю - работа с MS через курсор есть АФИГЕННОЕ ЗЛО!

Я, кстати, тоже не дикий фанат MS SQL. И если бы речь шла о заказной разработке (типа писать что-нить на Яве/C# с ноля) я бы скорее Oracle выбрал чем MS SQL. Просто я во первых не люблю наскоков на курсоры. Не верю я, что можно сколько-нить дружелюбную к пользователю систему построить без навигационного доступа. Во вторых - я считаю что где-то начиная с MS SQL 2005 сиквел догнал оракла в плане применимости для Аксапты. Ну то есть - средства программирования (которые в оракле до сих пор мощнее), Аксапта все равно не использует, а в остальных случаях - разница небольшая. Да я помню про всякие оракловские навороты типа хэш-кластеров или bitmap-индексов. Но только выигрыш от этих сложных структур бывает где-то в паре процентов случаев, при этом нет гарантии что эти сложные структуры не погибнут при следующей синхронизации Ну а с учетом перехода на reporting services, поддержки MS OLAP и тп, особого смысла заморачиваться на оракл для аксапты я как раз не вижу...

[ZVV]

Цитата:

Сообщение от fed

(Кстати - не знаю, используются ли они в более поздних версиях Аксапты, сам на оракле не внедрял, а спросить не у кого ).

пока не используются, насколько я знаю...

[ZVV]

Цитата:

Сообщение от fed

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

Axapta 3.0 и Oracle 11 - кто-нить пробовал ?

[egorych]

Еще одна неприятная особенность курсоров в MS заключается в его архитектуре, как блокировочника. Т.е. если вы посылаете на сервер обычный запрос, то после прочтения результатов блокировки исчезают. Если-же вы открываете курсор, то блокировки работаю несколько иначе и задерживаются надолго! В большинстве случаев это самое поведение и вызывает гнев админов на курсоры, в том числе и мой ;-) Не проходило и дня без того, чтобы кого-то "зарубить", а то и АОС перестартовать. А разноска журналов прибытия вообще вызывала приступы бешенства.
Возможно в 4 и 5 как-то это все разрулили, но пока мы 5 сильно не терзали. Если так, то слава аксапте!
Насчет накладных расходов - ну все-таки разница в нагрузке на проц. в 30-40 % между MS и Ораклом думаю говорит не в пользу курсоров ;-)

[kashperuk]

После введения ОСС как-то блокировок и не заметно почти.. Так что переходите на след. версию.

[egorych]

Цитата:

Сообщение от kashperuk

Так что переходите на след. версию.

Хороший совет!

[fed]

Цитата:

Сообщение от egorych

Еще одна неприятная особенность курсоров в MS заключается в его архитектуре, как блокировочника. Т.е. если вы посылаете на сервер обычный запрос, то после прочтения результатов блокировки исчезают. Если-же вы открываете курсор, то блокировки работаю несколько иначе и задерживаются надолго!

Блокировки при использовании навигационного доступа вызваны не зловредностью системы, а тем что пользователи, в большинстве случаев, обижаются, когда они попросили у сервера выборку, побегали по ней, а в момент попытки редактирования система им выдала сообщение о том что сосед эту запись удалил. Кстати - в SQL 2005 появилась поддержка режима Read Commited Snapshot Isolation, который как раз позволяет отключить блокировку при чтении. Хотя и ценой недовольства пользователей, у которых из под носа удалили запись.
Насколько я понимаю, у вас на проекте была такая ситуация: Была высокая утилизация процессоров сервера БД. Вы сделали предположение что все это вызвано использованием курсоров. В принципе, предположение имеет право на существование. Курсоры и правду дополнительную нагрузку создают (правда, обычно, терпимую). Я, кстати, недавно сам видел как при попытке запуска WMS, смешное количество пользователей создает удивительно большую нагрузку на процессор сервера БД. Возможно - WMS и вправду, скажем, создает множество мелких запросов, что в сочетании с курсорами приводит к непропорциональной нагрузке на процессор сервера БД. Вы заменили MS SQL на Oracle. Нагрузка упала. Был сделан вывод что это из за отсутствия курсоров.
НО: Во первых это только теория. Возможно MS SQL работал медленнее из за каких-то других факторов, которые теперь, пост фактум уже не идентифицировать.
Во вторых - даже если в вашем конкретном случае выигрыш был достигнут из за отказа от использования курсоров, не факт что такой же выигрыш будет достигнут в других случаях, на других версиях Аксапты и другом наборе модулей.
В третьих - курсоры не абсолютное зло. Это просто способ предоставить пользователю больше удобств, ценой дополнительной нагрузки на сервер.
Короче говоря - не надо на курсоры в Аксапте ругаться. Они там не от дурости или ленности разработчиков используются, а просто потому что любые альтернативы с точки зрения пользователей могут еще неудобнее оказаться.

[gl00mie]

Цитата:

Сообщение от egorych

это стандартный Oracle Client API, самый низкоуровневый (а значит с меньшими накладными расходами) метод доступа. Кстати MS тоже такое имеет, и причем начиная с 2005 работает по своему протоколу, ну очень шустрому! ТОлько вот использовать его видимо религия не позволяет!

Уж не знаю, кому там религия не позволяет. Давно уже была тема про подключение к MS SQL 2005 и выше с помощью SQL Native Client.

Цитата:

Сообщение от fed

А в SQL Server ODBC-драйвер конечно не идеальный и от перехода на Native Client в версии 2009 Аксапта выиграла

От перехода на использование по умолчанию SQL Native Client. Никто не мешал руками настроить его использование что в 3-ке, что в 4-ке.

Цитата:

Сообщение от egorych

Я отнюдь не против MSSQL, тем более я с ним довно-давно работаю (и сейчас тоже). Мне он очень нравится! С Ораклом я относительно недавно - год где-то. Поэтому я могу сравнить как они работают применительно к Аксапте.
я считаю, что для Аксапты лучший выбор - Оракл! Решаются многие проблемы и производительности и другие. Причем, поскольку Аксапта не использует ни в MS ни в Оракл хранимки, триггеры и т.д. то администрирование Оракла сводится почти к нулю! Често! И глюки, (коих много, судя по форумам) ну никак не влияют на работу! Имеется ввиду версия 10G R2 и выше есс-но, с 9 придется шаманить что-то но не много!

У вас база, если не секрет, какого размера? Насколько быстро растет? Сколько пользователей одновременно работает? Дорабатываете ли вы свое приложение или же раз внедрили - и дальше только бантики прикручиваете?
На счет того, что администрирование сводится к нулю - это вы какие-то сказки тут рассказываете. Может, в ваших конкретных условиях администрированием никто и не занимается, и оно все само как-то при этом умудряется работать, но в общем случае Оракл более требователен к квалификации DBA. У меня перед глазами пример того, как "полтора" (один выделенный и один, занимающийся еще другими вопросами) DBA постоянно что-нить подкручивают в Оракле, пришпиливают аутлайны, приделывают какие-то индексы, которых не видно в AOT'е, периодически апгрейдят сервера (Оракл работает в кластере) и хранилище данных... Не знаю, как бы база жила на Ms SQL, но, во всяком случае, ни о каком сведении администрирования к нулю даже речи не идет.

[egorych]

Цитата:

Сообщение от gl00mie

У вас база, если не секрет, какого размера? Насколько быстро растет? Сколько пользователей одновременно работает? Дорабатываете ли вы свое приложение или же раз внедрили - и дальше только бантики прикручиваете?

База у нас небольшая ~100G, юзеров стабильно 100-120. Внедрение было в 2004 году, с тех пор постоянно чего-то дорабатывается, допиливается.
Насчет администрирования - занимаюсь конкретно я (ну + всякое еще ;-) ), но честное слово - перед переходом сделал нужные настройки, с тех пор поменял помница кол-во процессов и все. Ну слежу за запросами - появляются проблемные - допиливаю. Ну нет других проблем! Чесно!
Возможно это наше частное решение, но, думаю на большинство обычных внедрений оно похоже!
Да, где базы террабайтные там работы больше и следить нужно больше. Дорастем увидим!

[someOne]

Цитата:

Сообщение от gl00mie

На счет того, что администрирование сводится к нулю - это вы какие-то сказки тут рассказываете. Может, в ваших конкретных условиях администрированием никто и не занимается, и оно все само как-то при этом умудряется работать, но в общем случае Оракл более требователен к квалификации DBA. У меня перед глазами пример того, как "полтора" (один выделенный и один, занимающийся еще другими вопросами) DBA постоянно что-нить подкручивают в Оракле, пришпиливают аутлайны, приделывают какие-то индексы, которых не видно в AOT'е, периодически апгрейдят сервера (Оракл работает в кластере) и хранилище данных... Не знаю, как бы база жила на Ms SQL, но, во всяком случае, ни о каком сведении администрирования к нулю даже речи не идет.

Позвольте привести другой пример использования Oracle.
В нашем случае никто ничего "постоянно" не "подкручивает". Более того, DBA по ораклу в штате организации сейчас нет совсем - используем аутсорсинг - администрирование Оракла.

Нет никаких индексов, не видимых в АОТ, это и не к чему - средства АОТ позволяют прекрасно управлять необходимыми индексами без "влезания" в сам Оракл.

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

(Размер базы более 100gb, кол-во активных пользователей окало 100)

Главное что хочется отметить - то что "Оракл требует постоянной работы по его поддержке и тюнинга" - миф.

Ттем у кого 1,5 DBA трудятся над администрированием Оракла рекомендую отдать эту работу на аутсорсинг какой нибудь компании с грамотным DBA по Ораклу. Думаю, что они это сделают и лучше, качественнее и быстрее. Кроме того, можно существенно сэкономить на расходах по обслуживанию системы. (Представил сколько в месяц "стоит" квалифицированный DBA Оракла * 1,5)