Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10 .. 13   вперед  Ctrl
 БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
TRON
Member

Откуда:
Сообщений: 6
Вот в чем я вижу этот плюс так это в возможности в ORACLE установить приоритет запроса. Т.е. в MSSQL кто-то запрашивает сложный отчет (сложный запрос) который делается к примету 5 минут, а кто-то другой вынужден долго ждать ответа на свой элементарный запрос (подчеркну- не в блокировках дело , а в загрузке сервера). Вот если бы я мого указать высокий приоритет коротких запросов... Может кто знает будет в Yukon приоритетность запросов?
26 июл 04, 16:02    [835448]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Geenetix
Member

Откуда:
Сообщений: 139
TRON
Может кто знает будет в Yukon приоритетность запросов?

Что такое Yukon?
26 июл 04, 16:18    [835541]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
segun
Member

Откуда: Москва
Сообщений: 504
автор
Может кто знает будет в Yukon приоритетность запросов?
Насколько я знаю, будет только выделенный Admin Connection для администратора, то есть DBA сможет работать с сервером не взирая на загрузку последнего.
26 июл 04, 17:01    [835772]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
None0
Guest
TRON, сдается мне что это чисто теоретический плюс. В реальной жизни мало востребованный.

Либо выкладки с замерами в студию.
26 июл 04, 22:44    [836434]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
None0
TRON, сдается мне что это чисто теоретический плюс. В реальной жизни мало востребованный.

Либо выкладки с замерами в студию.


Ай молодца! Ну чего тут обсуждать, не нужно в реальной жизни и баста!
И я вынужден с Вами согласится, поскольку:

* не бывает в реальной жизни ситуации, когда требования к времени отклика различны для разных групп пользователей
* не бывает такого, что CPU является узким местом в системе
* не бывает такого, что кто-то запустил отчет за последний квартал, а остальные нервно курят
26 июл 04, 23:09    [836451]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
andrushok
Member

Откуда: от верблюда
Сообщений: 7430
Я большой любитель Oracle и совсем не любитель MsSQL. Но работаю с ыми обоими, ничего не поделать. И не соглашаюсь, что это +. Если отчет надо генерить - знамо только SELECT. А SELECTы друг другу мало мешают, что сложные, что простые (хотя на виндовозе всякое бывает, тут и Oracle не поможет, если затык какой). Другое дело - менять базу. Так в Oracle и в MsSQL подход разный. И там и сям есть возможность всех построить... Все это вообще, бантики. А так, разбирайте план запроса и оптимизируйте. Не прогодаете. Чудес не бывает. А построение отчета за 5 минут - извините. Такие базы рожать вообще не стоит (3 минуты - максимум, шоб Apache не вырубился =))
27 июл 04, 01:16    [836534]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
2 killed

Третий пункт IMHO немножко не того, не по процессору :)

2 andrushok

У меня некоторые отчеты по 20 минут строились, и что характерно без всякого Апача. Зачем такая категоричность ? Задачи разные бывают.
27 июл 04, 07:58    [836686]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Quark
Member

Откуда: Екат
Сообщений: 1099
Выставление приоритетов это необходимая вещь, например в биллинговых системах. Но в принципе это в большинстве случаев можно организовать и на верхнем уровне(очередями, например).
27 июл 04, 09:32    [836819]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Сергей Васкецов
Member

Откуда:
Сообщений: 20362
None0
TRON, сдается мне что это чисто теоретический плюс. В реальной жизни мало востребованный

