ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
25 сообщений из 324, страница 1 из 13
  1  все
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32621556
TRON
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
TRON
Гость
Вот в чем я вижу этот плюс так это в возможности в ORACLE установить приоритет запроса. Т.е. в MSSQL кто-то запрашивает сложный отчет (сложный запрос) который делается к примету 5 минут, а кто-то другой вынужден долго ждать ответа на свой элементарный запрос (подчеркну- не в блокировках дело , а в загрузке сервера). Вот если бы я мого указать высокий приоритет коротких запросов... Может кто знает будет в Yukon приоритетность запросов?
...
Рейтинг: 0 / 0
26.07.2004, 16:02
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32621606
Geenetix
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Geenetix
Участник
TRONМожет кто знает будет в Yukon приоритетность запросов?
Что такое Yukon?
...
Рейтинг: 0 / 0
26.07.2004, 16:18
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32621714
Фотография segun
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
segun
Участник
авторМожет кто знает будет в Yukon приоритетность запросов?Насколько я знаю, будет только выделенный Admin Connection для администратора, то есть DBA сможет работать с сервером не взирая на загрузку последнего.
...
Рейтинг: 0 / 0
26.07.2004, 17:01
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32622093
None0
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
None0
Гость
TRON, сдается мне что это чисто теоретический плюс. В реальной жизни мало востребованный.

Либо выкладки с замерами в студию.
...
Рейтинг: 0 / 0
26.07.2004, 22:44
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32622104
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
None0TRON, сдается мне что это чисто теоретический плюс. В реальной жизни мало востребованный.

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

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

* не бывает в реальной жизни ситуации, когда требования к времени отклика различны для разных групп пользователей
* не бывает такого, что CPU является узким местом в системе
* не бывает такого, что кто-то запустил отчет за последний квартал, а остальные нервно курят
...
Рейтинг: 0 / 0
26.07.2004, 23:09
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32622170
Фотография andrushok
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrushok
Участник
Я большой любитель Oracle и совсем не любитель MsSQL. Но работаю с ыми обоими, ничего не поделать. И не соглашаюсь, что это +. Если отчет надо генерить - знамо только SELECT. А SELECTы друг другу мало мешают, что сложные, что простые (хотя на виндовозе всякое бывает, тут и Oracle не поможет, если затык какой). Другое дело - менять базу. Так в Oracle и в MsSQL подход разный. И там и сям есть возможность всех построить... Все это вообще, бантики. А так, разбирайте план запроса и оптимизируйте. Не прогодаете. Чудес не бывает. А построение отчета за 5 минут - извините. Такие базы рожать вообще не стоит (3 минуты - максимум, шоб Apache не вырубился =))
...
Рейтинг: 0 / 0
27.07.2004, 01:16
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32622289
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
2 killed

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

2 andrushok

У меня некоторые отчеты по 20 минут строились, и что характерно без всякого Апача. Зачем такая категоричность ? Задачи разные бывают.
...
Рейтинг: 0 / 0
27.07.2004, 07:58
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32622391
Фотография Quark
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Quark
Участник
Выставление приоритетов это необходимая вещь, например в биллинговых системах. Но в принципе это в большинстве случаев можно организовать и на верхнем уровне(очередями, например).
...
Рейтинг: 0 / 0
27.07.2004, 09:32
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32622550
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Васкецов
Участник
None0TRON, сдается мне что это чисто теоретический плюс. В реальной жизни мало востребованный
Представье себе в рамках ERP постоение книги покупок/продаж, расчет производственной себестоимости, перерасчет картотеки склада (если позвляется менять цену и производить движение задним числом, без этого никак нельзя), долгосрочное планировние рисков/финансовое... Еще можно вспомнить, если постараться. На большом предприятии в зависимости от величины расчитываемого периода это может продолжаться крайне долго, при этом это не является предметом оперативного учета, то есть, закончится расчет сейчас или через часа 4 - не принципиально, но он не должен мешать оперативной работе. На кассе покупателю не скажешь, что у нас отчет строится/закупки планируются, мол, покурите полчаса. Если ASE/ORACLE это умеют, то MSSQL тут явно проигрывает независимо от того, приходлось ли Вам с этим сталкиваться. О каких "выкладках с замерами" можно писать, если Вы, судя по всему, не понимаете, о чем идет речь?
...
Рейтинг: 0 / 0
27.07.2004, 10:37
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32622589
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Васкецов
Участник
andrushokЕсли отчет надо генерить - знамо только SELECT. А SELECTы друг другу мало мешают, что сложные, что простые
Отчеты - не обязательно только select, отчеты бывают крайне сложные, с множеством временных и постоянных таблиц.

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

