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

[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, тем более я с ним довно-давно работаю (и сейчас тоже). Мне он очень нравится! С Ораклом я относительно недавно - год где-то. Поэтому я могу сравнить как они работают применительно к Аксапте.
Извините, но я опять повторю - работа с MS через курсор есть АФИГЕННОЕ ЗЛО!

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

[ZVV]

Цитата:

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

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

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

[Logger]

Цитата:

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

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

А от этого уже лекарство придумали.
Не удалять индексы при синхронизации
Мы давно используем, проблем не было.

[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)