Представье себе в рамках ERP постоение книги покупок/продаж, расчет производственной себестоимости, перерасчет картотеки склада (если позвляется менять цену и производить движение задним числом, без этого никак нельзя), долгосрочное планировние рисков/финансовое... Еще можно вспомнить, если постараться. На большом предприятии в зависимости от величины расчитываемого периода это может продолжаться крайне долго, при этом это не является предметом оперативного учета, то есть, закончится расчет сейчас или через часа 4 - не принципиально, но он не должен мешать оперативной работе. На кассе покупателю не скажешь, что у нас отчет строится/закупки планируются, мол, покурите полчаса. Если ASE/ORACLE это умеют, то MSSQL тут явно проигрывает независимо от того, приходлось ли Вам с этим сталкиваться. О каких "выкладках с замерами" можно писать, если Вы, судя по всему, не понимаете, о чем идет речь?
27 июл 04, 10:37    [837061]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Сергей Васкецов
Member

Откуда:
Сообщений: 20362
andrushok
Если отчет надо генерить - знамо только SELECT. А SELECTы друг другу мало мешают, что сложные, что простые

Отчеты - не обязательно только select, отчеты бывают крайне сложные, с множеством временных и постоянных таблиц.

andrushok
И там и сям есть возможность всех построить

На MSSQL можно так log заполнить, что никто даже залогиниться на сервер (!) не сможет, о чем вы вообще?

andrushok
А построение отчета за 5 минут - извините. Такие базы рожать вообще не стоит

Для отчета, не имеющего оперативной ценности (см. мой пост выше) формально не имеет значения, в течении какого времени он строится. Приходил тут на собеседование один товарищ, рассказывал, что у него себестоимость считается 5 минут и гордился, что очень быстро, при этом даже не заикался об объемах данных и алгоритме расчета.
27 июл 04, 10:45    [837115]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
Правильным подходом является разделение баз данных на оперативную БД и БД отчетности. Тогда обсуждаемые в этом топике проблемы просто не возникают. У меня так и сделано.
27 июл 04, 10:51    [837153]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Сергей Васкецов
Member

Откуда:
Сообщений: 20362
andsm
Правильным подходом является разделение баз данных на оперативную БД и БД отчетности

Это не всегда возможно. Примеры выше я приводил.
27 июл 04, 11:10    [837272]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
TRON
Member

Откуда:
Сообщений: 6
Сергей Васкецов
andsm
Правильным подходом является разделение баз данных на оперативную БД и БД отчетности

Это не всегда возможно. Примеры выше я приводил.


Иногда так разделить возможно. Иногда можно поставить в цикле (например перебора курсора) WAITFOR DELAY XXX чтобы дать жить другим запросам (запросам в широком смысле необязательно один SELECT). Но!

1. Сложный запрос (ОДИН SELECT на несколько (десятков!) страниц) уже существует, отлажен (нюансов может быть очень много) - зачем его менять! (а может быть еще и шифрован).
2. Сложный длительный запрос НАГРУЖАЕТ сервер так, что запрос даже на другую БД(отчетности) сильно тормозится.

Именно тогда не хватает возможности приоритета. Еще раз подчеркну - речь идет не о блокировках!
27 июл 04, 11:56    [837567]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
TRON
Member

Откуда:
Сообщений: 6
Сергей Васкецов
andsm
Правильным подходом является разделение баз данных на оперативную БД и БД отчетности

Это не всегда возможно. Примеры выше я приводил.


Иногда так разделить возможно. Иногда можно поставить в цикле (например перебора курсора) WAITFOR DELAY XXX чтобы дать жить другим запросам (запросам в широком смысле необязательно один SELECT). Но!

1. Сложный запрос (ОДИН SELECT на несколько (десятков!) страниц) уже существует, отлажен (нюансов может быть очень много) - зачем его менять! (а может быть еще и шифрован).
2. Сложный длительный запрос НАГРУЖАЕТ сервер так, что запрос даже на другую БД(отчетности) сильно тормозится.

Именно тогда не хватает возможности приоритета. Еще раз подчеркну - речь идет не о блокировках!
27 июл 04, 12:12    [837672]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Guest_2
Guest
автор
1. Сложный запрос (ОДИН SELECT на несколько (десятков!) страниц) уже существует, отлажен (нюансов может быть очень много) - зачем его менять! (а может быть еще и шифрован).

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