andrushokА построение отчета за 5 минут - извините. Такие базы рожать вообще не стоит
Для отчета, не имеющего оперативной ценности (см. мой пост выше) формально не имеет значения, в течении какого времени он строится. Приходил тут на собеседование один товарищ, рассказывал, что у него себестоимость считается 5 минут и гордился, что очень быстро, при этом даже не заикался об объемах данных и алгоритме расчета.
...
Рейтинг: 0 / 0
27.07.2004, 10:45
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32622610
andsm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andsm
Участник
Правильным подходом является разделение баз данных на оперативную БД и БД отчетности. Тогда обсуждаемые в этом топике проблемы просто не возникают. У меня так и сделано.
...
Рейтинг: 0 / 0
27.07.2004, 10:51
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32622687
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Васкецов
Участник
andsmПравильным подходом является разделение баз данных на оперативную БД и БД отчетности
Это не всегда возможно. Примеры выше я приводил.
...
Рейтинг: 0 / 0
27.07.2004, 11:10
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32622836
TRON
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
TRON
Гость
Сергей Васкецов andsmПравильным подходом является разделение баз данных на оперативную БД и БД отчетности
Это не всегда возможно. Примеры выше я приводил.

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

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

Именно тогда не хватает возможности приоритета. Еще раз подчеркну - речь идет не о блокировках!
...
Рейтинг: 0 / 0
27.07.2004, 11:56
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32622900
TRON
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
TRON
Гость
Сергей Васкецов andsmПравильным подходом является разделение баз данных на оперативную БД и БД отчетности
Это не всегда возможно. Примеры выше я приводил.

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

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

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

А уж гордиться курсорами в SP, я бы не стал. Для меня использование курсора исключение, а не практика.
...
Рейтинг: 0 / 0
27.07.2004, 12:31
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623019
andsm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andsm
Участник
TRON1. Сложный запрос (ОДИН SELECT на несколько (десятков!) страниц) уже существует, отлажен (нюансов может быть очень много) - зачем его менять! (а может быть еще и шифрован).
2. Сложный длительный запрос НАГРУЖАЕТ сервер так, что запрос даже на другую БД(отчетности) сильно тормозится.
Так ведь базы надо разносить на разные сервера, чтобы не мешали друг другу. А так это вроде и разделили, а толку все равно мало.
...
Рейтинг: 0 / 0
27.07.2004, 12:44
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623021
TRON
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
TRON
Гость
Guest_2 автор1. Сложный запрос (ОДИН SELECT на несколько (десятков!) страниц) уже существует, отлажен (нюансов может быть очень много) - зачем его менять! (а может быть еще и шифрован).
Вот потому и надо менять, что выполняется очень долго и забирает для своего выполнения все ресурсы сервера.

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


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

2. Гордится курсорами... При чем тут гордость, хоть убей не пойму? А GUI у Вас на ПК? То же ведь ресурсы забирает...
...
Рейтинг: 0 / 0
27.07.2004, 12:44
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623212
Guest_2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guest_2
Гость
автор2. Гордится курсорами... При чем тут гордость, хоть убей не пойму? А GUI у Вас на ПК? То же ведь ресурсы забирает...
А вот это кто писал?
авторИногда можно поставить в цикле (например перебора курсора) WAITFOR DELAY XXX чтобы дать жить другим запросам
А потом радуемся, что
авторВот в чем я вижу этот плюс так это в возможности в ORACLE установить приоритет запроса

Вот для того, что бы выражаясь Вашим же языком чтобы дать жить другим запросам Сложный запрос (ОДИН SELECT на несколько (десятков!) страниц) необходимо разбить на несколько простых, с использованием временных таблиц.
...
Рейтинг: 0 / 0
27.07.2004, 13:37
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623298
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
авторВот для того, что бы выражаясь Вашим же языком чтобы дать жить другим запросам Сложный запрос (ОДИН SELECT на несколько (десятков!) страниц) необходимо разбить на несколько простых, с использованием временных таблиц.

