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

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