А уж гордиться курсорами в SP, я бы не стал. Для меня использование курсора исключение, а не практика.
27 июл 04, 12:31    [837794]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
andsm
Member

Откуда: Москва
Сообщений: 1320
Блог
TRON
1. Сложный запрос (ОДИН SELECT на несколько (десятков!) страниц) уже существует, отлажен (нюансов может быть очень много) - зачем его менять! (а может быть еще и шифрован).
2. Сложный длительный запрос НАГРУЖАЕТ сервер так, что запрос даже на другую БД(отчетности) сильно тормозится.

Так ведь базы надо разносить на разные сервера, чтобы не мешали друг другу. А так это вроде и разделили, а толку все равно мало.
27 июл 04, 12:44    [837875]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
TRON
Member

Откуда:
Сообщений: 6
Guest_2
автор
1. Сложный запрос (ОДИН SELECT на несколько (десятков!) страниц) уже существует, отлажен (нюансов может быть очень много) - зачем его менять! (а может быть еще и шифрован).

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

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



1. ...потому и менять надо...
Напоминает мне это с anekdot.ru вопрос-ответ к конференции
в. - Ребята у меня член не стоит! Помогите! Что делать?
о. Да? А меня хоть ведро с бетоном вешай!

2. Гордится курсорами... При чем тут гордость, хоть убей не пойму? А GUI у Вас на ПК? То же ведь ресурсы забирает...
27 июл 04, 12:44    [837879]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Guest_2
Guest
автор
2. Гордится курсорами... При чем тут гордость, хоть убей не пойму? А GUI у Вас на ПК? То же ведь ресурсы забирает...

А вот это кто писал?
автор
Иногда можно поставить в цикле (например перебора курсора) WAITFOR DELAY XXX чтобы дать жить другим запросам

А потом радуемся, что
автор
Вот в чем я вижу этот плюс так это в возможности в ORACLE установить приоритет запроса


Вот для того, что бы выражаясь Вашим же языком чтобы дать жить другим запросам Сложный запрос (ОДИН SELECT на несколько (десятков!) страниц) необходимо разбить на несколько простых, с использованием временных таблиц.
27 июл 04, 13:37    [838237]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Yo!
Guest
автор
Вот для того, что бы выражаясь Вашим же языком чтобы дать жить другим запросам Сложный запрос (ОДИН SELECT на несколько (десятков!) страниц) необходимо разбить на несколько простых, с использованием временных таблиц.


это как :) ? типа согласованость данных нам уже не нужна ? или у нас dirty read форева ?
27 июл 04, 14:04    [838380]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
TRON
Member

Откуда:
Сообщений: 6
Guest_2
автор
2. Гордится курсорами... При чем тут гордость, хоть убей не пойму? А GUI у Вас на ПК? То же ведь ресурсы забирает...

А вот это кто писал?
автор
Иногда можно поставить в цикле (например перебора курсора) WAITFOR DELAY XXX чтобы дать жить другим запросам

А потом радуемся, что
автор
Вот в чем я вижу этот плюс так это в возможности в ORACLE установить приоритет запроса


Вот для того, что бы выражаясь Вашим же языком чтобы дать жить другим запросам Сложный запрос (ОДИН SELECT на несколько (десятков!) страниц) необходимо разбить на несколько простых, с использованием временных таблиц.


Вы мысль плохо держите (видит бог, я старался... ). Повторю еще раз свое мнение:
Есть запрос (SELECT) - один!, сложный, выполняющийся долго, нагружающий сервер и ТОРМОЗЯЩИЙ другие запросы. Почему так сложилось, почему он такой (а не разбит на отдельные блоки и т.д.) - в контексте этого мнения не важно! Так, что жаль, что нет приоритетов запросов в MSSQL 2000. Иногда это серьезный минус.
27 июл 04, 14:16    [838440]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Glory
Member