это как :) ? типа согласованость данных нам уже не нужна ? или у нас dirty read форева ?
...
Рейтинг: 0 / 0
27.07.2004, 14:04
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623335
TRON
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
TRON
Гость
Guest_2 автор2. Гордится курсорами... При чем тут гордость, хоть убей не пойму? А GUI у Вас на ПК? То же ведь ресурсы забирает...
А вот это кто писал?
авторИногда можно поставить в цикле (например перебора курсора) WAITFOR DELAY XXX чтобы дать жить другим запросам
А потом радуемся, что
авторВот в чем я вижу этот плюс так это в возможности в ORACLE установить приоритет запроса

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

Вы мысль плохо держите (видит бог, я старался... ). Повторю еще раз свое мнение:
Есть запрос (SELECT) - один!, сложный, выполняющийся долго, нагружающий сервер и ТОРМОЗЯЩИЙ другие запросы. Почему так сложилось, почему он такой (а не разбит на отдельные блоки и т.д.) - в контексте этого мнения не важно! Так, что жаль, что нет приоритетов запросов в MSSQL 2000. Иногда это серьезный минус.
...
Рейтинг: 0 / 0
27.07.2004, 14:16
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623498
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
Почему так сложилось, почему он такой (а не разбит на отдельные блоки и т.д.) - в контексте этого мнения не важно!
Так можно договориться до того что неважно что именно вообще написано в запросе. Очень удобно будет списать проблемы с производительностью на отсутствие одной вещи. Имхо. По-моему нужно бороться именно с запросом. Раз уж он "сложный, выполняющийся долго, нагружающий сервер". Плюс возможно пересмотреть схему данных. Плюс возможно оптимизировать размещение объектов внутри базы. Плюс возможно пересмотреть оборудование.
...
Рейтинг: 0 / 0
27.07.2004, 15:09
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623504
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
Это я ктому вообще говорил что по-моему для промышленных баз применение приоритета запроса - это абсурд. В такой базе ВСЕ запросы должны отрабатывать оптимально быстро. В силу своей организации а не данного им приоритета.

Приоритет возможно нужен для каких-то разовых задач и конечно же для пользователей, которые имеют какие-никакие администраторские права.
...
Рейтинг: 0 / 0
27.07.2004, 15:12
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623524
Guest_2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guest_2
Гость
авторВы мысль плохо держите (видит бог, я старался... ). Повторю еще раз свое мнение:Есть запрос (SELECT) - один!, сложный, выполняющийся долго, нагружающий сервер и ТОРМОЗЯЩИЙ другие запросы. Почему так сложилось, почему он такой (а не разбит на отдельные блоки и т.д.) - в контексте этого мнения не важно!
Я мысль держу хорошо.
Бросьте заниматься выдумыванием плюсов на пустом месте и зрите в корень. Этот запрос и есть проблема. Устранить проблему - значит переписать запрос. Этим и надо заниматься. Рано или поздно Вам все равно придется это сделать.
...
Рейтинг: 0 / 0
27.07.2004, 15:18
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623558
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
2Glory
паазвольте с Вами не согласится.
приоритеты - в некоторых случаях очень даже хороши. рассмотрим ситуацию, когда необходимо удалить большой объем данных. Не суть важно почему - это может быть неудавшийся документ, промежуточные результаты расчетов и т.д.
Простое удаление - достаточно длительный процесс. Одним из выходов является установка на данных флага "Удалено" , а собственно удаление делать в "фоновом" режиме - джобом, к примеру.
так вот мне бы не хотелось, чтобы вот такое "Фоновое" удаление существенно влияло на текущую работу.
2Guest_2
>Устранить проблему - значит переписать запрос. Этим и надо заниматься. Рано или поздно Вам все равно придется это сделать.
давайте попробуем оптимизировать запрос вида
Код: plaintext
1.
2.
3.
4.
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 хочет как можно скорее выполнить все запросы, в т.ч. и этого аналитика.
...
Рейтинг: 0 / 0
27.07.2004, 15:28
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623586
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
приоритеты - в некоторых случаях очень даже хороши. рассмотрим ситуацию, когда необходимо удалить большой объем данных. Не суть важно почему - это может быть неудавшийся документ, промежуточные результаты расчетов и т.д.
Во-во в некоторых(!) случаях. Т.е. в каких-то специальных так скажем режимах работы. А не в той картине которую нам нарисовал TRON - что какие-то "силньно грузящие" действия являются штатным(!) режимом. Тем более каким-то стандартным отчетом.
...
Рейтинг: 0 / 0
27.07.2004, 15:34
| Ответить | Цитировать | Написать  
25 сообщений из 324, страница 1 из 13
  1  все
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]