Откуда:
Сообщений: 104751
Почему так сложилось, почему он такой (а не разбит на отдельные блоки и т.д.) - в контексте этого мнения не важно!
Так можно договориться до того что неважно что именно вообще написано в запросе. Очень удобно будет списать проблемы с производительностью на отсутствие одной вещи. Имхо. По-моему нужно бороться именно с запросом. Раз уж он "сложный, выполняющийся долго, нагружающий сервер". Плюс возможно пересмотреть схему данных. Плюс возможно оптимизировать размещение объектов внутри базы. Плюс возможно пересмотреть оборудование.
27 июл 04, 15:09    [838751]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Glory
Member

Откуда:
Сообщений: 104751
Это я ктому вообще говорил что по-моему для промышленных баз применение приоритета запроса - это абсурд. В такой базе ВСЕ запросы должны отрабатывать оптимально быстро. В силу своей организации а не данного им приоритета.

Приоритет возможно нужен для каких-то разовых задач и конечно же для пользователей, которые имеют какие-никакие администраторские права.
27 июл 04, 15:12    [838767]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Guest_2
Guest
автор
Вы мысль плохо держите (видит бог, я старался... ). Повторю еще раз свое мнение:Есть запрос (SELECT) - один!, сложный, выполняющийся долго, нагружающий сервер и ТОРМОЗЯЩИЙ другие запросы. Почему так сложилось, почему он такой (а не разбит на отдельные блоки и т.д.) - в контексте этого мнения не важно!

Я мысль держу хорошо.
Бросьте заниматься выдумыванием плюсов на пустом месте и зрите в корень. Этот запрос и есть проблема. Устранить проблему - значит переписать запрос. Этим и надо заниматься. Рано или поздно Вам все равно придется это сделать.
27 июл 04, 15:18    [838810]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
2Glory
паазвольте с Вами не согласится.
приоритеты - в некоторых случаях очень даже хороши. рассмотрим ситуацию, когда необходимо удалить большой объем данных. Не суть важно почему - это может быть неудавшийся документ, промежуточные результаты расчетов и т.д.
Простое удаление - достаточно длительный процесс. Одним из выходов является установка на данных флага "Удалено" , а собственно удаление делать в "фоновом" режиме - джобом, к примеру.
так вот мне бы не хотелось, чтобы вот такое "Фоновое" удаление существенно влияло на текущую работу.
2Guest_2
>Устранить проблему - значит переписать запрос. Этим и надо заниматься. Рано или поздно Вам все равно придется это сделать.
давайте попробуем оптимизировать запрос вида
select Date,Sum(Summ),Sum(Vol),Max(Amount)
from DocDebet
where Date >= @df and Date < @dt
group by Date
где мощность таблицы DocDebet ~2*10^8, под условие отбора попадает ~12*10^6 строк.
Согласен, можно заранее считать промежуточные результаты (такой себе мини-OLAP). Но для этого надо знать, какие данные нам могут понадобится, а это можно сделать далеко не всегда. К тому же OLAP обычно значительно превосходит по объемам данных OLTP, что в случае с ограниченными техническими средствами делает его применения недопустимым.
Остается один выход - считать на лету. И опять-таки не хочется чтобы какой-нибудь "аналитик" застопорил текущую работу из-за того, что SQL Server хочет как можно скорее выполнить все запросы, в т.ч. и этого аналитика.
27 июл 04, 15:28    [838888]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Glory
Member

Откуда:
Сообщений: 104751
приоритеты - в некоторых случаях очень даже хороши. рассмотрим ситуацию, когда необходимо удалить большой объем данных. Не суть важно почему - это может быть неудавшийся документ, промежуточные результаты расчетов и т.д.
Во-во в некоторых(!) случаях. Т.е. в каких-то специальных так скажем режимах работы. А не в той картине которую нам нарисовал TRON - что какие-то "силньно грузящие" действия являются штатным(!) режимом. Тем более каким-то стандартным отчетом.
27 июл 04, 15:34    [838935]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2 3 4 5 6 7 8 9 10 .. 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить