ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
324 сообщений из 324, показаны все 13 страниц
  все  
БОЛЬШОЙ ПЛЮС 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
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623662
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
так объясните как вы переписав запрос используя временные таблицы получите согласованые данные ?
...
Рейтинг: 0 / 0
27.07.2004, 15:51
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623669
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
у меня удаление промежуточных данных - штатный режим работы.
да и расчет отчетов - вроде бы тоже штатный режим работы, не так ли?
...
Рейтинг: 0 / 0
27.07.2004, 15:54
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623679
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
так объясните как вы переписав запрос используя временные таблицы получите согласованые данные ?
А почему они должны быть несогласованными если их никто не изменяет ?
...
Рейтинг: 0 / 0
27.07.2004, 15:58
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623689
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
> А почему они должны быть несогласованными если их никто не изменяет ?

это как :) ?
...
Рейтинг: 0 / 0
27.07.2004, 16:02
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623713
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
Вот так. Автор заявил "а кто-то другой вынужден долго ждать ответа на свой элементарный запрос ( подчеркну- не в блокировках дело , а в загрузке сервера). "
Если нет блокировок, значит нет доступа к совместным данным. Если нет доступа к совместным данным то почему надо заботится о согласовании ?

Да даже если нужно согласование то почему вы считает что именно использование временных таблиц может его нарушить ?

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


есть такая традиция у субд давать доступ к совместным данным :)
просто автор немного непонял что все упирается в блокировочный механизм, длинную транзакцию нельзя задерживать иначе она за счет блокировок застопорит другие транзакции (в mssql еще помножить на эскалацию). ibm для дб2 советует чтоб увеличить concurency почаще комитится ...

Glory
Да даже если нужно согласование то почему вы считает что именно использование временных таблиц может его нарушить ?


если один запрос ты бьешь на несколько транзакций, то теряется согласованость.
...
Рейтинг: 0 / 0
27.07.2004, 16:31
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623818
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
2Glory
>И что теперь решать вопрос производительности работы отчета путем изменения приоритета запроса ? Не анализом плана выполнения ? Не анализом индексов, схемы данных ?
Если можно, приведите Ваши рекомендации для запроса, который я привел выше.
>Не анализом узких мест обрудования ?
За анализом узких мест обычно должно следовать их устранение. А это - трата денег, иногда - значительная. Замена дисковой подсистемы на более навороченную может повлечь за собой замену всего сервера.
2Yo!
>если один запрос ты бьешь на несколько транзакций, то теряется согласованость.
а если я считаю отчет за закрытый период, в котором данные не изменяются, то не теряю :-) Более того, там даже транзакции и не нужны.
...
Рейтинг: 0 / 0
27.07.2004, 16:38
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623832
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
есть такая традиция у субд давать доступ к совместным данным
просто автор немного непонял что все упирается в блокировочный механизм, длинную транзакцию нельзя задерживать иначе она за счет блокировок застопорит другие транзакции (в mssql еще помножить на эскалацию).

Если речь идет про отчеты т.е. про чтение данных то временные таблицы никаким образом не смогут нарушить согласованность данных. И совместные блокировки на чтения друг другу не мешают.

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

А насчет того что автор чего-то не понял - так это уже ваши предположения.

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

ЗЫ
А оптимизатора способного составить оптимальный план запроса текст которого на 10 листов просто не возможно создать. Имхо. Либо этот оптимизатор будет искать этот план дольше чем собственно времени выполнения запроса
...
Рейтинг: 0 / 0
27.07.2004, 16:43
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623844
ыыыы
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ыыыы
Участник
Складывается впечатление, что некоторым вообще не надо было с файл-сервера слезать
Ни тебе заботы о дисковых подсистемах и процессорах на серверах, ни проблем с загруженностью, ни оптимизации запросов... Какие-такие планы запросов?
Подумаешь - какой-то аналитик мега-отчет начал снимать. Ну провесилась у него машина, но ведь только у него. Через пять часов он этот отчет снимет, а все остальные - как работали, так и будут работать. ЛЯПОТА!
Однако некоторые слезают... приоритеты запросам потом раздают...

это так... ни к кому конкретно не обращаясь.
...
Рейтинг: 0 / 0
27.07.2004, 16:46
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623847
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
Если можно, приведите Ваши рекомендации для запроса, который я привел выше
Я что-то не увидел нигде в этом топике текста запроса.

За анализом узких мест обычно должно следовать их устранение. А это - трата денег, иногда - значительная. Замена дисковой подсистемы на более навороченную может повлечь за собой замену всего сервера.
Анализ и создание индексов тоже требуют денег ? Пересмотр схемы данных тоже?
А оптимизация дисковой системы не обязательно должна сводится к покупке "навороченного" контроллера. Начинать можно с вынесения базы tempdb на отдельный диск(даже с RAID0). Или с отказа от RAID5 для OLTP системы например.
...
Рейтинг: 0 / 0
27.07.2004, 16:48
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623866
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
может я просто чего то не догоняю ...запрос

select .. table1
union
select .. table2

вы предлагаете переписать
T0 select table1 into #tmp1
T1 select table2 into #tmp2

в момент T0 данные в table2 меняются ...
...
Рейтинг: 0 / 0
27.07.2004, 16:56
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623893
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
может я просто чего то не догоняю ...запрос
Если этот запрос содержится где-то на 10-ом уровне вложенности всего запроса, то имеет смысл переписать
create table #tmp(.... ) --
insert #tmp
select * into
from(
select .. table1
union
select .. table2
) AS a

select .... from ....#tmp

Особенно если в плане выполнения будут присутствовать операции Table/Index Spool. Для Derived table создание промежуточной таблицы также может оказаться выгодным. Особенно если Derived table вычисляет какие-то агрегаты, что позволит нам для промежуточной таблицы создать ПК или уникальный индекс

А для блокировок как я уже сказл существуют транзакции и уровни изоляции.
...
Рейтинг: 0 / 0
27.07.2004, 17:05
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623916
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
представте я что select * from table(1/2) это тоже тяжелые вложеные запросы, это я для обстракции ...
select * into
from(
select .. table1
union
select .. table2
) AS a

если так переписать то смысла маловато.

>А для блокировок как я уже сказл существуют транзакции и уровни изоляции.

непонимаю ... или вы на dirty read намекаете ?
...
Рейтинг: 0 / 0
27.07.2004, 17:16
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623945
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
2Glory
да вот же запрос, на.. хмм. уже предыдущей страничке
Код: plaintext
1.
2.
3.
4.
select Date,Sum(Summ),Sum(Vol),Max(Amount)
from DocDebet
where Date >= @df and Date < @dt
group by Date
>Анализ и создание индексов тоже требуют денег ? Пересмотр схемы данных тоже?
Дык, Glory, вы то (и я тоже) писали о анализе узких мест оборудования!!!
А вынос tempdb на отдельный диск может привести к тому, что штатный БП уже не будет тянуть нагрузку, к примеру... или корзинка/корпус не предусматривает установку дополнительных дисков (а тогда надо внешнее, типа Fujitsu Sx30)...
Отказ от Raid5 - это вполне вариант, конечно. Иногда, правда, трудно убедить заказчика, но это технические детали и о них не стоит (говорю без иронии, не как повод обсудить еще и такой аспект).
...
Рейтинг: 0 / 0
27.07.2004, 17:23
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623961
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
если так переписать то смысла маловато.
Если посмотреть на план всего запроса то операции Table/Index Spool можно смело заменять на занесение данных в промежуточные таблицы. Поскольку эти операции и есть создание этих временных таблиц. Это раз.

Уменьшая количество таблиц в основном запросе мы автоматически уменьшаем количество возможных планов выполнения. Что дает оптимизатору шанс найти более оптимальный план. Это два.

Создавая на промежуточных таблицах какие-то даже элементарные индексы вроде ПК (к примеру для той же derived table) мы позволяем оптимизатору возможность использовать эти индексы. Это три.

Понятно что речь не идет о занесении в промежуточные таблицы конечных результатов как вы показали для "select .. table1 union select .. table2". А именно вот для этих самых "select * from table(1/2) это тоже тяжелые вложеные запросы""

непонимаю ... или вы на dirty read намекаете ?
Это вы все время намекает на какую-то несогласованность данных.
...
Рейтинг: 0 / 0
27.07.2004, 17:27
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623964
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
2ыыыы
Да, блин, мы такие!
Потому что у меня система - он-лайн, мне важно, чтобы очереди в приемный пункт были как можно меньше, чтобы инженера работали быстро.
И то что я по ходу дела считаю аналитические отчеты на том же сервере - так это от бедности :-( Ну нет у меня еще одной железки, нету!
И мне практически всё равно, что аналитик получит отчет не через 5 минут, а через 20 - система в первую очередь не для аналитического учета, а для оперативного.
...
Рейтинг: 0 / 0
27.07.2004, 17:28
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623972
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
Дык, Glory, вы то (и я тоже) писали о анализе узких мест оборудования!!!
Я поставил анализ оборудования на 3ее место. После плана выполнеия, индексов и схемы данных. Потому что понятно что начинать нужно с более дешевых способов оптимизации.
...
Рейтинг: 0 / 0
27.07.2004, 17:29
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623985
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
заметил интересные особенности:
Yo! в основном интересует согласованность данных (видать натерпелся и/или специфика систем такова).
Glory по большей части интересуется правильным проектированием и оптимизацией. Видать намучился, обучая молодежжж..
причем первый отвергает практически все попытки утверждать, что согласованность - не всегда самое главное, а второй утверждает, что всегда можно перепроектировать по правильному.
Что интересно, оба они правы и неправы одновременно.
По поводу согласованности ничего говорить не буду, у меня таких проблем не возникает, а вот по поводу перепроектирования.... Дык это денег стоит. Да, я вижу, что в моей системе есть "некрасивые" места. Я уже знаю, что их можно было бы сделать по другому. Но делать этого нельзя. потому что изменение части может повлечь за собой полную перепроверку всей системы в целом. это долго и дорого.
К тому же я не упускаю из виду сопровождение чужой системы, в которой мы не имеем права/возможности что-либо менять. мы только можем изменять настройки сервера. И в некоторых случаях настройки приоритета были бы очень кстати.
...
Рейтинг: 0 / 0
27.07.2004, 17:36
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32623992
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
2Glory

я посмотрел Table/Index Spool нет, следуя вашим рекомендациям получил 5% ускорение. теперь запрос идет не 30 минут, а 25.
ну и что это меняет ? принципиально ? надеюсь вы не станете уверять что любой запрос можно оттюнить до 3х минут.
...
Рейтинг: 0 / 0
27.07.2004, 17:40
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624008
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
>Я поставил анализ оборудования на 3ее место. После плана выполнеия, индексов и схемы данных. Потому что понятно что начинать нужно с более дешевых способов оптимизации.
Аболютно согласен. Причем схема данных значительно дороже плана/индексов.
Именно по этому я попросил соптимизировать мой запрос-пример.
Кстати, почему ни у кого не вызывает вопросов option(maxdop N) или with (index=...)?или SET DEADLOCK_PRIORITY? это ведь тоже способы оптимизации. Причем под оптимизацией давайте понимать оптмизации работы системы в целом, а не отдельных ее частей. никого не будет интересовать, насколько быстро считаются отчеты, если в процессе расчета тормозит остальная работа.
Давайте рассматривать опцию вида set priority low|high как полезную фичу, которая помогает в некоторых жизненных ситуациях.
P.S. Хотя, как бы мы к приоритету не относились, пока его нет - наши слова так, облачка в небе...
...
Рейтинг: 0 / 0
27.07.2004, 17:44
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624029
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
2locky

если у вас нет проблем с блокировками почему бы не далать как ibm в db2 - писать внешнюю сторед процедуру (которая работает как отдельный процесс) и на этот процесс средствами уже ос ставить приоритет ?
...
Рейтинг: 0 / 0
27.07.2004, 17:50
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624031
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
>я посмотрел Table/Index Spool нет, следуя вашим рекомендациям получил 5% ускорение. теперь запрос идет не 30 минут, а 25.
ну, предполжим, не 5%, а около 16%... вот так вот, на ровном месте, без смены железяк и изменения схемы данных получить 15% запас по производительности - очень даже ничего, верно ведь? причем, не прилагая особенных усилий/времени...
...
Рейтинг: 0 / 0
27.07.2004, 17:50
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624035
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
>если у вас нет проблем с блокировками почему бы не далать как ibm в db2 - писать внешнюю сторед процедуру (которая работает как отдельный процесс) и на этот процесс средствами уже ос ставить приоритет ?
дык, эта... я ведь там суммирую чего-то как-то... цифры надо из базы получить? надо. как получить? одним единственным способом - сделать select... а вот на выполнение этого select'а и хочеться назначить приоритет.
...
Рейтинг: 0 / 0
27.07.2004, 17:52
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624040
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
запрос идет не 30 минут, а 25.
ну и что это меняет ? принципиально ?
1. Ну для начала 5 минут вашем случае не 5% а 16%.

2. Если вы хотите привлечь меня к полной оптимизации ваших запросов то я за это беру деньги. При отсутствии сведений о схеме данных, тексте самого запроса, плана выполнения, конфигурации обрудовани и тп - дороже (пропорционально каждому отсутствующему элементу)


надеюсь вы не станете уверять что любой запрос можно оттюнить до 3х минут
Любой нельзя. А мы уже рассуждаеи об оптимизации любого запроса или все таки еще придерживаемся посылки об оптимизации запросов на 10 страниц ???
Никакой тюнинг запроса не увеличит пропускную способность дисковой системы или объем оперативной памяти.


К тому же я не упускаю из виду сопровождение чужой системы, в которой мы не имеем права/возможности что-либо менять. мы только можем изменять настройки сервера. И в некоторых случаях настройки приоритета были бы очень кстати.
Т.е. ищзменение приоритета запроса в ситеме типа "черный ящик" - это не есть "право/возможность что-либо менять" в ней ????
...
Рейтинг: 0 / 0
27.07.2004, 17:54
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624046
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
Именно по этому я попросил соптимизировать мой запрос-пример.
Да где он ваш пример то этот ?

Кстати, почему ни у кого не вызывает вопросов option(maxdop N) или with (index=...)?или SET DEADLOCK_PRIORITY? это ведь тоже способы оптимизации. Причем под оптимизацией давайте понимать оптмизации работы системы в целом, а не отдельных ее частей. никого не будет интересовать, насколько быстро считаются отчеты, если в процессе расчета тормозит остальная работа.
Давайте рассматривать опцию вида set priority low|high как полезную фичу, которая помогает в некоторых жизненных ситуациях.
Согласен.
...
Рейтинг: 0 / 0
27.07.2004, 17:56
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624068
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
>Т.е. ищзменение приоритета запроса в ситеме типа "черный ящик" - это не есть "право/возможность что-либо менять" в ней ????
ну почему сразу "Черный ящик"? мне как DBA никто не может запретить анализировать базу, смотреть на неё.. а вот "счупать руками"... типа там, индекс построить... ну, наверное, это не очень страшно. а вот схему данных поменять - тут уж увольте-с, слишком стрёмно.
Да к тому же существую всякого рода инструменты, которые позволяют юзеру строить отчеты... на них то не наздравтсвуешься! они иногда такое генерят - мама моя дорогая! Одна из таких систем выдавала запросы вида
Код: plaintext
1.
select * from DocDebet where year(date)= 2000  and month(date)= 4
и сервер честно сканил агроменную таблицу.... все были счастливы :-)
да и запросцы такие тулзы на 10 страниц запросто генерят. оптимизировать их как? да никак! а вот хотя бы придавить, чтобы не так мешали....
кста, вспомним еще про query governor cost limit - есть ведь штука, которая рубит запросы, которые могут долго выполнятся! но нам то надо не зарубить, пусть себе работает... главное чтобы тихонько-тихонько....
...
Рейтинг: 0 / 0
27.07.2004, 18:05
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624077
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
Glory

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

ну наконец то, итак тюнинг ситуацию не изменит, даже если вам удастся ускорить в 2 раза до 15 минут это не приемлимо. не многие позволить залочить пол базы на 15 минут. дальше если на этот запрос поставить приоритет то он залочит пол базы на гораздо большее время, что смысла вообще не имеет.
...
Рейтинг: 0 / 0
27.07.2004, 18:09
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624094
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
2Glory
>Да где он ваш пример то этот ?
Glory, я щаз сказюся! Да вот же он, 3-й раз постю...
Могу еще токо в мыло кинуть...
Код: plaintext
1.
2.
3.
4.
select Date,Sum(Summ),Sum(Vol),Max(Amount)
from DocDebet
where Date >= @df and Date < @dt
group by Date
P.S. или вы намекаете на правила со скриптом таблицы и всё такое?
Код: plaintext
1.
2.
3.
4.
5.
create table DocDebet(date smalldatetime not null,Summ money not null,Vol float not null,Amount int not null)
create clustered index cl on DocDebet(date)
insert into DocDebet(date,Summ,Vol,Amount)
select crdate,id,uid,info
from sysobjects

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
declare @df smalldatetime,@dt smalldatetime
set @df = '20040101'
set @dt = '20040201'
select Date,Sum(Summ),Sum(Vol),Max(Amount)
from DocDebet
where Date >= @df and Date < @dt
group by Date
только строчек набабахайте поболее, миллионов эдак... ну 50, хотябы, с распределением по месяцам по 10-12 миллионов.
...
Рейтинг: 0 / 0
27.07.2004, 18:14
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624097
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
>> Glory
>>Никакой тюнинг запроса не увеличит пропускную способность дисковой системы или объем оперативной памяти.
>ну наконец то, итак тюнинг ситуацию не изменит
Вай-ме! Да тюнинг-то предназначен не для того, чтобы увеличивать память или пропускную способность ДПС, а для того (в числе всего прочего, хотя иногда верно и обратное), чтобы сократить их(ресурсов) потребление!
Если вы разбиваете запрос вида
Код: plaintext
1.
select acc,Sum(Summ) from Table group by acc
на два запроса
Код: plaintext
1.
2.
select acc,Sum(Summ) from Table where acc <  1000  group by acc
select acc,Sum(Summ) from Table where acc >=  1000  group by acc
это может значить, что worktable для суммирования будет умещаться в ОЗУ и не будет сбрасывать на диск, а значит будет меньше дисковых операций и тогда пропускная способность ДПС не так важна.
...
Рейтинг: 0 / 0
27.07.2004, 18:18
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624137
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
2locky

от того что "быстрее" ничего не меняется, даже если это быстрее в 2 раза.
...
Рейтинг: 0 / 0
27.07.2004, 18:52
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624147
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
>ну наконец то, итак тюнинг ситуацию не изменит, даже если вам удастся
>ускорить в 2 раза до 15 минут это не приемлимо. не многие позволить залочить
>пол базы на 15 минут. дальше если на этот запрос поставить приоритет то он
>залочит пол базы на гораздо большее время, что смысла вообще не имеет.
Но еще меньше желающих лочить базу (вот ведь привязались-то с согласовнностью) на 30 минут вместо 15.
А ускорение некоторых запрсов в 2 раза - значит увеличение быстродействия всей системы в целом в те-же 2 раза (хотя когда-как, когда больше, когда меньше).
и потом, давайте все-таки не смешивать некоторые весчи, ок?
а то я живенько могу представить ситуацию, когда блокировщик быренько отработает запрос, а версионник или просто ничего не смоежт сделать, или будет долго-долго висеть.

Мы ведь (я, по крайней мере) рассматриваем ситуацию выполнения долгоиграющих запросов без использования транзакций с уровнем изоляции read uncommitted и использование приоритета выполнения запроса как средство снижения влияния такого рода запросов на работоспособность всей системы в целом.
Вы же рассматриваете приоритеты как полностью недопустимый инструмент.
С этой точки зрения...
Кстати, позвольте Вас спросить: каким уровнем изоляции транзакций вы пользуетесь в сових системах? по моим предположениям, тем, что у MS SQL называется serializable - как обеспечивающий наименьшее количество фантомов и обеспечивающий наилучшую согласованность данных.
...
Рейтинг: 0 / 0
27.07.2004, 19:06
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624154
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nikolay Kulikov
Участник
2 locky: Зачем в DB2 писать хранимую процедуру для и приоритизировать ее не уровне OS. Я честно говоря не понял.
2TORT: Oracle может только устанавливать приоритет запроса или еще какие-то лимиты выставлять???
...
Рейтинг: 0 / 0
27.07.2004, 19:21
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624157
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
2Nikolay Kulikov
если я сам правильно понял предложение Yo!, то он предлагал написать ESP, которой в самой ESP принудительно выставлять процесс на уровне ОС.... но смысла в этом мало, т.к. ESP всё равно должну будет обращаться в серверу за данными, а значит генерировать запросы, приоритет которых мы выставить не можем :-)
Тем более что что-то мне подсказывает, что затруднительно будет выставить приоритет для ESP (разве что для треда, который её выполняет, и то не уверен, как на это отреагирует SQL Server). А если сервер использует не треды, а фиберы? как тогда?
...
Рейтинг: 0 / 0
27.07.2004, 19:29
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624230
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
locky2Nikolay Kulikov
если я сам правильно понял предложение Yo!, то он предлагал написать ESP, которой в самой ESP принудительно выставлять процесс на уровне ОС.... но смысла в этом мало, т.к. ESP всё равно должну будет обращаться в серверу за данными, а значит генерировать запросы, приоритет которых мы выставить не можем :-)


да нет предложение было тащить данные допустим в dbf и уже колбасить внешним процессом этот dbf. фокспром например, чтоб самому движек sql не изобретать. понятно что такое если и прокатит то на очень ограниченом круге задач ...

на счет приоритета, в таком виде на блокировочнике он был бы полезен только при возможности dirty read и несогласованого чтения, что встречается давольно редко в финансовых системах.
к стате если у вас расчеты за прошедший период на данных которые уже не изменятся, почему не расчитать все ночью/выходные ? почему это необходимо делать именно в реалтайм ?

ЗЫ. у меня оракл.
...
Рейтинг: 0 / 0
27.07.2004, 21:09
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624243
None0
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
None0
Гость
Как я и думал, все местные гуру оказались не более чем пустозвонами. Воды на 50 сообщений.
Так где выкладки, господа?

Ну ладно, хрен с ними, с выкладками. Ткните меня лучше в документацию по 8.1.7 где можно закустомизировать:
1) Чтобы сессия работала с более низким приоритетом. (Кстате виндузячьи нити (а оракловские сесии там на нитях) умеют менять приоритет? Или они там не вложены в процесс? ..Блин, совсем все забыл)
2) Чтобы запрос, работал с более низким приоритетом.

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


Развиваю мысль.

Никакой тюнинг запроса не увеличит производительность CPU, это тоже ограниченный ресурс.

Теперь я хочу иметь дополнительную степень свободы, не полагаться на шедулер ОС, для которого все процессы равны (одинаковы), а управлять ими, имея знания со стороны приложения. В оракле эта степень свободы есть.

Почему никого не удивляет возможность назначения приоритета процессу со стороны ОС ? В виндовсе это тоже есть насколько я знаю через диспетчер задач.

Кстати приоритезировать нужно не отдельный запрос, а задачи со стороны бизнеса.
...
Рейтинг: 0 / 0
28.07.2004, 01:45
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624294
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
Nikolay KulikovOracle может только устанавливать приоритет запроса или еще какие-то лимиты выставлять???




Resource Manager
...
Рейтинг: 0 / 0
28.07.2004, 01:47
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624355
Guest_2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guest_2
Гость
2Locky
автор>Устранить проблему - значит переписать запрос. Этим и надо заниматься. Рано или поздно Вам все равно придется это сделать.
давайте попробуем оптимизировать запрос вида
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 строк.
Вообще-то Ваш запрос рассматривать вне контекста всей Информационной Системы (ИС) - есть глупость полнейшая.
Действительно трудно что-либо возразить по поводу оптимизации запроса типа Select * From dba.debt; при той мощности таблицы, которую Вы указали. Вопрос в другом, а насколько необходимо выполнять данный запрос?
Для каких целей? Хорошо, допустим, что необходимо для выполнения какого-нибудь отчета. Тогда возникает другой вопрос, почему подготовка этого отчета идет в час-пик? Почему его нельзя готовить ночью, заранее?
Почему допустим в вашем примере нельзя хранить итоги по дням в отдельной таоблице? Лично я ничего по этому поводу сказать не могу, сидя сдесь в форуме, а не у вас на рабочем месте.
...
Рейтинг: 0 / 0
28.07.2004, 06:45
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624409
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
Дааа понаписали :) Ну объясните мне господа хорошие КАК выделение длинному аналитическому запросу (на OLTP блокировочнике) минимального приоритета ПО ПРОЦЕССОРУ может увеличить пропускную способность системы в целом (по моему это его просто положит). Сырое чтение не предлагать.

2 locky

Хотелось бы услышать пример где Oracle будет долго долго висеть, а MSSQL шустренько и правильно все отработает.
...
Рейтинг: 0 / 0
28.07.2004, 08:13
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624591
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
ну наконец то, итак тюнинг ситуацию не изменит, даже если вам удастся ускорить в 2 раза до 15 минут это не приемлимо. не многие позволить залочить пол базы на 15 минут. дальше если на этот запрос поставить приоритет то он залочит пол базы на гораздо большее время, что смысла вообще не имеет.
Повторяю для вас как и для locky - я указал как минимум 3 направления оптимизации запросов без изменения приоритета. Начиная от самого дешевого до самого дорогостоящего. А вы упорно останавливаетесь на первом(т.е. на анализе плана выполнения).
Да, только один тюнинг плана выполнеия не решит проблему ЛЮБОГО запроса. Но он может решить проблему для КОНКРЕТНОГО запроса. А запрос вытекает из схемы данных. А схема эта с данными размещается на физическом оборудовании. Это все взаимосвязанные вещи.

2 locky
только строчек набабахайте поболее, миллионов эдак... ну 50, хотябы, с распределением по месяцам по 10-12 миллионов.
Такого вида запрос оптимизируется только изменением схемы. Вот несколько вариантов (от простого к сложному)
- добавление столбцов типа int в которых будут занесены отдельно дата и время как смещение от какой-то базовой даты и времени.
- разбиение таблицы на несколько(по месяцам например) и создание секционированного представления
- создание постоянных таблиц с агрегатами, которые могут обновляться периодически или в триггерах базовой таблицы

2killed
Развиваю мысль.
Никакой тюнинг запроса не увеличит производительность CPU, это тоже ограниченный ресурс.
Использование только выставления приоритета запросу тоже не решит проблему производительности. О чем собственно я и говорил. Мне лично такой подход напоминает ситуацию - "давайте включим на машине аварийные огни и все будут понимать что мы едим так медленно потому, что сломаны. И будут нас спокойно обгонять а не материть нас за черепашью скорость". Это конечно вариант, но я лично предпочту поставить такую машину в сервис на комлексную проверку

Теперь я хочу иметь дополнительную степень свободы, не полагаться на шедулер ОС, для которого все процессы равны (одинаковы), а управлять ими, имея знания со стороны приложения. В оракле эта степень свободы есть.
Это особенность Оракла, а не как сказано в теме топика "БОЛЬШОЙ ПЛЮС ORACLE". Еще раз спрошу - вы лично создаете промышленные системы в которых заранее программируете или позволяете пользователю/администратору изменять приоритет посылаемых им запросов ?
...
Рейтинг: 0 / 0
28.07.2004, 10:32
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624699
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nikolay Kulikov
Участник
2Killed.
Я так понял он только CPU и время выполнения ограничивает???
Создание MQT или Materialized View это tuning запроса или нет???
...
Рейтинг: 0 / 0
28.07.2004, 11:22
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624704
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Некоторые способы обходных путей и решений блокировочников по предложенной проблеме. Рассматривается Sybase ASA, который так же является блокировочником, как и MSSQL и во многом схож с ним:
1. есть возможность выставить низкую приоритетность для сессии
2. есть возможность выставления для сессии у оптимизатора запросов режима работы (OLTP или OLAP)
3. оптимизированны сами блокировки, т.е.:
- Для программиста все блокировки в ASA представлены как ROW-LEVEL LOCK (позаписные).
- Для вставок новых записей существуют Insert блокировки, не мешающие чтению существующих записей.
- Для удаленных записей существует опция управления их видимостью (ждать подтверждения их удаления или же при чтении считать, что они удалены и не учитывать их).
- Существует опция управления поведением сессий на блокировки (ждать снятия блокировки или выйти по ошибке из за блокированных записей).
- При чтении записей из таблицы блокируется только текущая на момент чтения запись. После того, как она прочитана, блокировка с нее снимается (для режимов изоляции READ UNCOMMITED / READ COMMITED).
- Есть оператор блокировки всей таблицы (LOCK TABLE), позволяющий на время работы транзакции наложить Table Lock.
- Использование индексов при чтении снижает кол-во блокировок, если изменяемые записи не затрагивают поля в индексе, т.е. не блокируют индекс.
- Существует куча опций управления оптимистичностью блокировок, управления проверками CONSTRAINTS (во время проведения операции или отложенные до COMMIT) и т.д.
4. отработан сам механизм проверок и блокировок: блокировка записей осуществляется параллейно с проверками и BEFORE триггерами, что гарантирует в случае обнаружения невозможности проведения изменения немедленное снятие блокировок и откат транзакции, без необходимости блокирования всего массива изменяемых записей.

К вышесказанному могу сказать, что особых проблем блокировки в ASA не создают, достаточно просто думать головой, выбирать правильный уровень изоляции в зависимости от поставленной задачи, пользоваться временными таблицами, которые никого не блокируют, существуют только внутри сессии (и кстати могут быть как NOT TRANSACTIONAL, что неплохо сказывается на скорости их работы), ну и естественно не держать COMMIT по сто лет. Ну а в отстальном я на 100% согласен с Glory - все решается учетом архитектуры сервера, правильной проектировкой БД и граммотным составлением запросов и тут уже без разницы, что используется - блокировочник или версионник. Имея немного фантазии и не зная основ работы можно тормознуть любой из них, лишь бы желание было :)
...
Рейтинг: 0 / 0
28.07.2004, 11:24
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624722
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
2Glory
>Повторяю для вас как и для locky - я указал как минимум 3 направления оптимизации запросов без изменения приоритета
Пасибо, но я вообще-то рассматривал ситуацию, когда все эти этапы, ессно, пройдены. Честное слово, Glory, мы рассматриваем приоритеты не как панацею от всех болезней, а как последнее средство.
>Такого вида запрос оптимизируется только изменением схемы. Вот несколько вариантов (от простого к сложному)
ну, я так и думал :-)
>- добавление столбцов типа int в которых будут занесены отдельно дата и время как смещение от какой-то базовой даты и времени.
date - поле типа smalldatetime, дата без времени ( а хоть бы и с ним) - разница по скорости не измеряется стандартными средствами.
>- разбиение таблицы на несколько(по месяцам например) и создание секционированного представления
В общем-то так и есть, только деление не по месяцам, а так сказать по периодам активности: относительно свежие данные, с которыми постоянно работают в последнее время и данные за прошлый период. проблема в том что даже запросы по таким секционированным представлениям могут быть весьма и весьма тяжелыми, а большинство отчетов считаются в рамках одного месяца.
>- создание постоянных таблиц с агрегатами, которые могут обновляться периодически или в триггерах базовой таблицы
Для части отчетов это есть,раз в сутки обновляется табличка сводных данных, но как я уже писал, не для всех отчетов я могу предварительно посчитать агрегаты - мало того, что трудно предсказать, что понадобиться, так еще и размер этих агрегатов будет превосходить размер исходной базы.
...
Рейтинг: 0 / 0
28.07.2004, 11:29
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32624753
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
2 locky
2Glory
>Повторяю для вас как и для locky - я указал как минимум 3 направления оптимизации запросов без изменения приоритета
Эта цитата была для killed. Извиняюсь что забыл это указать
...
Рейтинг: 0 / 0
28.07.2004, 11:36
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32625685
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
Glory2 locky
2Glory
>Повторяю для вас как и для locky - я указал как минимум 3 направления оптимизации запросов без изменения приоритета
Эта цитата была для killed. Извиняюсь что забыл это указать

Произошла типичная подмена понятий
Речь шла о возможности выставлять приоритет различным операциям. При чем здесь оптимизация запросов? Выставите приоритет и оптимизируйте на здоровье. Оракл позволяет оптимизировать запросы и при использовании Resource Manager'a и без него. Это совершенно разные вещи.

Если не понятно, то спрошу в лоб. Как в MSSQL можно ограничить деятельность пользователя Васи Пупкина 10% CPU?
...
Рейтинг: 0 / 0
28.07.2004, 16:12
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32625711
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
Nikolay Kulikov2Killed.
Я так понял он только CPU и время выполнения ограничивает???
Создание MQT или Materialized View это tuning запроса или нет???

CPU и степень параллелизма разрешенную пользователю. Время - уже косвенно. Если нужно просто обрубить сессию при достижении лимитов, то это решается без RM.

Создание MV - да, можно в какой-то степени рассматривать как tuning запроса. Но при чем здесь это?
...
Рейтинг: 0 / 0
28.07.2004, 16:19
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32625772
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nikolay Kulikov
Участник
killed CPU и степень параллелизма разрешенную пользователю. Время - уже косвенно. Если нужно просто обрубить сессию при достижении лимитов, то это решается без RM.


А что по поводу ввода вывода и места в журнале????

MQT - MV
Ты читаешь предагрегированные данные и не надо ставить кучу локов твоим отчетом в транзакционной таблице.
...
Рейтинг: 0 / 0
28.07.2004, 16:39
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32625796
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
Nikolay Kulikov killed CPU и степень параллелизма разрешенную пользователю. Время - уже косвенно. Если нужно просто обрубить сессию при достижении лимитов, то это решается без RM.


А что по поводу ввода вывода и места в журнале????

MQT - MV
Ты читаешь предагрегированные данные и не надо ставить кучу локов твоим отчетом в транзакционной таблице.

А что вы хотите знать про ввод-вывод? Места в каком журнале?

Про MV не понял. При чем здесь МV? Нет, ну хотите пользоваться MV в Оракл - ради бога. Речь то про приоретизацию, шедулинг и т.д.
...
Рейтинг: 0 / 0
28.07.2004, 16:46
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32625973
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
killed
Произошла типичная подмена понятий
Речь шла о возможности выставлять приоритет различным операциям. При чем здесь оптимизация запросов? Выставите приоритет и оптимизируйте на здоровье. Оракл позволяет оптимизировать запросы и при использовании Resource Manager'a и без него. Это совершенно разные вещи.


Ну так а кто подменяет понятия то ??? Оргинальная постановка вопроса была "Задание приоритета запросу(!) есть большой плюс Оракла, который позволяет де повысить общую производительность системы давая больше ресурсов частым но легким запросам чем редким и тяжелым"
Так вот мое мнение - что не есть решение проблемы а лишь имитация такого решения (см. пример с машиной и аварйиными огнями)

killed
Если не понятно, то спрошу в лоб. Как в MSSQL можно ограничить деятельность пользователя Васи Пупкина 10% CPU?
Нет, не позволяет. А речь уже идет о пользователе ? Т.е. о всех запросах выполняемых этим пользователем во всех его коннектах ?

В свою очередь спрошу в который раз - что кто-то использует в промышленных системах заранее запрограммированные запросы с пониженным/повышенным приоритетом ?? Или предоставляет пользователю возможность изменить/задать приоритеты отсылаемых им запросов ?
...
Рейтинг: 0 / 0
28.07.2004, 17:43
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32626026
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
>В свою очередь спрошу в который раз - что кто-то использует в промышленных системах заранее запрограммированные запросы с пониженным/повышенным приоритетом ??
я так делаю. Бью отчет на небольшие итеративные части, которые считается в целом медленнее, чем одним запросом. но это дает возможность другим процессам в промежутках поработать.
...
Рейтинг: 0 / 0
28.07.2004, 18:06
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32626087
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Васкецов
Участник
GloryВ свою очередь спрошу в который раз - что кто-то использует в промышленных системах заранее запрограммированные запросы с пониженным/повышенным приоритетом ?? Или предоставляет пользователю возможность изменить/задать приоритеты отсылаемых им запросов ?
Да, для расчета производственной себестоимости
...
Рейтинг: 0 / 0
28.07.2004, 18:55
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32626223
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
Glory killed
Произошла типичная подмена понятий
Речь шла о возможности выставлять приоритет различным операциям. При чем здесь оптимизация запросов? Выставите приоритет и оптимизируйте на здоровье. Оракл позволяет оптимизировать запросы и при использовании Resource Manager'a и без него. Это совершенно разные вещи.


Ну так а кто подменяет понятия то ??? Оргинальная постановка вопроса была "Задание приоритета запросу(!) есть большой плюс Оракла, который позволяет де повысить общую производительность системы давая больше ресурсов частым но легким запросам чем редким и тяжелым"
Так вот мое мнение - что не есть решение проблемы а лишь имитация такого решения (см. пример с машиной и аварйиными огнями)

killed
Если не понятно, то спрошу в лоб. Как в MSSQL можно ограничить деятельность пользователя Васи Пупкина 10% CPU?
Нет, не позволяет. А речь уже идет о пользователе ? Т.е. о всех запросах выполняемых этим пользователем во всех его коннектах ?

В свою очередь спрошу в который раз - что кто-то использует в промышленных системах заранее запрограммированные запросы с пониженным/повышенным приоритетом ?? Или предоставляет пользователю возможность изменить/задать приоритеты отсылаемых им запросов ?

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

Да, речь идет о пользователе, точнее о бизнес-роли, которая отведена этому пользователю.

Пожайлуста пример. Биллинговая система. С одной стороны постоянный обсчет звонков, тарификация, маршрутизация и т.п. Десятки звонков в секунду. С другой стороны, веб-интерфейс. Клиенты компании могут зайти, посмотреть свою статистику.
...
Рейтинг: 0 / 0
28.07.2004, 21:59
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32626237
None0
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
None0
Гость
Вот, вопрос о том, что невозможно ставить приоритеты на запросы - снят. Остались приоритеты задач (процессов - в понятии ОС, сессий - в понятии Оракла). Ну это и так всем понятно. Может и умеет. Оракл опять берет на себя то, что умеет ОС.
...
Рейтинг: 0 / 0
28.07.2004, 22:58
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32626243
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
если не сможете самостоятельно додумать, зачем это сделано в Оракл, обращайтесь, поможем
...
Рейтинг: 0 / 0
28.07.2004, 23:17
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32626627
None0
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
None0
Гость
Если уж у кого и буду спрашивать, то у вас, Киллед, последнего. Вы конечно мужик в "афторитете", но, сдается, с документацией и практикой дружили давно. Ваши теоретические изыскания мне не интересны. Удачи!
...
Рейтинг: 0 / 0
29.07.2004, 11:02
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32626721
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nikolay Kulikov
Участник
2 Killed:
По поводу MQT и MV - Это касалось как получить реальное количество пива на складе не блокируя много строк.

По поводу IO. Например я не хочу что-бы у меня в течении рабочего дня 10:00 до 18:00 не выполнялись транзкакции которые читают более 50000 строк и пользователь не мог отожрать более 10 процентов места активного журнального пространства.

P.S. Приоритизация запросов может потребоваться в Хранилищах данных. Когда у тебя 10 запросов будут читать почти всю базу время выполнения у тебя будет расти очень быстро. Для этого в DB2 например можно указать что в системе может выполняться
не более 1000 запросов с cost < 1000
не более 20 запросов с 1000 < cost < 100 000
не более 2 запросов с соst > 100 000.

Если приходит запрос превышающий эти лимиты он ставится в очередь и выполняетсяв background. А пользователь потом приходит и читает ответ в специально созданой странице.
...
Рейтинг: 0 / 0
29.07.2004, 11:32
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32627015
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EugeneS
Участник
Oracle9i Database Administrator's Guide
Release 2 (9.2)
Part Number A96521-01

What Is the Database Resource Manager?
The main goal of the Database Resource Manager is to give the Oracle database server more control over resource management decisions, thus circumventing problems resulting from inefficient operating system management.

This section contains the following topics:

What Problems Does the Database Resource Manager Address?
How Does the Database Resource Manager Address These Problems?
What are the Elements of the Database Resource Manager?
Understanding Resource Plans
What Problems Does the Database Resource Manager Address?
When database resource allocation decisions are left to the operating system, you may encounter the following problems:

Excessive overhead

Excessive overhead results from operating system context switching between Oracle server processes when the number of server processes is high.

Inefficient scheduling

The operating system deschedules Oracle database servers while they hold latches, which is inefficient.

Inappropriate allocation of resources

The operating system distributes resources equally among all active processes and is unable to prioritize one task over another.

Inability to manage database-specific resources, such as parallel execution servers and active sessions
How Does the Database Resource Manager Address These Problems?
Oracle's Database Resource Manager helps to overcome these problems by allowing the database more control over how machine resources are allocated.

Specifically, using the Database Resource Manager, you can:

Guarantee certain users a minimum amount of processing resources regardless of the load on the system and the number of users
Distribute available processing resources by allocating percentages of CPU time to different users and applications. In a data warehouse, a higher percentage may be given to ROLAP (relational on-line analytical processing) applications than to batch jobs.
Limit the degree of parallelism of any operation performed by members of a group of users
Create an active session pool. This pool consists of a specified maximum number of user sessions allowed to be concurrently active within a group of users. Additional sessions beyond the maximum are queued for execution, but you can specify a timeout period, after which queued jobs will abort.
Allow automatic switching of users from one group to another group based on administrator defined criteria. If a member of a particular group of users creates a session that executes for longer than a specified amount of time, that session can be automatically switched to another group of users with different resource requirements.
Prevent the execution of operations that are estimated to run for a longer time than a predefined limit
Create an undo pool. This pool consists of the amount of undo space that can be consumed in by a group of users.
Configure an instance to use a particular method of allocating resources. You can dynamically change the method, for example, from a daytime setup to a nighttime setup, without having to shut down and restart the instance.
...
Рейтинг: 0 / 0
29.07.2004, 13:11
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32627134
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
None0Если уж у кого и буду спрашивать, то у вас, Киллед, последнего. Вы конечно мужик в "афторитете", но, сдается, с документацией и практикой дружили давно. Ваши теоретические изыскания мне не интересны. Удачи!

Вам бы подумать, как будете рулить приоритетами процессов со стороны ОС , когда Оракл работает в режиме shared server'a. А потом уже про практику, афторитет и прочее.
...
Рейтинг: 0 / 0
29.07.2004, 13:47
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32627166
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EugeneS
Участник
killed None0Если уж у кого и буду спрашивать, то у вас, Киллед, последнего. Вы конечно мужик в "афторитете", но, сдается, с документацией и практикой дружили давно. Ваши теоретические изыскания мне не интересны. Удачи!

Вам бы подумать, как будете рулить приоритетами процессов со стороны ОС , когда Оракл работает в режиме shared server'a. А потом уже про практику, афторитет и прочее.

Оracle не рулит пользовательскими серверными процессами ну просто никак и в доке строго настрого запрещает вмешиваться со стороны ОС в это дело.
...
Рейтинг: 0 / 0
29.07.2004, 13:56
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32627174
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
Nikolay Kulikov2 Killed:
По поводу MQT и MV - Это касалось как получить реальное количество пива на складе не блокируя много строк.

По поводу IO. Например я не хочу что-бы у меня в течении рабочего дня 10:00 до 18:00 не выполнялись транзкакции которые читают более 50000 строк и пользователь не мог отожрать более 10 процентов места активного журнального пространства.

P.S. Приоритизация запросов может потребоваться в Хранилищах данных. Когда у тебя 10 запросов будут читать почти всю базу время выполнения у тебя будет расти очень быстро. Для этого в DB2 например можно указать что в системе может выполняться
не более 1000 запросов с cost < 1000
не более 20 запросов с 1000 < cost < 100 000
не более 2 запросов с соst > 100 000.

Если приходит запрос превышающий эти лимиты он ставится в очередь и выполняетсяв background. А пользователь потом приходит и читает ответ в специально созданой странице.

Про пиво - это не я спрашивал. Поэтому я и не понял.

Про IO. Я DB2 не знаю, хотелось бы уточнить пару моментов.
Как в DB2 можно *заранее* узнать сколько строк читают транзакции? Что будет с большими транзакциями? Они suspended? Что такое активное журнальное пространство в DB2 и как оно соотносится с запросами?

Что такое cost в DB2 ? Это оценки оптимизатора? В каких единицах он измеряется и на каком этапе? Процесс выполняется в background - ему отводятся какие-то лимиты по ресурсам?
...
Рейтинг: 0 / 0
29.07.2004, 14:00
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32627183
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
EugeneS killed None0Если уж у кого и буду спрашивать, то у вас, Киллед, последнего. Вы конечно мужик в "афторитете", но, сдается, с документацией и практикой дружили давно. Ваши теоретические изыскания мне не интересны. Удачи!

Вам бы подумать, как будете рулить приоритетами процессов со стороны ОС , когда Оракл работает в режиме shared server'a. А потом уже про практику, афторитет и прочее.

Оracle не рулит пользовательскими серверными процессами ну просто никак и в доке строго настрого запрещает вмешиваться со стороны ОС в это дело.

а кто спорит?
...
Рейтинг: 0 / 0
29.07.2004, 14:02
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32627277
None0
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
None0
Гость
Да, верно. В shared моде никак.
Но для этого есть Аппликэйшн Сервер. Вот пусть он и тромбует большое кол-во запросов пользователей в маленькое кол-во сессий.
А кстате, комуто известна статистика насколько shared <, > dedicated?
...
Рейтинг: 0 / 0
29.07.2004, 14:32
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32627296
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nikolay Kulikov
Участник
автор
Про IO. Я DB2 не знаю, хотелось бы уточнить пару моментов.
Как в DB2 можно *заранее* узнать сколько строк читают транзакции? Что будет с большими транзакциями? Они suspended? Что такое активное журнальное пространство в DB2 и как оно соотносится с запросами?



Активные журналы в DB2 - это набор файлов в которые пишутся журнальные данные от транзакциях. Максимльный размер этого активного пространства кол-во файлов * на их размер. Когда в файл активные транзакции не пишут он может быть заархивирован. Соответственно можно выставить ограничение для одного пользователя на то сколько места он может отожрать.
Для оракла примерный аналог - место в REDO и UNDO журналах которое моджет быть выделено для одного пользователя.


Заранее это надо смотреть на cost. Но в DB2 2 продукта на данный момент управляею Workload. Cost учитывает DB2 Query Patroller о нем ниже. DB2 Governor он и выставляет лимиты на CPU и количество строк который транзакция может прочитать записать. Периодически этот демон просыпается и смотрит статистику пользователя или приложения. Если не вписываемся в рамки то:
- force the application
- change the application's priority
- change the schedule for the application


автор
Что такое cost в DB2 ? Это оценки оптимизатора? В каких единицах он измеряется и на каком этапе? Процесс выполняется в background - ему отводятся какие-то лимиты по ресурсам?

cost в DB2 - Это оценки оптимизатора. Во внутренних попугаях которые зависят от скорости и количества CPU, производительности дисковой подсистемы вплоть до характеристик диска на котором лежит TS.
Когда процесс перевродится в бэкграунд DB2 Query Patreoller'om - он ждет. Например у нас 3 запрос с cost > 100000. Он ждет пока один из двух работающих закончится. А потом начинает работу. После выполнения запрос сохраняется в таблицу. Имя которой можно найти в warning который DB2 выдало юзеру поставив его в очередь. Напрямую из этой таблицы читает данные и продолжает обработку. Опять же в основном это актуально для ХД.
...
Рейтинг: 0 / 0
29.07.2004, 14:38
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32627318
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
None0Да, верно. В shared моде никак.
Но для этого есть Аппликэйшн Сервер. Вот пусть он и тромбует большое кол-во запросов пользователей в маленькое кол-во сессий.
А кстате, комуто известна статистика насколько shared <, > dedicated?

Можно и так. Только application server - отдельный продукт, отдельные деньги.
Статистика грубо говоря такая, как отношение баз с <, > 1000 пользователей, без учета там специфики для MTS, скажем баз, обслуживающих веб-приложения.
...
Рейтинг: 0 / 0
29.07.2004, 14:43
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32627320
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EugeneS
Участник
None0Да, верно. В shared моде никак.
Но для этого есть Аппликэйшн Сервер. Вот пусть он и тромбует большое кол-во запросов пользователей в маленькое кол-во сессий.
А кстате, комуто известна статистика насколько shared <, > dedicated?

Для трамбовки есть еще Connection Manager
...
Рейтинг: 0 / 0
29.07.2004, 14:43
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32627356
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
а что у дб2 вместо ораклового MTS ? т.е. с помощью чего он вытягивает больше чем 10К сессий ?


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

и что происходит с превысевшей транзакцией ? роллбэк или суспенд ? если суспенд что с блокировками ?
...
Рейтинг: 0 / 0
29.07.2004, 14:54
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32627381
TRON
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
TRON
Гость
killed Glory killed
Произошла типичная подмена понятий
Речь шла о возможности выставлять приоритет различным операциям. При чем здесь оптимизация запросов? Выставите приоритет и оптимизируйте на здоровье. Оракл позволяет оптимизировать запросы и при использовании Resource Manager'a и без него. Это совершенно разные вещи.


Ну так а кто подменяет понятия то ??? Оргинальная постановка вопроса была "Задание приоритета запросу(!) есть большой плюс Оракла, который позволяет де повысить общую производительность системы давая больше ресурсов частым но легким запросам чем редким и тяжелым"
Так вот мое мнение - что не есть решение проблемы а лишь имитация такого решения (см. пример с машиной и аварйиными огнями)

killed
Если не понятно, то спрошу в лоб. Как в MSSQL можно ограничить деятельность пользователя Васи Пупкина 10% CPU?
Нет, не позволяет. А речь уже идет о пользователе ? Т.е. о всех запросах выполняемых этим пользователем во всех его коннектах ?

В свою очередь спрошу в который раз - что кто-то использует в промышленных системах заранее запрограммированные запросы с пониженным/повышенным приоритетом ?? Или предоставляет пользователю возможность изменить/задать приоритеты отсылаемых им запросов ?

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



Вот ведь.. А я почему то уверен был что такое есть... Жаль (абстрактно)...
Развеяли иллюзии...

Тем не менее считаю (абстрактно), что такое было бы полезным...

В конце концов оптимизация запросов - это тоже ресурс, на это надо тратить время, умственные усилия и т.д. Кроме того разговоры "программиста, сочинившего такой неоптимизированный запрос надо выгнать" и т.д. хороши (даже если не брать моральную сторону) для Москвы, СПб и т.д., а для небольших городов это малопрактично (такие советы выдают малодость советчика).

В целом наличие такой возможности сразу резко бы упростило многое (запросы можно конструировать более простыми, к тому же посмотрите сколько времени у вас работает сервер, а сколько sql-сервер - у меня на 1000 ч. работы сервера приходится 30 ч. работы SQL-сервера - однако дорога ложка к обеду. )
...
Рейтинг: 0 / 0
29.07.2004, 15:02
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32627399
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nikolay Kulikov
Участник
MTS - вообще-то вещь внешняя по отношению к БД. Ее как с MS-SQL так и с другими БД использовать можно. В DB2 есть эквивален Connection Manager под названием Connection Concentrator. Так же у IBM есть TXSeries - монитор транзакций.
...
Рейтинг: 0 / 0
29.07.2004, 15:09
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32627478
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
Nikolay Kulikov


автор
Что такое cost в DB2 ? Это оценки оптимизатора? В каких единицах он измеряется и на каком этапе? Процесс выполняется в background - ему отводятся какие-то лимиты по ресурсам?

cost в DB2 - Это оценки оптимизатора. Во внутренних попугаях которые зависят от скорости и количества CPU, производительности дисковой подсистемы вплоть до характеристик диска на котором лежит TS.
Когда процесс перевродится в бэкграунд DB2 Query Patreoller'om - он ждет. Например у нас 3 запрос с cost > 100000. Он ждет пока один из двух работающих закончится. А потом начинает работу. После выполнения запрос сохраняется в таблицу. Имя которой можно найти в warning который DB2 выдало юзеру поставив его в очередь. Напрямую из этой таблицы читает данные и продолжает обработку. Опять же в основном это актуально для ХД.

В целом я понял. А как вы качестве DBA можете соотнести стоимость (в попугаях), кол-во запросов и наконец загрузку CPU ? Например как понять сколько запросов со стоимостью 10000 можно разрешить на конкретной системе? Откуда цифра 10000? Я так понял, это чистый try & use - простой подбор, не более того. И эту схему нужно периодически пересматривать, поскольку объем данных, cost - величины непостоянные?

В целом, насколько я смог понять - это не совсем шедулинг. Получается третий запрос ждет, пока не закончится один из первых двух. Т.е. он ориентирован на окончание запроса, а не на реальную текущую загрузку CPU.
...
Рейтинг: 0 / 0
29.07.2004, 15:33
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32627483
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
Nikolay KulikovMTS - вообще-то вещь внешняя по отношению к БД. Ее как с MS-SQL так и с другими БД использовать можно. В DB2 есть эквивален Connection Manager под названием Connection Concentrator. Так же у IBM есть TXSeries - монитор транзакций.

МTS (multithreded server) - это предыдущее название shared server. От него отказались, чтобы не было путанницы. Извиняюсь, написал MTS по привычке.
...
Рейтинг: 0 / 0
29.07.2004, 15:35
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32627868
Nikolay Kulikov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Nikolay Kulikov
Участник
Есть определенные GUIDE LINE's
...
Рейтинг: 0 / 0
29.07.2004, 17:45
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32628226
Фотография Cat2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Cat2
Модератор форума
locky. О запросе с суммированием по большой базе. Это что? Необходимая оперативная инфа? Юзер сдохнет от того, что не получит ее? Денормализация рулит. С выносом календарных итогов, остатков, ets в отдельные таблы.

Не верю я, что для аналитических отчетов (MS SQL) нельзя поставить NOLOCK для табл. Или грязную изоляцию применить. А дальнейшие тормоза уже только от железа.

Десятистраничный селект. Даю 10 канадских баксов против одного монгольского тугрика, что база спроектирована неправильно.
...
Рейтинг: 0 / 0
29.07.2004, 22:54
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32628586
--------
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
--------
Гость
Cat2locky. О запросе с суммированием по большой базе. Это что? Необходимая оперативная инфа? Юзер сдохнет от того, что не получит ее? Денормализация рулит. С выносом календарных итогов, остатков, ets в отдельные таблы.

Не верю я, что для аналитических отчетов (MS SQL) нельзя поставить NOLOCK для табл. Или грязную изоляцию применить. А дальнейшие тормоза уже только от железа.

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

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

Кто больше ?
...
Рейтинг: 0 / 0
30.07.2004, 09:57
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32628674
Glory
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glory
Участник
Сергей Васкецов
Да, для расчета производственной себестоимости
Хм. Наверное я уже чего-то не понимаю в этой жизни.

killed
Пожайлуста пример. Биллинговая система. С одной стороны постоянный обсчет звонков, тарификация, маршрутизация и т.п. Десятки звонков в секунду. С другой стороны, веб-интерфейс. Клиенты компании могут зайти, посмотреть свою статистику.
И все это в рамках одной базы и одного sql сервера ??? OLTP и OLAP в одном флаконе ??? Извините меня, но вы меня никогда не убедите что должны "жить" вместе. Никакое задание приоритетов не сделает так что olap запрос не будет мешать oltp запросу. Имхо.
А гибридные решения - это желание съэкономить деньги. В таких системах запросто можно заменить встроенную приоритезацию запросов административными методами. Вроде
"с 10.00 до 16.00 работают только операторы ввода данных"
"с 16.00 до 10.00 работают генераторы отчетов"
...
Рейтинг: 0 / 0
30.07.2004, 10:31
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32628872
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
2Cat2
Юзер - не сдохнет, наверное. НО эта цифирь ему нужна, так-шта... Остатки, итоги и все такое - вынесено, фиксируется и всё такое. ранее я писал, однако, что НЕ ВСЕ числа можно посчитать предварительно. Например count(distinct acc) за разные периоды по разным условиям можно посчитать, но объем будет сопоставим с объемом исходной базы, а то и более его.
2Толпа дефисов.
А я даю 30 баксов, что когда я строю аналитический отчет по закрытому периоду и использую NOLOCK - данные будут правильные, т.к. в закрытом периоде ничего не меняется, на то он и закрытый.
2Glory

И все это в рамках одной базы и одного sql сервера ??? OLTP и OLAP в одном флаконе ??? Извините меня, но вы меня никогда не убедите что должны "жить" вместе. Никакое задание приоритетов не сделает так что olap запрос не будет мешать oltp запросу. Имхо.
А гибридные решения - это желание съэкономить деньги. В таких системах запросто можно заменить встроенную приоритезацию запросов административными методами. Вроде
"с 10.00 до 16.00 работают только операторы ввода данных"
"с 16.00 до 10.00 работают генераторы отчетов"

опускаю чисто финансовые вопросы типа покупки сервера для OLAP есть еще и чисто политические - типа как DBA заставит зам директора по экономике считать свои зубодробительные отчеты "с 16.00 до 10.00". Как на мой взгляд, так у DBA может и весу (политического) не хватить. Тем более, что он (DBA) как раз должен обеспечивать нормальное функционирование системы, в которое в т.ч. входит и "доступность информации по требованию".
...
Рейтинг: 0 / 0
30.07.2004, 11:32
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32629151
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
Glory Сергей Васкецов
Да, для расчета производственной себестоимости
Хм. Наверное я уже чего-то не понимаю в этой жизни.

killed
Пожайлуста пример. Биллинговая система. С одной стороны постоянный обсчет звонков, тарификация, маршрутизация и т.п. Десятки звонков в секунду. С другой стороны, веб-интерфейс. Клиенты компании могут зайти, посмотреть свою статистику.
И все это в рамках одной базы и одного sql сервера ??? OLTP и OLAP в одном флаконе ??? Извините меня, но вы меня никогда не убедите что должны "жить" вместе. Никакое задание приоритетов не сделает так что olap запрос не будет мешать oltp запросу. Имхо.
А гибридные решения - это желание съэкономить деньги. В таких системах запросто можно заменить встроенную приоритезацию запросов административными методами. Вроде
"с 10.00 до 16.00 работают только операторы ввода данных"
"с 16.00 до 10.00 работают генераторы отчетов"

Ну я убеждать целью не ставлю. Статистика в той системе далеко не OLAP. Просто пользователь может ворошить свои звонки за несколько прошлых месяцев. Теперь "должны/не должны" определяется бюджетом в каждом конкретном случае с учетом еще кучи причин. Реалии - они как бы сильно оторваны от учебников. Кстати гибридных систем в мире подавляющее большинство. Приоритезацию с помощью административных методов я не буду комментировать. Это примерно тоже, что форматирование дискетки в Виндовс 98.
...
Рейтинг: 0 / 0
30.07.2004, 12:43
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32629344
Фотография Сергей Васкецов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Васкецов
Участник
Glory Сергей Васкецов
Да, для расчета производственной себестоимости
OLTP и OLAP в одном флаконе ???
Понимаете, расчет себестоимости - не обязательно отчет, то есть, это не OLAP в чистом виде, например, по результатам расчета может осуществляться ввод документов прихода ГП, резервирования, планирования, генерация проводок или ее аналоги. Это уже вовсе никакой не OLAP.
...
Рейтинг: 0 / 0
30.07.2004, 13:43
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32630265
Фотография Сергей Тихонов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Тихонов
Участник
lockyдавайте попробуем оптимизировать запрос вида
Код: 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 строкПроще паренной репы ;-) Материализованные виды рулят в данном случае...
Теперь далее: если у вас запрос не укладывается в 600 секунд, значит:
1. Плохо спроектирована БД (таблицы, индексы, расположение на дисках и т.д.) - тут понятно, куда смотреть надо ;-).
2. Плохой алгоритм (если это не 1 запрос) - говорить о том, что ситуацию надо менять установкой приоритетов потоков ОС - пошло. Какой же вы программист, если не можете переработать алгоритм...
3. Недостаточно системных ресурсов. Ну извините - планируйте ваши тяжелые запросы на peak-off hours.
4. Используйте OLAP. Даже в случае бедности и использования одного сервера вы получите значительный эффект. Кубы вы ведь не будете процессить во время пиковой нагрузки на сервере, если нет - то это к врачу...
5. Используйте "очередь сообщений". В MSSQL 2000 ее можно делать своими руками, в Yukon`е будет уже встроенная (кстати, а как там у Оракла в этом смысле?).
6. В MSSQL есть такие параметры, как cost threshold for parallelism и max degree of parallelism - очень действенный способ не отдавать вес ресурс одному запросу. А работать с приоритетами для задач - не, ИМХО фигня это. Решать за СУБД, как ей потоки распределять - дело неблагодарное...

Теперь по поводу бедности. В большинстве случаев на самом деле речь идет о том, что руководство не понимает того, во сколько выльются простои, связанные с недоступностью КИС: в данном случае это и тормоза при работе юзеров, и падение серверов / баз, и т.д. Вы просто предложите руководству посчитать, во сколько обойдется пол-дня простоя сервера БД. Когда вы учтете затраты на работу персонала, неудовлетворенность клиентов, недополученную прибыль и т.д., вы поймете, что нормальное аппаратное обеспечение - это норма жизни. А читать про то, что блок питания не потянет еще плюс 1 HDD - просто смешно...
...
Рейтинг: 0 / 0
30.07.2004, 23:35
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32630430
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
>Проще паренной репы ;-) Материализованные виды рулят в данном случае...
угу.. токо на поддержку материадизованных вьюшек ресурсы тратяться постоянно, а запрос так, от времени к времени...
>Теперь далее: если у вас запрос не укладывается в 600 секунд, значит:
>1. Плохо спроектирована БД (таблицы, индексы, расположение на дисках и т.д.) - тут понятно, куда смотреть надо ;-).
дык в запросе таблица одна, ограничение одное, кластерный индекс по дату - куда проще.
Тем более Вы мыслите как программист - если что-то плохо - я это переделаю! А я мыслю как DBA - у меня есть купленная система, которую я НЕ ИМЕЮ ПРАВА (да и желания - это не моя работа) переделывать. А вот настройку сервера - могу, аднака....
>2. Плохой алгоритм (если это не 1 запрос) - говорить о том, что ситуацию надо менять установкой приоритетов потоков ОС - пошло. Какой же вы программист, если не можете переработать алгоритм...
Алгоритм - вроде как бы нормальный, конечно, несколько сложнее - там есть еще один джойн, но индексы нужные есть.
>3. Недостаточно системных ресурсов. Ну извините - планируйте ваши тяжелые запросы на peak-off hours.
да, ресурсов недостаточно. а планирование - я уже просил рассказать мне, как DBA можеть порекомендовать начальнику, когда он должен работать с системой :-)
>4. Используйте OLAP. Даже в случае бедности и использования одного сервера вы получите значительный эффект. Кубы вы ведь не будете процессить во время пиковой нагрузки на сервере, если нет - то это к врачу...
Вот тут - не скажу, не пробовал, хотя и думал. однако использование OLAP тут-же предполагает его изучение. будут за это платить - вопрос еще тот.
>5. Используйте "очередь сообщений". В MSSQL 2000 ее можно делать своими руками, в Yukon`е будет уже встроенная (кстати, а как там у Оракла в этом смысле?).
Не в курсе, что это такое, надо посмотреть. Ссылочку предложите?
>6. В MSSQL есть такие параметры, как cost threshold for parallelism и max degree of parallelism - очень действенный способ не отдавать вес ресурс одному запросу.
Угу, и maxdop стоит в 1 - из за некого глюка, при котором SQL неправильно считает суммы :-( однако наибольшая нагрузка ложится не на камни, а на ДПС, так шта...
>А работать с приоритетами для задач - не, ИМХО фигня это. Решать за СУБД, как ей потоки распределять - дело неблагодарное...
Однако, я могу решать, сколько камней использовать для запроса (option maxdop), какие индексы юзать(with index=) и в каком порядке связывать(option force order) таблицы, да и каким образом (loop|merge|hash join). я могу сказать приоритет для deadlock'а (SET DEADLOCK_PRIORITY), в какой-то мере управлять перекомпиляцией (keep plan, keepfixed plan, exec with recompile).... могу еще коем-чем управлять...
почему вызывает такое удивление, когда я хочу управлять еще одним параметром системы? В конце концов, ораклоиды то тоже не дураки были, когда ввели приоритеты... да, теоретически неправильно их использовать, а вот на практике....
Давайте чуток вспомним: SQL - декларативный язык, он определяет ЧТО делать. а КАК делать - решает оптмизатор и иже с ними. С этой точки зрения все наши указания индексов, порядка соединений и т.д. - глупости чистой воды, но мы их используем и как-то не особо по этому поводу напрягаемся.
автор
Теперь по поводу бедности. В большинстве случаев на самом деле речь идет о том, что руководство не понимает того, во сколько выльются простои, связанные с недоступностью КИС: в данном случае это и тормоза при работе юзеров, и падение серверов / баз, и т.д. Вы просто предложите руководству посчитать, во сколько обойдется пол-дня простоя сервера БД. Когда вы учтете затраты на работу персонала, неудовлетворенность клиентов, недополученную прибыль и т.д., вы поймете, что нормальное аппаратное обеспечение - это норма жизни.

А ни во сколько простой в один день не обойдется. прибыль не зависит от того, будет КИС в этот день работать или не будет. И удовлетворенность клиентов зависит по большому счету от работы канализационной сети, а не от того, смогли они сегодня справку получить, или нет. Тем более, что справку они получат, правда, за чуть большее время. вместо 3-х минут будет 5, но для одного чела это несущественно.
>А читать про то, что блок питания не потянет еще плюс 1 HDD - просто
смешно...
аха, давайте посмеемся вместе.... БП уже работает с перегрузкой, потому как тянет на 2 винта больше, чем полагалось по расчету, и напруга в нем проседает с завилным постоянством. бум продолжать спорить?
Да, так о чем это мы?
А о том, что еще одна настройка сервера - вещь очень нужная и полезная. И не надо кричать: "Вы ЭТИМ можете поранится, мы Вам ЭТО не дадим!" Мы взрослые умные (:-) ) люди, мы можем поранится чем угодно! Но мы постараемся этого не сделать. Так шта, хде наш инстрУмент?
...
Рейтинг: 0 / 0
31.07.2004, 16:54
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32630558
Guest_2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guest_2
Гость
Напомню с чего по сути все собственно и началось.
Locky2Guest_2
>Устранить проблему - значит переписать запрос. Этим и надо заниматься. Рано или поздно Вам все равно придется это сделать.
давайте попробуем оптимизировать запрос вида
Код: plaintext
1.
2.
select Date,Sum(Summ),Sum(Vol),Max(Amount)
from DocDebet
where Date >= @df and Date < @dtgroup by Date
где мощность таблицы DocDebet ~2*10^8, под условие отбора попадает ~12*10^6 строк.

Вот судя по этому
LockyА я мыслю как DBA - у меня есть купленная система, которую я НЕ ИМЕЮ ПРАВА (да и желания - это не моя работа) переделывать.
Вы есть АДМИНИСТРАТОР.
С точки зрения разработчика - действительно этот запрос на указанном Вами множестве будет работать плохо и ничего с ним не поделаешь. Устранить проблему - значит переписать запрос. Этого запроса в вашей системе быть не должно. Уже давались советы по рефакторингу кода системы. Устраивают они вас или нет это другое дело.

Давайте перейдем на точку зрения Администратора.

Вообще-то купленной ИС глубоко все равно, когда вашему Начальнику приспичит запустить отчет для выполнения которого необходимо выполнения приведенного выше запроса. Вообще-то должен быть регламент использования эксплуатируемой ИС. Он либо у Вас в банке есть, либо его нет. И именно в этом документе прописываются все правила и ограничения связанные с получением отчетности. И как мне кажется, Вы как Администратор системы можете и должны поддерживать данный документ в актуальном состоянии.

По поводу техники, на которой крутится база.
ИС опять же глубоко все равно на то, есть ли деньги на замену оборудования или нет. Если для нормальной работы требуются большие аппаратные мощности - они должны быть приобретены. Ваша задача, как Администратора, не дать Начальникам забывать о том, что решение проблемы находится исключительно в их компетенции, а не в Вашей.

Поймите администрирование ИС не заключается только в настройке программно-аппаратного комплекса. Это прежде всего выработка регламента использования ИС и контроль за исполнением этого регламента со стороны пользователей. И тут перед Администратором все пользователи равны, как в бане перед баньщиком все её посетители.

PS. Если у вас Orace и вы используете приоритеты запросов и это Вам помогает в работе, то и слава богу. В любом случа, как мне кажется, это не самый большой плюс по сравнению с MSSQL.
...
Рейтинг: 0 / 0
01.08.2004, 07:52
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32630678
Фотография Сергей Тихонов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Тихонов
Участник
Поддерживаю Guest_2 в плане регламентов и необходимого оборудования.
Теперь далее:
locky>угу.. токо на поддержку материадизованных вьюшек ресурсы тратяться постоянно, а запрос так, от времени к времени...Ну, у вас же не ежедневно эти 10*8 записей добавляются/удаляются/меняются... Вы на самом деле наверняка не пробовали ;-) У MSSQL достаточно хорошие алгоритмы в этом смысле... Ваши юзеры, скорее всего, и не почуствуют, что сервер еще что-то там поддерживает. Начальное построение вьюса - ДА - отнимет много времени.
lockyВот тут - не скажу, не пробовал, хотя и думал. однако использование OLAP тут-же предполагает его изучение. будут за это платить - вопрос еще тот.А вам самому-то неинтересно разобраться с сабжем? Ради любви к искусству? Вы все ради денег делаете?
lockyНе в курсе, что это такое, надо посмотреть. Ссылочку предложите?Предложу. Поищите по ключевым словам SQL Service Broker инфо...
lockyДавайте чуток вспомним: SQL - декларативный язык, он определяет ЧТО делать. а КАК делать - решает оптмизатор и иже с ними. С этой точки зрения все наши указания индексов, порядка соединений и т.д. - глупости чистой воды, но мы их используем и как-то не особо по этому поводу напрягаемся.Я не знаю, как у других, а в моей практике мы хинты используем в 1-2% случаев. У MSSQL достаточно продвинутый оптимизатор и в подавляющем большинстве случаев он строит оптимальный план (если, конечно, с индексами все в порядке...).
lockyА ни во сколько простой в один день не обойдется. прибыль не зависит от того, будет КИС в этот день работать или не будет. И удовлетворенность клиентов зависит по большому счету от работы канализационной сети, а не от того, смогли они сегодня справку получить, или нет. Ага, так нафига оно вам надо, головная боль эта - выкиньте КИС на помойку и забудьте о ней, как о страшном сне. Представьте, как прийдете к боссу и расскажете ему, сколько бабла можно сэкономимь, если работать по старинке без ИС... Гы-гы...
lockyаха, давайте посмеемся вместе.... БП уже работает с перегрузкой, потому как тянет на 2 винта больше, чем полагалось по расчету, и напруга в нем проседает с завилным постоянством. бум продолжать спорить? Ой, я уже так насмеялся, аж за живот держусь ;-)) ... См. пост Guest_2 об аппаратном обеспечении...
...
Рейтинг: 0 / 0
01.08.2004, 19:17
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32631061
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
2Сергей Тихонов
>А вам самому-то неинтересно разобраться с сабжем? Ради любви к искусству? Вы все ради денег делаете?
Очень интересно. Но - только в свободное от основной работы время, изыскав для этого свободное железо. Про литературу, которую надо покупать - не говорю, большую часть инфы можно взять из сети.
автор
Ага, так нафига оно вам надо, головная боль эта - выкиньте КИС на помойку и забудьте о ней, как о страшном сне. Представьте, как прийдете к боссу и расскажете ему, сколько бабла можно сэкономимь, если работать по старинке без ИС... Гы-гы...
Да дело в том, что простой системы в течении одного дня выливается всего лишь в необходимость на следующий день доввести не введенные документы. Конечно, если простой приходится на конец отчетного периода, то нексолько хуже, но абсолютно несмертельно.
автор
Ой, я уже так насмеялся, аж за живот держусь ;-)) ... См. пост Guest_2 об аппаратном обеспечении...
Давайте посмеемся вместе: некоторые проблемы (еще раз повторю, не все) можно было бы решить БЕСПЛАТНО, имей сервер некоторые настройки. А покупка железа - это всегда деньги.
P.S. Как то тут всё уходит на 2-й круг... Начали с того, что фича то-ли полезна, то ли нет, нашли пути, как можно было бы обойтись без неё, упёрлись в то, что для этого необходимо реорганизовывать КИС/железо (что стоит денег), сказали - что да, иногда такая фича полезна, но можно обойтись без неё, но для этого...
Прям как-то заскучал... :-)
...
Рейтинг: 0 / 0
02.08.2004, 11:43
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32631127
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
funikovyuri
Участник
Сергей Тихонов

Я не знаю, как у других, а в моей практике мы хинты используем в 1-2% случаев. У MSSQL достаточно продвинутый оптимизатор и в подавляющем большинстве случаев он строит оптимальный план (если, конечно, с индексами все в порядке...).

Блажен кто верует... Вы случаем MS SQL не продаете? :)
...
Рейтинг: 0 / 0
02.08.2004, 12:02
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32631168
Фотография Сергей Тихонов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Тихонов
Участник
funikovyuri Сергей Тихонов

Я не знаю, как у других, а в моей практике мы хинты используем в 1-2% случаев. У MSSQL достаточно продвинутый оптимизатор и в подавляющем большинстве случаев он строит оптимальный план (если, конечно, с индексами все в порядке...).

Блажен кто верует... Вы случаем MS SQL не продаете? :)
Я не верую, я знаю :-). Знаю, сколько запросов в день проходит на моем сервере БД, какие из них отнимают у сервера больше всего ресурсов, знаю динамику изменения нагрузки за период и т.д.
Нет, случаем, MSSQL НЕ продаю, точно так же, как и Oracle и многое другое (SAP, Documentum, SAS...). Для этого у нас есть туча продавцов-консультантов в компании :-) ...
...
Рейтинг: 0 / 0
02.08.2004, 12:20
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32631407
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
funikovyuri
Участник
Сергей Тихонов

Знаю, сколько запросов в день проходит на моем сервере БД, какие из них отнимают у сервера больше всего ресурсов, знаю динамику изменения нагрузки за период и т.д.

Вы сказали что оптимизатор у MS SQL позволяет обходится без хинтов в 98-99% случаев, выбирая оптимальный план выполнения. К сожалению, такие фразы в большинстве случаев не отражают реальное положение вещей и больше похожи на заявления различного рода продавцов. Про динамику нагрузки я не спрашивал...
...
Рейтинг: 0 / 0
02.08.2004, 13:56
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32631612
Фотография Сергей Тихонов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Тихонов
Участник
funikovyuriВы сказали что оптимизатор у MS SQL позволяет обходится без хинтов в 98-99% случаев, выбирая оптимальный план выполнения. К сожалению, такие фразы в большинстве случаев не отражают реальное положение вещей и больше похожи на заявления различного рода продавцов. Про динамику нагрузки я не спрашивал... Да, так оно и есть, если правильно БД проектировать, правильные индексы строить... Хинты действительно используются очень редко, так что моя фраза - реальное положение вещей ... Так что - низкий поклон разработчикам MSSQL 2000 за их оптимизатор ;-) .
...
Рейтинг: 0 / 0
02.08.2004, 15:05
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32631877
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
автор
Да, так оно и есть, если правильно БД проектировать, правильные индексы строить... Хинты действительно используются очень редко, так что моя фраза - реальное положение вещей... Так что - низкий поклон разработчикам MSSQL 2000 за их оптимизатор ;-) .

Действительно, уже в 7-ке оптимизатор был - о-го-го! Я переходил на 7-ку с 6.5, сразу отметил, что 7-ка влегкую разгребает те запросы, которые на 6.5 долго приходилось тюнить.
и действительно, в 95% случаев оптимизатор лучше тебя знает, как чего делать. Остается еще 5%, которые надо гонять вручную. К примеру, вручную заданый план запроса может быть в 20-25 раз быстрее чем тот, который выбрал оптимизатор.
у меня из всех запросов только для 10-12 штук явно указаны порядок соединения и индексы. но это - базовые запросы нижнего уровня, используются в 50% отчетов. И тут я оказываюсь умнее, чем оптимизатор, хотя и частично умнее. Потому как мои планы не всегда работают самым наилучшим образом. зато они никогда не работают наихудшим образом.
...
Рейтинг: 0 / 0
02.08.2004, 17:02
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32700508
wellx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
wellx
Участник
Судя по постам ваша проблема может быть решена ТОЛЬКО покупкой второго сервера , причем можно их самых дешевых. На него ставите второй MSSQL , и настраиваете репликацию по ночам на второй сервер. НА него переводите всех кому нужны длинные и долгие отчеты , пусть ждут их хоть до ночи, а оперативные данные вгоняют в основную базу. Лицензия потребуется только на сервер и SQL без юзеров . Заодно всегда будет копия базы на вчера вечером. Вторую базу можно
сделать read-only для ускорения работы , но это уж как вам виднее...

А экономить при таких проблемах - как минимум путь к увольнению/банкротству.
...
Рейтинг: 0 / 0
17.09.2004, 18:58
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32700572
Зл0й
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зл0й
Участник
По поводу плюсов Оракла, не могу не высказаться - родная СУБД все-таки :)

Значится так. Я неоднократно встречал задачи, типа приведенной выше из ERP, перестройка справочника с одновременным выполнением очетов. Если абстрагироваться от специфики конкретной задачи, то имеются следующие требования:
- мы изменяем данные в таблице или группе таблиц
- мы одновременно читаем данные из этой таблицы/группы таблиц
- требуется обеспечить согласованное чтение, грязное чтение не допускается (некорректные отчеты нам не нужны)
- длительное ожидание на блокировке для "писателей" однозначно недопустимо
- длительное ожидание на блокировке для "читателей" допустимо, но не желательно.

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

В СУБД имеющих MVCC (версионниках) таких как Oracle, есть неблокирующее согласованное чтение. Поскольку оно неблокирующее, то писателям оно никак не мешает. Если интересно как оно работает - при изменении данных старая версия сохраняется. Допустим при "долгоиграющей" читающей транзакции мы наткнулись на запись которая была изменена "писателями" после начала читающей транзакции. В этом случае "читатель" получит данные существовавие в базе на момент начала читающей транзакции (или сообщение об ошибке ORA-01555). Поскольку дисковые массивы и контроллеры нынче недороги, проблема читателей-писателей, относительно легко решается выделением достаточного места (и пропускной способности дисковой подсистемы) под "старые версии данных". Называется это хозяйство rollback (undo) segment.

В случе если объем читающих-пишущих транзакций таков, что система просто с ними не справляется, в Оракле делается вот какой трюк:

Заводим hot standby database, это такая база куда наша основная БД будет логи присылать. Потом открываем этот standby в режиме "только чтение". И гоняем наши отчеты на этом standby. Задержка будет, но небольшая (полчасика, или минут 15) и регулируемая администратором.

В мелкософте, насколько мне известно, возможности иметь hot standby database открытую на чтение нет. Но я не великий спец по MSSQL, так что поправьте меня, если что.
...
Рейтинг: 0 / 0
17.09.2004, 20:33
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32700664
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
авторВ СУБД-блокировщиках способ обеспечения согласованного чтения один - при чтении устанавливается блокировка, предотвращающая изменение данных, которая снимается только по окончании операции чтения. В противном случае имеем "грязное" (несогласованное) чтение. Соответственно как только "читатель" заблокировал данные для генерации отчетов, то "писатели" курят бамбук, пока не будет снята блокировка. Поскольку блокировка "писателей" однозначно недопустима, то нам остается разрешать грязное (неблокирующее) чтение и ошибки в отчетах.
Вы уж меня извините, но познания о блокировочниках у Вас мягко говоря слабоватые. Вообще то основным источником блокировок как раз являются писатели, а не читатели, писатели удерживают измененные записи в блокированном состоянии до подтверждения транзакции, а читатели, если эти записи попадают под условия запроса, просто стоят и ждут, пока писатели с них снимут блокировки. То что оказывается по Вашему мнению читатели вот так вот "притесняют" бедных писателей для меня честно говоря было полной неожиданностью. Что я могу сказать на примере ASA по поводу блокировок читателями:
1. Блокировки читателями ставяться только на время выполнения запроса, далее до COMMIT висит только SHARE-блокировка, запрещающая изменение метаструктуры задействованных в запросе таблиц.
2. СУБД для читателей полностью блокирует все записи до окончания выполнении запроса только для уровня изоляции SERIALIZABLE или же когда жестко в запросе указан хинт XLOCK. Для READ COMMITED (которого обычно вполне достаточно для отчетов) блокируется только текущая обрабатываемая запись при выполнении запроса, с которой тут же снимается блокировка, как только СУБД переходит сканом на следующую обрабатываемую запись.
3. В случаях использования индекса на таблицу при подходящих условиях (то есть когда чтения индекса достаточно и чтение таблицы не требуется) оптимизатор вполне может не накладывать блокировку на таблицу, обойдясь блокировкой анти-вставки на текущую запись индекса, таким образом блокируя только момент вставки между текущей и следующей записью новой на время чтения позиции индекса.
4. Если оптимизатор видит, что эффективнее построить хэш или рабочую таблицу, то он вообще может обойтись без блокировок.
5. Стоит упомянуть многочисленные опциях, регулирующие поведение СУБД в различных ситуациях и для различных уровней изоляций, с помощью которых можно довольно много - от игнорирования в READ COMMITED удаленных, но еще незавершенных транзакцией данных, до переноса до COMMIT проведения всех проверок целостности данных, что например, позволяет эффективно в таблицы грузить и изменять деревья, а главное не блокировать во время проведения транзакции ключи родительских таблиц при добавлении записей в дочерние и делать это потом одной операцией, таким образом сведя время блокировок к минимуму. Плюс разные виды накладываемых блокировок - оптимистические и пессиместические, которыми тоже можно много чего разрулить.
6. Ну и наконец, никто нам не мешает ручками разруливать ситуации с блокировками, граммотно писать запросы, не делать длинные по времени транзакции, переносить и рассчитывать данные во временные таблицы, которые никого и никогда не блокируют, по назначению использовать уровни изоляции и различные виды курсоров.

P.S. В общем мне кажется было бы довольно необоснованно говорить, что Оракл круче MSSQL или ASA именно тем, что они блокировочники, а он версионник. У каждого продукта свои достоинства и недостатки, у каждого свои превосходные и удобные плюсы и свой геммор, за который бы хотелось поубивать их разработчиков.
...
Рейтинг: 0 / 0
17.09.2004, 23:33
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32700673
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
Код: plaintext
Заводим hot standby database, это такая база куда наша основная БД будет логи присылать. Потом открываем этот standby в режиме "только чтение". И гоняем наши отчеты на этом standby. Задержка будет, но небольшая (полчасика, или минут  15 ) и регулируемая администратором.

Маленькое дополнение.
9i and upward - можно до нуля свести. Правда если на это идут то по другим причинам
...
Рейтинг: 0 / 0
18.09.2004, 00:01
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32700716
Зл0й
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зл0й
Участник
Когда я говорил о том, что читатели блокируют писателей, естественно речь шла об уровне изоляции транзакций Serializable. Ясен пень, что при Read Commited читатели писателей не блокируют (изменения структуры таблицы я не рассматриваю) а писатели блокируют читателей на время выполнения пишущей транзакции. Какие неприятности бывают при уровне изоляции Read Commited хорошо известно. Хрестоматийтый пример разбирался на sql.ru неоднократно. Грубо - у клиента 2 счета, чековый и сберегательный. Мы считаем баланс по группе клиентов. Мы начали читать таблицу, прочитали баланс на сберегательном счете в 1000 рублей. Затем прошла транзакция переводящая со сберегательного счета на чековый 500 рублей. Затем мы прочитали баланс чекового счета в 500 рублей. Таким образом эти злополучные 500 рублей мы посчитали дважды. И вся любовь. Поэтому с фразой "обычно достаточно Read Commited" я весь несогласный.

Что до блокировки индекса, не суть важно что мы блокируем индекс или таблицу. Важно что в данном случае, если читатель serializable то "писатели" отдыхают пока читатели не отпустят блокировку. Что недопустимо по условию задачи. Не должен клиент у POS-терминала с кредитной карточкой стоять и ждать пока мы свои отчеты закончим.

Вот поэтому MSSQL/Sybase/Informix/DB2/Teradata не любят долгоиграющие транзакции, особенно на уровне изоляции serializable. Что до транзакций-писателей, то все инструменты для СУБД-блокировщиках по умолчанию работают в режиме autocommit. И в книжках по СУБД-блокировщикам рекомендуется транзакции делать коротенькие, и commit делать почаще. Все это - не от хорошей жизни. В Оракле commit делается тогда когда этого требует логика приложения, а не когда этого хочет СУБД. И это правильно.

Уважаемый ASCRUS привел целый ряд способов которыми можно выкрутиться если СУБД-блокировщик. Как правило приходится либо жертвовать согласованностью данных (использовать Read commited вместо serializable) либо соглашаться на то что пишущая транзакция может завершиться с ошибкой. То есть она итак может звершиться с ошибкой, мы лишь увеличиваем вероятность такого завершения.

Поэтому, ИМХО СУБД-блокировщики имеют ряд ограничений, и плохо подходят для решения определенного класса задач, типа изложенной выше. СУБД-версионник лучше подходит для этих задач. Я просто сторонник той теории что суп удобнее хлебать ложкой, а салат есть - вилкой, а не наоборот. Возможно в природе есть задачи которые лучше решаются блокировщиком чем версионником. Я их пока не встречал. Приводите такую задачу - буду признателен. Хотя нет, вру. Teradata - злобный блокировщик, рулит в больших хранилищах данных. Там конкуренции между читателями и писателями обычно нет. И Teradata превосходит Оракл она не потому что она "блокировщик" а потому что помогает звериная мощь MPP-архитектуры.
...
Рейтинг: 0 / 0
18.09.2004, 03:51
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32700766
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Зл0йХрестоматийтый пример разбирался на sql.ru неоднократно. Грубо - у клиента 2 счета, чековый и сберегательный. Мы считаем баланс по группе клиентов. Мы начали читать таблицу, прочитали баланс на сберегательном счете в 1000 рублей. Затем прошла транзакция переводящая со сберегательного счета на чековый 500 рублей. Затем мы прочитали баланс чекового счета в 500 рублей. Таким образом эти злополучные 500 рублей мы посчитали дважды. И вся любовь. Поэтому с фразой "обычно достаточно Read Commited" я весь несогласный.
А зачем "затем, затем, затем" ? Почему бы не "сразу". Читаем одним запросом по группе клиентов баланс для сберегательного и чекового счета, соотвествующе при переборе клиентов записи в счетах блокируется по одной на текущего обрабатываемого клиента, далее разблокируются и писатели уже могут спокойно изменять тех клиентов, которые уже прошли в запросе. Далее результат запроса выкидываем клиентскому приложению или во времянку для дальнейшей обработки - это уже как по логике нужно.

Зл0йЧто до блокировки индекса, не суть важно что мы блокируем индекс или таблицу. Важно что в данном случае, если читатель serializable то "писатели" отдыхают пока читатели не отпустят блокировку. Что недопустимо по условию задачи. Не должен клиент у POS-терминала с кредитной карточкой стоять и ждать пока мы свои отчеты закончим.

С учетом вышесказанного и избавляясь от serializable, мы получаем, что клиент и не будет ждать - данные то он там новые вводит, а значит по логике они не должны на этот момент входить на обрабатываемые читателями данные (например в условие входит, что на записи, занесенные ранее текущего времени), так что читатели могут блокировать то, что существует на момент выполнения запроса, а писатели продолжать добавлять записи.

авторУважаемый ASCRUS привел целый ряд способов которыми можно выкрутиться если СУБД-блокировщик. Как правило приходится либо жертвовать согласованностью данных (использовать Read commited вместо serializable) либо соглашаться на то что пишущая транзакция может завершиться с ошибкой. То есть она итак может звершиться с ошибкой, мы лишь увеличиваем вероятность такого завершения.
Да нет же, я привел целый ряд моментов, которые изначально нужно учитывать при проектировании БД и тогда не будет возникать различных проблем, которые Вы тут привели. То есть, если человек привык проектировать БД на Оракле и начнет делать ее на том же MSSQL, то сделает он все так как привык делать, а потом будет долго возмущаться - вот какие блокировочники плохие, блокировками достали. Однако я более чем уверен, что если человек, прекрасно знающий MSSQL впервой сделает БД на Оракле, то ругани в сторону версионников и Оракла конкретно будет не меньше.

авторПоэтому, ИМХО СУБД-блокировщики имеют ряд ограничений, и плохо подходят для решения определенного класса задач, типа изложенной выше. СУБД-версионник лучше подходит для этих задач. Я просто сторонник той теории что суп удобнее хлебать ложкой, а салат есть - вилкой, а не наоборот. Возможно в природе есть задачи которые лучше решаются блокировщиком чем версионником. Я их пока не встречал. Приводите такую задачу - буду признателен.
Поэтому IMHO любая задача будет решена лучше на блокировочнике, чем на версионнике, если на блокировочнике ее будет решать специалист, у которого уровень знаний и опыт больше, чем у специалиста, делающего это на версионнике. То же самое можно сказать наоборот. И все - никаких филосовских рассуждений о достоинствах и недостатках разных СУБД, такой вот я прагматик :)
...
Рейтинг: 0 / 0
18.09.2004, 11:06
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32701608
-------------
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
-------------
Участник
Зл0йВ мелкософте, насколько мне известно, возможности иметь hot standby database открытую на чтение нет. Но я не великий спец по MSSQL, так что поправьте меня, если что. Поправляю - есть и реально используются
...
Рейтинг: 0 / 0
20.09.2004, 10:05
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32705253
Зл0й
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зл0й
Участник
Так, так, насчет избавились от serializable поподробнее.

Дано таблица accounts(acct_number, acct_type, balance) причем большая - много счетов. Имеются две сессии S0 читающая таблицу с уровнем изоляции read commited и S1 изменяющая эту таблицу.

В таблице имеются слкдующие записи
...
12345, Сhecking, 1000.00 -- Чековый счет
...
12345, Savings, 0.00 -- Сберегательный счет
...

Требуется подсчитать суммарный баланс чековых и сберегательных счетов по большой группе клиентов.

Момент времени: сессия: событие
----------------------------------------
T0: S0: началась "долгоиграющая" читающая транзакция. Заблокирована запись с acct_number = 12345 acct_type='Сhecking' затем запись прочитана balance=1000 и блокировка снята - Read commited так работает или нет?
----------------------------------------
T1: S0: Таблица большая, сессия S0 пока читает записи для других клиентов. Предположем что сейчас заблокирован acct_number = 78901

Т1: S1: Запись "12345, Сhecking" уже разблокирована. Запись "12345, Savings" еще не заблокирована. Перебрасываем с чекового счета на сберегательный 500.00 и прибиваем это изменение коммитом.
----------------------------------------
T2: S0: Читаем 12345, Savings, 500.00 Вот оно, "грязное" (несогласованное) чтение.

Таким образом для acct_number = 12345 сумма чекового и сберегательного счетов посчитана 1500.00 а не 1000.00 как должно быть. Все очень просто. Или мы блокируем ВСЕ счета по которым мы считаем суммы, или мы имеем грязное чтение. Третьего не дано.

Возражения?

ЗЫ я не только с Ораклом работал, приходилось работать с Информиксом. Сейчас помимо Оракла работаю с DB2 и Teradata. Так что просьба не рассказывать про достоинства СУБД-блокировщиков, которых на самом деле нет. У них одно преимущество перед Ораклом - меньше i/o жрут, так как при оптимальной реализации им надо меньше undo писАть. Достоинство это ИМХО мало полезное. Чем так страдать, ИМХО проще железяку нормальную поставить.
...
Рейтинг: 0 / 0
21.09.2004, 21:01
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32705282
Зл0й
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зл0й
Участник
Так что уровень изоляции транзакций serializable был не просто так придуман, а чтобы не было аномалий типа вышеприведенной. Некоторые авторы называют ее phantom read, я же просто обозвал ее diry read. По мне все что не consistent, то dirty.
...
Рейтинг: 0 / 0
21.09.2004, 21:51
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32705285
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
А ЗлОй во многом прав. А ASCRUS не догонят немного. (без обид ?)
Только одного не понимаю, с какой радости Oracle версионником стал.
Я, конечно, не сильно в курсе, но на сколько я знаю, данные для "старых" транзакций он берет из т.н. сегмента отката , а он у него не резиновый, хоть может быть и большим. А вот если там уже данных нет тогда КААК ....

Я прав или нет ?
Да, и насчет ПО СРАВНЕНИЮ С MSSQL - ну сделают и в MS такую ж фичу в Yukonе - ну и ?
...
Рейтинг: 0 / 0
21.09.2004, 21:54
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32705358
Зл0й
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зл0й
Участник
Oracle версионник, хотя и весьма своеобразный. Данные действительно берутся из сегментов отката (rollback segment он же undo segment). СУБД сама по себе не гарантирует что они там будут. Если данных в оном сегменте нетути, вылезает ошибка ORA-01555 "Snapshot too old". Борются с этим вот как путем создания сегментов отката адекватных решаемой задаче. И еще commit стараются без нужды не делать, так как он помечает старые данные в сегменте отката как "свободное место куда можно писАть".

Есть другие способы хранить старые версии данных, например можно при update писать данные в новую страницу как в PostGreSql. Тогда возникает проблема сборки мусора. Да и производительность получается так себе. Можно писАть старые версии в лог, потом их оттуда читать. Проблема в том, что лог обычно имеет структуру оптимизированную под запись. Восстановление по логам происходит не очень часто, так что они не оптимизированы на чтение. Если механизм версий будет читать данные из логов, сдается мне что производительность будет весьма паршивая. ИМХО Оракловое решение с сегментами отката - разумный компромисс.

Из коммерческих СУБД версионники Оракл и Интэрбэйс. Как MVCC сделано в Интербэйсе я не знаю, надо спросить в профильной конфе. Из оупенсорсных СУБД MySQL пытается идти по стопам Оракла, пока без особого успеха. В PostGreSql ИМХО механизм версий сделан ИМХО крайне неудачно.

Соответсвенно вопрос, если Оракл - не версионник, тогда кто тогда версионник? А что будет в Юконе - мы поглядим когда его сделают. Помнится Сайбэйс тоже когда-то обещал блокировку на уровне записи. Обещанного три года ждут. В случае с Сайбэйсом даже дольше.

По поводу hot backup. А разве в MSSQL можно в онлайне логи присылать на standby базу которая открыта на чтение? Не знал.
...
Рейтинг: 0 / 0
22.09.2004, 01:48
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32705388
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Ну не все так плохо :) Буду немножко врать, так как не работал в банковских технологиях, но постараюсь суть передать верно :)

Итак ситуация первая
Есть таблица "движения денег по счетам". Любая операция перевода денег со счета на счет фиксируется новой записью в этой таблице, тут насколько я понимаю операций удаления и изменения записей практически нет. А значит, мы можем прекрасно организовать работу с этой таблицой как читателей, так и писателей, просто добавив в нее колонку TIMESTAMP и учитывая в запросах условие TIMESTAMP <= Now() . Тогда любой запрос в READ COMMITED по этой таблице будет учитывать только те данные, которые существовали на момент его выполнения и таким образом движения по счетам, возникающие после выполнения запроса будут добавляться уже как записи с более поздним временем и писатели, вставляя новые записи не будут мешать читателям, а те не будут лезть на даже закоммиченные, но более поздние данные. Здесь я думаю все понятно и особо спорить не о чем.

Ситуация вторая
Движение по счетам это хорошо, но долго, хотелось бы иметь текущий баланс по счетам каждого клиента, который автоматически бы перерасчитывался на триггерах при движении денег по вышеприведенной таблице.

Что же - идея здравая, ни кому не хочется поднимать многолетний архив, чтобы быстро получить баланс клиента, так что делаем табличку "баланс". Если бы счета хранились как колонки в записи, конечно бы проблем не возникало при построении аналитических запросов и на READ COMMITED - СУБД блокировало бы текущую запись вместе со всеми счетами, разблокировала ее и дальше продолжала обработку, а писатель, т.е. в данном случае триггер с таблицы движения денег по счетам, ждал бы микроскопическое время, если уж ему приспичело именно в этот момент изменить состояние счета. Однако такое решение естественно не подходит, так как счетов может быть сколько душе угодно. Как итог - в таблице множество записей по балансу клиента на каждый счет и как было правильно замечено READ COMMITED тут не прокатывает, без уровня изоляции SERIALIZABLE, который фактически сначала блокирует все обрабатываемые записи в таблице баланса и только потом начинает выполнение запроса не обойтись.

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

Немножко пофантазируем
Например, сделаем в табличке баланса еще поле TIMESTAMP, чтобы мы знали, когда последний раз был посчитан баланс (это всегда пригодиться).

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

Теперь осталось навести красоту - все таки пересчитать баланс, благо кого считать и зачем мы уже знаем. Делаем EVENT (событие), ставим ему тип SCHEDULE (по времени) и назначаем выполняться через каждое, оптимальное с нашей точки зрения время (например с частотой раз в минуту). В тело события пишем скрипт, который фиксирует в переменной текущее время и уже по ней выполняет перерасчет баланса для всех записей, имеющих меньшее или равное значению переменной время. Далее после выполнения операции нам остается честно удалить с буфера опять же по времени обработанные записи и сделать COMMIT. Ну и естественно в случае возникновения каких либо ошибок произведенный ROLLBACK вернет на место как и старые значения баланса, так и в состояние необработанных записи в табличке "перерасчет".

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

Проверка
Итак схема готова, давайте ее проверим на приведенном примере достоинства Оракла перед блокировочниками.
Зл0й
Момент времени: сессия: событие
----------------------------------------
T0: S0: началась "долгоиграющая" читающая транзакция. Заблокирована запись с acct_number = 12345 acct_type='Сhecking' затем запись прочитана balance=1000 и блокировка снята - Read commited так работает или нет?
----------------------------------------
T1: S0: Таблица большая, сессия S0 пока читает записи для других клиентов. Предположем что сейчас заблокирован acct_number = 78901

Т1: S1: Запись "12345, Сhecking" уже разблокирована. Запись "12345, Savings" еще не заблокирована. Перебрасываем с чекового счета на сберегательный 500.00 и прибиваем это изменение коммитом.
----------------------------------------
T2: S0: Читаем 12345, Savings, 500.00 Вот оно, "грязное" (несогласованное) чтение.

Таким образом для acct_number = 12345 сумма чекового и сберегательного счетов посчитана 1500.00 а не 1000.00 как должно быть. Все очень просто. Или мы блокируем ВСЕ счета по которым мы считаем суммы, или мы имеем грязное чтение. Третьего не дано.

На выполнение сложного аналитического запроса по таблице "баланса" ставим уровень изоляции SERIALIZABLE, чтобы в любом случае обеспечить "чистое чтение" данных" (если запрос обхватывает всю таблицу, то можно просто выполнить LOCK TABLE, будет быстрее, эффективнее и вообще не будет кушать ресурсов, в отличие от типа блокировки ROWLOCK, с которой работает ASA).

Итак ход событий:

1. началась "долгоиграющая" читающая транзакция по таблице "баланс". Заблокированы все обрабатываемые данные для любых писателей.

2. во время обработки этой транзакции писатели продолжают писать данные в таблицу "движение по счетам". Это приводит к следующим действиям:
2.1 вызывается триггер
2.2 из него добавленные записи добавляются в таблицу "перерасчет"
2.3 заканчивается действие триггера
2.4 писатели делают COMMIT и заканчивают транзакцию добавления записей

3. пришло время срабатывания события перерасчета баланса. в случае, когда для перерасчета есть данные, то оно пытается записать данные в табличку "баланс" и если натыкается на блокировки, зависает до их освобождения. таймер замараживается и это событие еще раз не вызывается по нему, пока не будет завершено текущее

4. читающая транзакция завершает работу и делает COMMIT

5. событие записывает обновленные нужные данные в таблицу "баланс", очищает в табличке "перерасчет" все обработанные ею записи, делает COMMIT и выходит, таким образом снова автоматически заводя таймер на свой запуск.

P.S. Таким образом используя таблицу-буфер, TIMESTAMP и механизм событий в ASA мы получаем не сложный в реализации, надежный, простой и не занимающий лишних ресурсов механизм разруливания ситуаций с высоким уровнем блокировок. Соответствующе я еще раз хочу подчеркнуть, что тут все зависит как от возможностей СУБД, так и от знаний специалиста и на любую поставленную задачу можно найти адекватное и красивое решение.

авторВозражения?

ЗЫ я не только с Ораклом работал, приходилось работать с Информиксом. Сейчас помимо Оракла работаю с DB2 и Teradata. Так что просьба не рассказывать про достоинства СУБД-блокировщиков, которых на самом деле нет. У них одно преимущество перед Ораклом - меньше i/o жрут, так как при оптимальной реализации им надо меньше undo писАть. Достоинство это ИМХО мало полезное. Чем так страдать, ИМХО проще железяку нормальную поставить.
Все вышесказанное - это и есть мои возражения. Причем пример я давал на Sybase ASA, но почти такой же механизм будет работать и на MSSQL. Мне лично легче еще одну табличку влепить, чем мотивировать клиенту покупку "нормальной" железяки, содержания штата админов и других "тяжелых" расходов. А блокировочники действительно к ресурсам не падкие и со скоростью у них все в порядке, так что это и есть их сильные и конкурентноспособные качества, главное помнить о палке о 2-х концах и уметь пользоваться достоинствами и обходить недостатки.

Будут ли у Вас возражения по вышеизложенному тексту ?
...
Рейтинг: 0 / 0
22.09.2004, 02:27
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32705394
Зл0й
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зл0й
Участник
Уважаемый ASCRUS, то что вы расписали есть по сути попытка реализации чего-то подобного механизму версий, но на СУБД-блокировщике. Грубо говоря, попытка сделать то же что и Оракл, только "ручками". Возражения такие:
- пример был приведен очень сильно упрощенный, чтобы проиллюстрировать проблему. Ито, решение на блокировщике вышло громоздкое. Реальная задача гораздо сложнее. Будем городить или ну его нафиг?
- Зачем городить доморощенный механизм-версионник когда есть готовый? Я конечно понимаю, что изобретение велосипеда это наш российский национальный вид спорта.

В общем, на уровне идеи, ваше предложение выглядит так: временно хранить часть данных в какой-то структуре независимой от механизма управления транзакциями СУБД. Управлять транзакциями "вручную" или в обход "родных" для СУБД механизмов.

Я видел немало разных механизмов позволяющих "обходить" механизм управления транзакциями. Например в оракле можно хранить данные в очередях сообщений, пайпах и в структурах данных в пакетах хранимых процедур. Фундаментальный недостаток всех этих решений - управление транзациями "вручную". Даже самая простенькая задачка превращается в сущий кошмар, как только мы храним состояние где-то, где оно может "пережить" rollback. Где-нибудь, что-нибудь да поломается. Например что будет с данными в случае аварии сервера? События теряются? Будем собственные логи писать?

Трудозатраты на корректную реализацию таких решений многократно превыщают стоимость железа. Ибо задача которую мы беремся решать в данном случае - написание "poor man's Tuxedo" или "poor man's Oracle", как угодно. По сути мы пишем примитивный доморощенный монитор транзакций, так ведь? Причем делаем это из-за того что обработчик транзакций встроенный в СУБД нас не устраивает. Может проще взять другую СУБД, особенно если речь о новой разработке?
...
Рейтинг: 0 / 0
22.09.2004, 03:47
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32705470
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
А Вы еще раз внимательно вчитайтесь в предложенную мной схему:
1. Это не есть попытка ручками реализовать схему работы, аналогичную Оракл, это идея о том, как правильно на блокировочнике разруливать OLTP и OLAP.
2. Предложенная мной идея (не решение конечно) транзакционно зависимая, где это Вы увидели, что она переживет ROLLBACK ? Данные в таблицу "перерасчет" попадут только по закоммиченным данным из операций по движению денег. А удаляться эти данные оттуда в пределах единой транзакции пересчета баланса, так что здесь накладок быть не может. Как вариант - вместо таблицы буфера всегда можно сделать флаг "участвует в балансе" в таблице движения средств и использовать его, выставляя его в событии после включение суммы записи в баланс.
3. Если рухнет сервер, то при его запуске все незакрытые транзакции откатятся, через минуту запуститься событие и оно продолжит пересчитывать баланс. Не вижу тут никакого повода делать логи или еще чего было.
4. Никто не мешает сделать обновление пересчитываемой таблицы баланса по ночам, а для подсчета текущего баланса клиента брать его баланс и все записи из таблицы движения по счетам, у которых дата ввода в БД больше даты последнего перерасчета баланса. С учетом вышепредложенного мною флага по проведение записи в баланс это дает хорошие функциональные возможности держать подтвержденный на утро баланс и иметь возможность править работу текущих суток, без пересчитывания баланса.
5. Вы мне пытаетесь сказать, что лучше всего универсальный Оракл, который одновременно представляет из себя OLTP и OLAP. Я Вам пытаюсь показать, что при должном подходе и проектировании БД задачу по обработке и накоплению данных можно решить на чистых OLTP-блокировочниках. Если БД получается огромной и по ней часто выполняются аналитические отчеты, то к ним просто рядышком ставится аналитический DSS-сервер, на который по ночам переливаются данные и уже никому не мешая он может быстро промалывать огромные массивы данных, далеко оставляя позади тот же Оракл. Ну а для DSS, где данные обычно сливаются сразу блоками и важна скорость чтения, а не записи, как раз версионность никогда не помешает. Что например и сделано в Sybase IQ :)
...
Рейтинг: 0 / 0
22.09.2004, 08:27
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32706698
Константин Лисянский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Константин Лисянский
Участник
Если высказаться по теме, то на мой взгляд такая фича очень полезна.
Особенно (как заметил Николай Куликов) в среде хранилищ данных.
Особенно в среде активных хранилищ данных, когда хранилище используется не только для ответов на стратегические вопросы, но и на тактические.
Кроме этого, неплохо иметь возможность в СУБД когда можно установить приоритеты группам пользователей. Например, менеджеры высшего звена достаточно чувствительны ко времени отклика. Соответственно, им нужно дать приоритет повыше чтобы гарантировать быстрое получение результатов.
Аналитики могут при этом пододжать пока их сложные запросы закончатся.
Другая группа пользователей - call center. Им важно быстро получить информацию о звонящем абоненте. Если они её берут из хранилища, то будет хорошо, если их запросы будут иметь высокий приоритет.

Поскольку в дискусии упоминалась СУБД Teradata, замечу, что там такая штука тоже имеется и называется Prioriry Scheduler. Кстати в отличие от ораклового менеджера, который появился только недавно, в Терадате эта штука существует с самого начала (т.е более 20 лет), что косвенно подтверждает полезность такой возможности.

По поводу оптимизации запросов - к хранилищу данных очень часто даётся доступ тулзам, которые генерируют SQL (BusinessObjects, Cognos Impromptu, Microstrategy). Пользователь, как правило, имеет очень мало возможностей повлиять на вид SQL, поэтому назначение приоритетов в данном случае может спасти от "шалунов", способных загнать сиситему в даун элементарно (cross join, например).

С уважением,
Константин Лисянский
http://lissianski.narod.ru
...
Рейтинг: 0 / 0
22.09.2004, 15:03
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32706842
Зорин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зорин
Гость
Зл0йПомнится Сайбэйс тоже когда-то обещал блокировку на уровне записи. Обещанного три года ждут. В случае с Сайбэйсом даже дольше.

Насколько мне известно row level locking в Sybase ASE есть с 1998-го.
примерно в это же время был выпущен MSSQL 7.0.
м?
...
Рейтинг: 0 / 0
22.09.2004, 15:47
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32707161
x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
x
Гость
Зл0йА разве в MSSQL можно в онлайне логи присылать на standby базу которая открыта на чтение?Прислать можно,
но на время поднятия логов пользователей из базы придется выгнать.
...
Рейтинг: 0 / 0
22.09.2004, 17:19
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32707705
Зл0й
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зл0й
Участник
Уважаемый ASCRUS, для того чтобы бороться с проблемой читатели-писатели вы сделали вот что:
- разнесли данные по нескольким таблицам
- завели таблицу транзакций (фактически почти transaction log)
- завели асинхронный по отношению к потоку транзакций процесс, читающий таблицу транзакций и обновляющий таблицу балансов. То есть "почти MQ" только ручками и single-threaded.

Соответственно мы заботу о согласованности данных попросту переложили с СУБД на приложение. Если в случае Оракла об этом заботится СУБД, то в вашем решениее об этом заботится приложение, проверяя timestamps. Недостатки этого подхода такие:
- приложения менее надежны чем СУБД.
- триггеры как работают как минимум на порядок медленнее чем механизмы СУБД
- мы факлически выстроили все транзакции в очередь и выполняем их по одной. Масштабируемость получается практически никакая.
- таблица балансов "отстает" по времени от других таблиц СУБД. Что если данные о балансах требуются более сложной транзакции, которой так же требуются данные из других таблиц? Нам во всех этих таблицах потребуется timestamp? Иначе как мы обеспечим согласованность данных из других таблиц с таблицей балансов?

Например, предположим что есть какая-то бизнес-логика связанная с проверкой баланса, читающая из других таблиц (не движение по счетам). Значит в тех таблицах тоже должен быть timestamp дающий нам информацию об актуальности данных. Иначе данные из этих таблиц могут быть по состоянию на 17:02:05 а балансы по состоянию на 17:01:55. Обеспечивать согласованность данных "ручками" это очень серьезный головняк.

Таким образом мы имеем весьма нетривиальную задачу обработки транзакцй "ручками". У нас есть очередь транзакций, асинхронный по отношению к потоку транзакций процесс их выполняющий, и данные согласованность которых надо проверять вручную. Зачем нам тогда вообще такая СУБД, если обработку транзакций приходится вручную делать? Чем писать собственный обработчик транзакций, может лучше взять готовый? На мэйнфреймах народ обходится MQ, CICS, вообще данные в файлы (VSAM, ISAM) пишет. Не нужна им СУБД, если конкурентного доступа к данным нет. Ваше решение, уважаемый ASCRUS есть по сути отказ от СУБД в пользу мэйнфреймовой идеологии обработки транзакций.

ИМХО решение крайне громоздкое, неэффективное и дорогое в разработке и обслуживании. Гораздо проще (и грамотнее) возложить обработку транзакций на СУБД и не заморачиваться самодельными TP мониторами.

Про hot standby - если в MSSQL для того чтобы логи накатывать надо юзеров из базы выгонять, то этот standby не горячий а холодный. По определению. Как и бэкап, горячий работает без выгона юзеров из базы, а холодный - с выгоном. По терминологии спорить не буду - "называй хоть горшком, только в печку не ставь". Скажем так, фичи которая в оракловой терминологии называется "hot standby" в MSSQL нет.
...
Рейтинг: 0 / 0
23.09.2004, 04:19
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32708074
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Уважаемый Зл0й . У меня начали возникать смутные подозрения, что мы с Вами явно общаемся на разных языках и никак не можем понять друг друга. Подскажите пожалуйста - Вы программист или администратор ?

автор- разнесли данные по нескольким таблицам
- завели таблицу транзакций (фактически почти transaction log)
- завели асинхронный по отношению к потоку транзакций процесс, читающий таблицу транзакций и обновляющий таблицу балансов. То есть "почти MQ" только ручками и single-threaded.
В своем последнем посте я предложил более элегантное решение проблемы - создание флага участия в балансе в таблице "Движение". Но и в предыдущем предложенном решении я ничего такого из вышеперечисленного не делал. Я просто создал табличку, в которой тусуются неподтвержденные в балансе записи до их добавления значений в баланс. Когда они добавяться, то табличка очистится. Заметьте я говорю языком проектировщика БД, Вы же шпрехаете терминами этакого заправского сисадмина.

авторСоответственно мы заботу о согласованности данных попросту переложили с СУБД на приложение. Если в случае Оракла об этом заботится СУБД, то в вашем решениее об этом заботится приложение, проверяя timestamps. Недостатки этого подхода такие:
- приложения менее надежны чем СУБД.
- триггеры как работают как минимум на порядок медленнее чем механизмы СУБД
- мы факлически выстроили все транзакции в очередь и выполняем их по одной. Масштабируемость получается практически никакая.
- таблица балансов "отстает" по времени от других таблиц СУБД. Что если данные о балансах требуются более сложной транзакции, которой так же требуются данные из других таблиц? Нам во всех этих таблицах потребуется timestamp? Иначе как мы обеспечим согласованность данных из других таблиц с таблицей балансов?
Ни о каком приложении и речи быть не может. Вся забота о TIMESTAMP лежит на СУБД, которое автоматически обновляет это поле при добавлении/изменении записи и запросах, в фильтрах которых стоит условие Поле TimeStamp <= NOW(). Так что Ваше высказывания о приложениях только подтверждает мои догадки, что Вы особо не реализовывали сложную бизнес-логику средствами СУБД. Насчет триггеров тоже промашка - в Оракле конечно может FOR EACH ROW и работают медленно и вызываются на каждую запись, но вот в ASA и MSSQL триггера FOR EACH STATEMENT вызываются только раз на весь массив изменяемых данных и при их граммотной реализации особо тормозов не наблюдается. Таблица балансов просто обязана отставать по времени - думаю Вы слышали про понятие банковский день, то есть мы имеем определенный на промежуток времени стабильный и подтвержденный баланс. Мало ли какие операции произойдут за этот промежуток. Всегда должно быть закрытие периода с перерасчетом аггрегатных таблиц, когда информация уже подтверждена, прошла контроль и готова войти в закрытый период. Это используется в любой задаче и мне удивительно, что Вы это игнорируете и пытаетесь влепить банку в реалтайме плавающий баланс. Насчет TIMESTAMP и других таблиц честно говоря ничего не понял. Если Вы имеете ввиду, что у Вас есть еще какие то таблицы, содержащие аггрегированные значения по входящим данным, то они всегда будут соотвествовать действительности, так как все будут пересчитываться одновременно в пределах одной транзакции на момент закрытия периода, как раз в том самом единственно запущенном событии (параллейном потоке). Исходя из вышесказанного просьба - давайте вести обсуждение по конкретной постановке, а не придумывать "А вот если ...".

авторТаким образом мы имеем весьма нетривиальную задачу обработки транзакцй "ручками". У нас есть очередь транзакций, асинхронный по отношению к потоку транзакций процесс их выполняющий, и данные согласованность которых надо проверять вручную. Зачем нам тогда вообще такая СУБД, если обработку транзакций приходится вручную делать? Чем писать собственный обработчик транзакций, может лучше взять готовый? На мэйнфреймах народ обходится MQ, CICS, вообще данные в файлы (VSAM, ISAM) пишет. Не нужна им СУБД, если конкурентного доступа к данным нет. Ваше решение, уважаемый ASCRUS есть по сути отказ от СУБД в пользу мэйнфреймовой идеологии обработки транзакций.
У меня нет обработки транзакций ручками. Чуть выше я обьяснил почему. У меня есть понятие закрытой (стабильной) точки для аггрегатных (расчетных) таблиц и данные, пока не вошедшие в закрытый период во входящих таблицах. Где здесь транзакции ручками хоть убей не вижу, я вроде тут пользуюсь стандартными транзакциями РСУБД и используя преимущества блокировочника, эффективно без лишнего потребления ресурсов решаю поставленную задачу.

Теперь более подробно разжую мной последнюю предложенную схему:

1. Есть входящая табличка "Движение", в которой регистрируются (то есть добавляются) записи по движению денег клиентов по счетам. В ней есть 2 служебных поля "Обработано" и "ВремяИзменения".

2. Есть аггрегатная табличка "Баланс", в которой на каждого клиента по каждому его счету храниться сумма баланса на закрытый период (банковский день). В ней есть служебное поле "ВремяИзменения" на всякий пожарный, так как здесь оно нам не пригодится.

3. Есть представление "Текущий баланс", в котором есть запрос, обьединяющий данные с таблички "Баланс" с данными с таблички "Движение", выставляя ей фильтр "Обработано = 0 AND TimeStamp <= Now()". Блокировать это представление никого не будет, так как в табличку движение новые данные уже будут добавляться с TimeStamp больше текущего времени на момент вызова представления и целостность будет прекрасно соблюдаться даже на уровне "Non-repeatable read", который не мешает писателям продолжать добавлять новые записи в табличку "Движение".

4. Есть событие (EVENT), которое автоматически запускается СУБД например в 4 часа утра и на этот момент стартует транзакцию, пересчитывает все аггрегатные таблички (в данном случае "Баланс") с учетом внесенных за сутки новых данных, ориентируясь по фильтру "Обработано = 0 AND TimeStamp <= Now", далее выставляет флаг "Обработано" для записей, вошедших в баланс и подтверждает проведение транзакции. Во время проведения транзакции таблица "Движение" идет на уровне изоляции "Non-repeatable read", а таблица "Баланс" на "Phantom row".

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

Кстати заметьте - Вы стали не продукты сравнивать (MSSQLvsOracle), а технологии. А этого делать никогда нельзя, если не знать обе технологии в совершенстве (что даже теоретически представляется сомнительным). Плюс Вы ко всему прочему вместо того, чтобы доказать на практических примерах преимущество версионника, попытались теоретически порассуждать, чем плох блокировочник. Если бы у меня было много свободного времени, то я бы Вам написал 1000 и одно решение на приведенные в пользу версионника задачи, которые бы доказывали, что блокировочник не хуже, а может быть даже и лучше. Все Ваши доводы против моих предложенных схем пока свелись к типовому высказыванию многих знакомых мне ораклистов "Это же думать надо и ручками писать. Круче, когда сама СУБД за тебя думает и делает".

Ну и главное:

OLTP - главная задача быстро собирать входящую информацию и рассчитывать по ней дополнительную. Писатели должны иметь более высокий приоритет перед читателями. Любой блокировочник удовлетворяет этому условию и поэтому я называю его "чистым" OLTP. Если в БД граммотно реализована бизнес-логика, то во входящие таблицы информация только добавляется и почти никогда не обновляется/удаляется, что не накладывает блокировки на уже архивные данные и позволяет читателям выполнять по ним запросы, без конфликтов с писателями. На аггрегатные таблицы, в которых одновременно могут применяться операции добавления, изменения, удаления обычно вешают параллейный поток и обновляют их через определенные промежутки времени, согласно постановке задачи (банковский день, расчетный месяц в зарплате и т.д.).

DSS - главная задача обрабатывать большие массивы информации и иметь быстрый ответ системы на любой запрос без его лимитирования на обьем обрабатываемых данных. Читатели должны иметь более высокий приоритет перед писателями. Обычно данные в такие системы собираются не в реалтайме, а за определенные промежутки времени. Таким образом я называю Terradata и Sybase IQ "чистыми" DSS.

С учетом вышесказанного смотрим на Оракл и видим, что его механизм версионности - это попытка совместить OLTP и DSS, то есть фактически схема "Два в одном". Вот ответьте мне на вопрос, что лучше - "сотовый + цифровой фотоаппарат" или же "сотовый со встроенным фотоаппаратом" ? А не ответите, потому что слово "лучший" в данном случае очень расплывчато. Смотря для чего лучше. Если с точки зрения скорости и качества - то по отдельности всегда было и будет лучше. А если с точки зрения цены и удобства использования, то эффективнее получается сотовик со встроенным цифровиком. Я в данном случае ратую для своих задач "за скорость+качество", а вы "за цену+удобство". Но по моему говорить, что Ваше "Два в одном" круче как минимум не стоит. Для Вас может быть и круче, а лично для меня версионность Оракла - это такой большой и подозрительный мыльный маркетинговый пузырь от компании Оракл для менеджеров и руководителей, на который Вы купились из за недостаточного знания механизмов проектирования БД на блокировочниках и фактически занимаетесь здесь тем, что цитируете рекламные лозунги Оракла. Вот чего меня удивляет, почему бы ораклистам, вместо того, чтобы ставить в заслугу Оракла довольно сомнительный механизм его версионности, не вспомнить о действительно его полезных фичах, которых нет например в MSSQL - кроссплатформенность, партиции, возможность тонкой ручной настройки, множество механизмов индексов, поддержка сжатых таблиц, довольно мощный PL/SQL и приличный оптимизатор запросов и т.д. и т.п. - тут много я за них достоинств привести не могу хотя бы по причине того, что не работал в тяжелых практических проектах с Ораклом. У меня даже начинают возникать смутные подозрения - а может всем этим никто и не пользуется в России на Оракле, может быть все так и продолжают по привычке курсорами гонять и не думая раскатывать по своим сегментам гигантские транзакции, говоря "Пущай, если будет ступориться, тачку помощнее купим, делов то".

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

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

на счет универсальности оракла уже как-то устал показывать на лидируещее положение оракла в тестах как OLPT так и DSS ... в то время как мыльный маркетинговых пузырь sybase не способен показать результат хотябы в разы отстающий от оракла.
...
Рейтинг: 0 / 0
23.09.2004, 12:35
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32708270
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Yo!2ASCRUS

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

на счет универсальности оракла уже как-то устал показывать на лидируещее положение оракла в тестах как OLPT так и DSS ... в то время как мыльный маркетинговых пузырь sybase не способен показать результат хотябы в разы отстающий от оракла.
Хорошо, если в последнем мною предложенном решении Вы не увидели возможности получать согласованные данные на текущий момент, то мне действительно остается только развести руками. Так же забавно послушать про малое число задач, которое почему то по моей практике как раз и является большинством решаемых задач, наверное мы что то разное автоматизируем. Насчет незаморачиваться ручками Вы буквально дословно подтвердили мое предыдущее высказывание о взглядах Ораклистов на проектирование баз данных. Ну а лидировать он может в тестах хоть до опупения, меня не интересуют теоретические выкладки и синтетические тесты, меня интересуют практические примеры работы реальных проектов и реальная скорость работы. Может быть в тестах Sybase и не способен показать "колоссальные результаты работы", но вот опять же из практики я сколько не видел банков, предприятий, целых отраслей работающих на Sybase - все эффективно работает на довольно средненьких по мощности и стоимости серверах, а по ораклевым решениям в основном вижу разгибание пальцев контор-интеграторов, не детские цены на ПО и аппаратную часть и довольно таки средненькие решения, которые по страшному тормозят, вокруг которых пасется куча админов, которые нянчатся с сервером как ребенком и круглые глаза клиента, когда ему сообщают, что БД подросла и неплохо бы сервачок поменять на более мощный, мотивируя это тем, что тогда тормоза изчезнут и все будет OK. И говорю я это не к тому, что Оракл плохой и не качественный, а к тому, что вот такие рассуждения по поводу "При проектировании БД головой думать не обязательно, СУБД все сделает за нас" и приводять к таким вот печальным результатам.

Ладно уважаемые коллеги администраторы-ораклисты. Заканчиваем беседу, все равно у нас разные параллейные вселенные и даже если я потрачу на вас свое время и выложу скрипты решений, которые будут эффективно работать, думаю все равно вы останетесь при своем мнении и будете продолжать цитировать маркетинговые лозунги Оракла, даже не вникая в то, что я пишу.

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

авторНу а лидировать он может в тестах хоть до опупения, меня не интересуют теоретические выкладки и синтетические тесты, меня интересуют практические примеры работы реальных проектов и реальная скорость работы.
реальные тесты реальных задач вы можете посмотреть на http://www50.sap.com/benchmark/

авторНу а лидировать он может в тестах хоть до опупения, меня не интересуют теоретические выкладки и синтетические тесты, меня интересуют практические примеры работы реальных проектов и реальная скорость работы.
реально оракл работает на ERP решениях от SAP, PeopleSoft, Oracle applicatons, MS Navison и других менее крутых.

авторМожет быть в тестах Sybase и не способен показать "колоссальные результаты работы", но вот опять же из практики я сколько не видел банков
список банков в которых работает решения оракла можно посмотреть сдесь:
http://www.oracle.com/customers/index.html

авторИ говорю я это не к тому, что Оракл плохой и не качественный, а к тому, что вот такие рассуждения по поводу "При проектировании БД головой думать не обязательно, СУБД все сделает за нас" и приводять к таким вот печальным результатам.
наверно именно из-за этих самых результатов все ведущие игроки в ИТ подерживают субд оракл и ни один из лидеров SAP, PeopleSoft, Oracle applicatons, MS Navison непашут на sybase ;)

авторИ говорю я это не к тому, что Оракл плохой и не качественный, а к тому, что вот такие рассуждения по поводу "При проектировании БД головой думать не обязательно, СУБД все сделает за нас" и приводять к таким вот печальным результатам.
т.е. мое проэктирование заведомо кривое ... логично :)

2ASCRUS
очень бы хотелось кроме слепой веры хоть чуть-чуть посмотреть на факты. вы так и не смогли доказать главного - если ваше решение имеет ограничение то какие бонусы оно за это дает? то что ваша очередь эфективней на данный момент вызывает большие сомнения ...
...
Рейтинг: 0 / 0
23.09.2004, 14:06
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32708514
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Yo!наверно именно из-за этих самых результатов все ведущие игроки в ИТ подерживают субд оракл и ни один из лидеров SAP, PeopleSoft, Oracle applicatons, MS Navison непашут на sybase ;)
ASE:
http://www.sybase.com/partner/alliance
http://www.sybase.com/detail_list/1,6902,44640,00.html
http://www.sybase.com/detail_list/1,6902,44634,00.html

ASA:
http://www.ianywhere.com/success_stories/index.html

Это называется так - "Сижу я в своем болоте и знаю, что круче этого болота нету на свете, потому как из за камышей другой местности мне не видно" :)

Вот что меня всегда в Вас удивляет - это Ваши безосновательные выводы, сделанные по принципу "То что я знаю, то и верно". Это зря, можно ведь и в лужу сесть :)
...
Рейтинг: 0 / 0
23.09.2004, 14:21
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32708527
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Кстати вдогонку - Sybase с SAP и PeopleSoft не просто партнеры, а большие друзья, можно сказать стратегические партнеры. Так что Ваши замечания по меньшей мере были смешны.
...
Рейтинг: 0 / 0
23.09.2004, 14:24
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32708590
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
мне совершенно не интересны достижения sybase, я вам отведил на конкретные выпады относящиеся к ораклу.

на счет друзей - это как говорится неописуемо. ну посмотрите

SAP - WALLDORF, Germany and DUBLIN, Calif. - 11/17/2003 12:00:00 AM - SAP AG (NYSE: SAP) and Sybase, Inc. (NYSE: SY) today announced a worldwide agreement to deliver integrated solutions by aligning SAP® Business One with Sybase data management solutions for small and midsize businesses (SMBs).

не знаю что такое SAP® Business One ... я говорил о mySAP ERP

PeopleSoft - Sybase’s enterprise database, integration, and infrastructure expertise optimizes PeopleSoft’s Supply Chain Management, CRM, Enterprise Service Automation, Financial, and Human Capital

это все ? а остальное ?

Oracle EBS - мимо
MS Navision - мимо


давайте вернемся к версионости и очередям, а то мерятся уже немного достало.
...
Рейтинг: 0 / 0
23.09.2004, 14:40
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32708604
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EugeneS
Участник
ASCRUS

Поле TimeStamp <= NOW(). Так что Ваше высказывания о приложениях только подтверждает мои догадки, что Вы особо не реализовывали сложную бизнес-логику средствами СУБД. Насчет триггеров тоже промашка - в Оракле конечно может FOR EACH ROW и работают медленно и вызываются на каждую запись, но вот в ASA и MSSQL триггера FOR EACH STATEMENT вызываются только раз на весь массив изменяемых данных и при их граммотной реализации особо тормозов не наблюдается.

Мне это напомнило историю, когда примерно лет 10 тому назад, пришел один товаришь и принес программульку для бухгалтерии написанную с использоваением СУБД Paradox и показывал как это круто.
Когда его спросили знает ли о про функционал который предоставляет Oracle ( тогда это был Oracle5 или 6 версии, на что он сказал , что это "херня", потому как он матекматик и все предусмотрел и в этом вопросе понимает лучше .

Насчет триггеров:
Oracle имеет триггера которые срабатывают как в случае FOR EACH ROW так и на уровне оператора, и могут быть как BEFORE так и AFTER .

Насколько я слышал, уровня BEFORE в MSSQL нет , думаю его нет и в SYBASE.
А то о чем вам намекали, это том что внутренние механизмы ядра СУБД отрабатывают события намного быстрей , чем самописные.

ASCRUS
Таблица балансов просто обязана отставать по времени - думаю Вы слышали про понятие банковский день, то есть мы имеем определенный на промежуток времени стабильный и подтвержденный баланс. Мало ли какие операции произойдут за этот промежуток. Всегда должно быть закрытие периода с перерасчетом аггрегатных таблиц, когда информация уже подтверждена, прошла контроль и готова войти в закрытый период. Это используется в любой задаче и мне удивительно, что Вы это игнорируете и пытаетесь влепить банку в реалтайме плавающий баланс.

А еще есть такая штука , как карточный счет, который должен в обязательном порядке подерживаться в on-line. Иначе вы сможете появляется ситуация когда вы сможете снять со счета больше денег чем у вас есть.

Или сходить в интернет на большее время , чем у вас заплачено, в случае предоставления услуг например Dial-up. Там теже счета, что и в банке, только расчет происходит в момент дисконнекта пользователя.
...
Рейтинг: 0 / 0
23.09.2004, 14:45
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32708639
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EugeneS
Участник
ASCRUSКстати вдогонку - Sybase с SAP и PeopleSoft не просто партнеры, а большие друзья, можно сказать стратегические партнеры. Так что Ваши замечания по меньшей мере были смешны.


Да, блин куда ни кинь у SAP все производители СУБД просто дружбаны.
Не понятно как только они деньги зарабатывают.

У SAP есть такая вещь как sizer ( то есть тест SAP SD benchmark ).
Cпециально чтобы пользователи смогли смасштабировать свои системы , согласно своих потребностей.
Смотреть сюда: www50.sap.com/benchmark


Так там SYBASE как лучшего дружбана даже нет в списках.
Зато там есть такая СУБД как SAP DB, которая на некоторых тестах делает
например MSSQL ( до 8 проц).
Вы не находите это странным?
Я лично нахожу.
...
Рейтинг: 0 / 0
23.09.2004, 14:54
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32708669
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EugeneS
Участник
ASCRUS
http://www.sybase.com/partner/alliance
http://www.sybase.com/detail_list/1,6902,44640,00.html
http://www.sybase.com/detail_list/1,6902,44634,00.html


Лезу, открываю.
http://www.sybase.com/detail/1,6904,1032460,00.html

Код: plaintext
1.
Currently, the SEC system has  200  users across the United States and the data warehouse is  320  gigabytes. With the new growth capabilities of the system, Foster sees the data warehouse quickly expanding to a terabyte of data.


автор
In addition to Sybase IQ, the new architecture includes Sun Microsystems Sun Fire™ hardware and an EMC Symmetrix® SAN.



Объем просто поражает, особенно с учетом того на каком оборудовании он крутится.
Вот и получается, что Sybase занимает почетное 4 место с 4 процентами рыночной доли, которая постоянно снижается.


Серьезный недостаток Oracle - это в основном его цена.
Это да, и тут ничего не попишешь.
Что же касается архитектуры самой СУБД,
тут он пока сделал всех, на несколько лет вперед.
И ничего тут не попишешь, с этим просто надо смирится.
Да, какие-то попытки сократить отрыв безусловно есть, но пока тому же например MSSQL еще ой как далеко.
...
Рейтинг: 0 / 0
23.09.2004, 15:03
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32708755
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Уважаемые оппоненты с платформы Оракл. Хотелось бы вести с вами двустороннюю беседу, то есть когда я внимательно читаю и думаю над вашими сообщениями, и вы в свою очередь проделываете над моими сообщениями.

Скажите пожалуйста, вот это:
ASCRUS3. Есть представление "Текущий баланс", в котором есть запрос, обьединяющий данные с таблички "Баланс" с данными с таблички "Движение", выставляя ей фильтр "Обработано = 0 AND TimeStamp <= Now()". Блокировать это представление никого не будет, так как в табличку движение новые данные уже будут добавляться с TimeStamp больше текущего времени на момент вызова представления и целостность будет прекрасно соблюдаться даже на уровне "Non-repeatable read", который не мешает писателям продолжать добавлять новые записи в табличку "Движение".
не является ли способом получения актуального баланса ? Вы с постоянным упорством продолжаете меня обвинять в том, что я якобы работаю с неактуальными данными, создается такое впечатление, что вы не читали моих постов или же не захотели вникать в то, что в них написано.

Так же у вас совершенно нет оснований говорить что "Оракл круче, потому что я думаю, что в другой СУБД этого нет или реализовано не эффективно или тесты на каком то сайте доказывают". Думать и доказывать можно много, но лучше знать. Поэтому отвечаю: в Sybase ASE нет BEFORE триггеров, в Sybase ASA они есть. И я вас так же спрашиваю: "А вы знаете, какой есть функционал у той же Sybase ASA ?" и вы на это мне заявляете, что это все херня, потому что это не Оракл, а вы как ораклисты в этих вопросах уж точно понимаете лучше.

Ну а "намеки" про внутренние механизмы я понял сразу, в ответ я "намекнул", что при правильной постановке задачи и проектировки базы данных может оказаться никакие дополнительные внутренние/универсальные механизмы и не понадобятся и даже наоборот, кроме сжирания ресурсов ничего путного они больше не сделают.

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

Так что никаких теоретических выкладок пожалуйста - или вы даете конкретные примеры, где действительно MSSQL/Sybase ASE/Sybase ASA/Sybase IQ/IBM DB2/Terradata не справились с задачей и после перевода ее на Оракл произошло чудо, или же просто рассказываете в качестве ликбеза о достоинствах Оракла, не задевая зазря другие технологии и СУБД.

P.S. И не надейтесь, что меня это хоть как то задевает - по моему личному мнению и опыту работ я твердо знаю те решения и отрасли, где даже на маленькой Sybase ASA я сделаю гораздо более конкуретноспособное и финансово-выгодное решение, чем существующие на Оракле. Меня честно говоря больше волнует успешность, доходность и конкурентнооспособность ПО, чем всякие выкладки на сравнения внутренних реализаций механизмов СУБД, так что я предпочитаю занимать ниши, где моя продукция заведомо лучше существующей, без разницы реализованной на чем - Оракле, MSSQL или других СУБД.
...
Рейтинг: 0 / 0
23.09.2004, 15:29
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32708790
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Кстати не понятно, если все с Ораклом так хорошо, то почему та самая пресловутая MB вешается с ним каждый день и содержит не малый по размерам штат администраторов ? И почему у моего друга сисадмина в конторе месяц назад поставили решение на Оракле и я выслушиваю теперь его поток жалоб на этот "вечный версионный тормоз" ? "Кривые ручки" скажите Вы и будете сто раз правы. Но как же тогда спрашивается супер-версионный механизм Оракла, который по идее сам должен разруливать любые ситуации, где проектировщику не нужно продумывать политику работы читателей и писателей и не задумываться о блокировках ? Почему он вместо разруливания выступает ручным тормозом ? Кто виноват и что делать клиентам ?

P.S. И кстати что делать, если по бизнес-логике потребуется специально заблокировать некоторые данные, чтобы их никто не мог изменить до подтверждения заблокировавшей их транзакции ?
...
Рейтинг: 0 / 0
23.09.2004, 15:40
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32708849
Фотография Gluk (Kazan)
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Gluk (Kazan)
Участник
select ... for update [nowait]

его есть у нас.
...
Рейтинг: 0 / 0
23.09.2004, 15:55
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32708884
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EugeneS
Участник
ASCRUSКстати не понятно, если все с Ораклом так хорошо, то почему та самая пресловутая MB вешается с ним каждый день и содержит не малый по размерам штат администраторов ? И почему у моего друга сисадмина в конторе месяц назад поставили решение на Оракле и я выслушиваю теперь его поток жалоб на этот "вечный версионный тормоз" ? "Кривые ручки" скажите Вы и будете сто раз правы. Но как же тогда спрашивается супер-версионный механизм Оракла, который по идее сам должен разруливать любые ситуации, где проектировщику не нужно продумывать политику работы читателей и писателей и не задумываться о блокировках ? Почему он вместо разруливания выступает ручным тормозом ? Кто виноват и что делать клиентам ?

Что такое MB, я честно скажу не знаю.
И почему ваш друг жалуется вам я тоже не могу ответить.
Есть еще такой вопрос как выбор поставщика решения , и тут СУБД Oracle как бы не причем.

Супер-версиионный механизм от Oracle != механизм "защита от дурака" у него другое назнаечение, сохранение старый версий блоков.


ASCRUS
P.S. И кстати что делать, если по бизнес-логике потребуется специально заблокировать некоторые данные, чтобы их никто не мог изменить до подтверждения заблокировавшей их транзакции ?


В общем случае
select fld1 , ....fldN from table_name fro update of fld1,... N;
...
Рейтинг: 0 / 0
23.09.2004, 16:04
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32708918
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
авторне является ли способом получения актуального баланса ? Вы с постоянным упорством продолжаете меня обвинять в том, что я якобы работаю с неактуальными данными, создается такое впечатление, что вы не читали моих постов или же не захотели вникать в то, что в них написано.

упорсто связано с тем что ...
авторНапример, предположим что есть какая-то бизнес-логика связанная с проверкой баланса, читающая из других таблиц (не движение по счетам). Значит в тех таблицах тоже должен быть timestamp дающий нам информацию об актуальности данных. Иначе данные из этих таблиц могут быть по состоянию на 17:02:05 а балансы по состоянию на 17:01:55.

авторНу а "намеки" про внутренние механизмы я понял сразу, в ответ я "намекнул", что при правильной постановке задачи и проектировки базы данных может оказаться никакие дополнительные внутренние/универсальные механизмы и не понадобятся и даже наоборот, кроме сжирания ресурсов ничего путного они больше не сделают.

как только вы приведете конкретные примеры где внутрение механизмы менее эфективны доморощеных мы вам покажем кривоту проэктирования примера.


авторВас обижает, что я обвиняю версионность Оракла и его "Два в одном" обычным маркетинговым ходом. Меня же поражает, что вы абсолютно необоснованно высказываете свое мнение о тех СУБД, с которыми не работали и не можете составить обоснованное о них мнение. Причем в таких обвинениях вы даже не удосуживаетесь различать круг задач и ложно создаете впечатление, что Оракл везде полезен и крут, а все остальные далеко позади.
1. нас обидеть можно только зарплатой, т.е. вы пока не сможете :)
2. на счет "маркетинговым ходом", хоть убей не понимаю у нас получается что оракл доказавший свою субд и в независимых тестах (sap&tpc) и в реальных задачах лидеров рынка (sap, ms, peoplesoft) на протежении 30 лет, подвердил тучей сертификатов и независимых коммисий и прочей лабудой - маркетинговый ход ... ок, согдасен а где все это у сайбеза ? или мы должны верить наслово ? смешно.


ЗЫ. совсем не понятна ваша увереность в нашем кривом проэктировании. но если это помогает вам оправдать ваши недочеты, то мы не возражаем ;)
...
Рейтинг: 0 / 0
23.09.2004, 16:15
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32708948
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EugeneS
Участник
ASCRUS

Ну а "намеки" про внутренние механизмы я понял сразу, в ответ я "намекнул", что при правильной постановке задачи и проектировки базы данных может оказаться никакие дополнительные внутренние/универсальные механизмы и не понадобятся и даже наоборот, кроме сжирания ресурсов ничего путного они больше не сделают.


Уважаемый, если вы считаете, что ваш механизм будет работать быстрей ,чем ядро СУБД , безотносительно какую СУБД вы используете, то либо функциональность СУБД "ниже плинтуса", либо вы чего-то не увидели.
Это обычно просто правило "хорошего тона" если для решения задачи необходимая функциональность есть в СУБД надо ей пользоваться, свой вариант чаще всего будет хуже. Исключение только ранние версии СУБД когда разработчик СУБД еще не "отладился".


ASCRUS

Так что никаких теоретических выкладок пожалуйста - или вы даете конкретные примеры, где действительно MSSQL/Sybase ASE/Sybase ASA/Sybase IQ/IBM DB2/Terradata не справились с задачей и после перевода ее на Оракл произошло чудо, или же просто рассказываете в качестве ликбеза о достоинствах Оракла, не задевая зазря другие технологии и СУБД.


Доказательством тех. возможностей того или иного продукта служат benchmark тесты:
- общие ( типа TPC ) - это типа пузомерки, их часто недостаточно, они часто не отражают ситуацию, но дают общее представление.
- специальные ( типа SAP SD ) - тесты приложений.

Так может вы поясните почему нет тестов SAP SD для SYBASE?
Тем более SAP и SYBASE партнеры.
...
Рейтинг: 0 / 0
23.09.2004, 16:23
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32709167
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Интересно, а что это вы так плавненько тему на Sybase переводите ? Я привел пример на Sybase ASA (которая кстати на самом деле даже не продукт Sybase) только из за того, что это мой сейчас основной рабочий инструмент. С таким же успехом я мог привести пример на Sybase ASE, MSSQL или DB2. Вы тут вроде как утверждали, что Оракл крут по сравнению со всеми именно из за того, что он версионник, а остальные блокировочники. Ну так и давайте не ограничиваться рамками одной СУБД, а посмотрим на все блокировочники: MSSQL, IBM DB2, Sybase ASE, Sybase ASA, ... Я от их всего имени выступал вообще то, а не от конкретно продукта, вот давайте все их и обсудим на досуге, выдавая по шаблону темы "Почему Оракл круче MSSQL", "Почему Оракл круче DB2", и т.д. Ну а насчет Sybase - мне честно говоря как то все равно, какие там у нее тесты есть, официальная информация всегда лежит у них на сайте, если кого то интересует, то всегда можно ее посмотреть, в том числе и где у нее тесты на SAP. Я лично работаю с iAnywhere Solution, Sybase для нее выступает только как крыша.

P.S. Эк вас задело всех высказывания насчет маркетинговых фишек и "Двух в одном" :) А вместо доказательств опять мне подсовываете ссылочки на тесты и маркетинговые заявления. Мне пожалуйста "Success story" с цифрами - какая СУБД стояла, какие были нагрузки и техника, почему был выбран Оракл для замены решения и что клиент от этого выиграл. Я человек недоверчивый и пока я как то не увидел в Оракле чего то революционного, что нельзя было бы эффективно решить средствами связки "Блокировочник OLTP" + "Аналитический сервер DSS".

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

для начало ответе все таки Злому:
автор
Например, предположим что есть какая-то бизнес-логика связанная с проверкой баланса, читающая из других таблиц (не движение по счетам). Значит в тех таблицах тоже должен быть timestamp дающий нам информацию об актуальности данных. Иначе данные из этих таблиц могут быть по состоянию на 17:02:05 а балансы по состоянию на 17:01:55.


если очень нужно привязатся к задаче давайте берем кто-то тут предложил онлаин казино. тысячи юзеров/транзакций, каждую секунду баланс меняется. на монитор выводим в реал-тайме график выйгрышей, чтоб не проеба[censored] момент когда народу "слишком" повезло.
...
Рейтинг: 0 / 0
23.09.2004, 18:04
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32709251
Фотография SergSuper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
SergSuper
Участник
какие-то вы все "версионщики" действительно странные.
Ну допустим надо Вам постоянно правильная сумма по муллиону записей - есть у вас такая возможность постоянно скаладывать никого не блокируя - вот вы так и делаете. А если подумать: можно же эту сумму постоянно пересчитывать при вводе каждого выигрыша - и не надо постоянно муллионы складывать и спокойно без версионности можно.

Кстати, правильно ли я понял что эта версионность спасает только если данные "для посмотреть"? Что-то менять на основании этих данных я не могу - хоть они и закоммиченные, но всё равно могут быть устаревшие.
...
Рейтинг: 0 / 0
23.09.2004, 18:32
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32709329
protector
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
protector
Участник
SergSuperКстати, правильно ли я понял что эта версионность спасает только если данные "для посмотреть"? Что-то менять на основании этих данных я не могу - хоть они и закоммиченные, но всё равно могут быть устаревшие.
Истину глаголишь. Так и есть.
...
Рейтинг: 0 / 0
23.09.2004, 19:23
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32709344
Фотография Leonid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Leonid
Участник
To Oracle-адепты:
Народ, а чем вы будете крыть, когда Yukon выйдет, где версионность "похитрее", чем версионность в Oracle ;)
У уважаемого Yo! в кормане всегда останется N-ое количество "фичей", которых не будет в MSSQL, которыми он будет пугать доверчивых форумян
Зато MSSQL станет сильно .NET-интегрированным. Sybase тоже чего-нибудь придумает. DB2 тоже подтянется.

Да и, вообще, ни какая технология не вечна. Утверждать, что Oracle не победим и единственно верен, на основании долгой истории триумфа - глупо и недальновидно. Пытаться в этом убедить самого себя и окружающих - тоже не благодарное занятие.

Вот за что мы-то все здесь бьемся, когда на пятки наступают "Фаил-Мейкеры"?

P.S. Навеяно борьбой с "Файл-мейкерством" в соседнем форуме.
...
Рейтинг: 0 / 0
23.09.2004, 19:43
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32709353
locky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
locky
Участник
2Leonid
А вот нефиг! Выйдет Юкон - тогда и поглядим, чо там езь, а чего там нету. А то вот уже бывало - наобещано куча полезных фич, токо юзать их тяжко.

И ваще, опять скатываемся на то, кто что и как могет сделать и как йето с нашей точки зрения неправильно делается у других. сравнить реальные рализации возможности нету? Нету, потому как простые примеры нам никому не катят, а сложные реальные - в облом писать.
Posted via ActualForum NNTP Server 1.0
...
Рейтинг: 0 / 0
23.09.2004, 19:53
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32709377
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
авторА если подумать: можно же эту сумму постоянно пересчитывать при вводе каждого выигрыша - и не надо постоянно муллионы складывать и спокойно без версионности можно.

похоже вы не поняли. смысл в том что когда ты эту сумму пересчитываешь то ее нужно куда-то записать, но тебе это сделать может помешать длинный отчет который читает этот баланс и кучу других таблиц. а задерживать писателя никак нельзя. тогда что делает ASCRUS - выносит этот баланс в другую таблицу, но проблемы это не решает транзакция то одна. тогда он делает ход "конем" выносит запись суммы баланса в другую транзакцию, раз в одной не получается - делает некую очередь, которая уже в отдельной транзакции. если очередь с новым балансом натыкается на длинный отчет, то не беда - она может и подождать хоть весь "банковский день".
т.е. ASCRUS добился того что делает оракл, но гораздо дешевле, работает небось хоть на 486 с 16мб. в принципе чем не решение ... еслиб не "банковский день"
...
Рейтинг: 0 / 0
23.09.2004, 20:13
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32709390
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
Народ, а чем вы будете крыть, когда Yukon выйдет, где версионность "похитрее", чем версионность в Oracle ;)[/quot]

когда в юконе будет версионость вместе с блокировками, вместо оракловой жавы дотнет, t-sql дотянет до pl/sql и встрят профайл и автономные транзакции и т.д, Yo! нажмет next в чудо визарде и с помпой смигрирует на mssql (если нет разницы зачем платить больше ? (C) не мое ... ), заберет себе разницу в лицензиях и на эти деньги нажрется, и сядет нетрезвый за руль и ... глупо умрет :) и знаете кто будет в этом виноват ? я по глазам вижу - знаете :)
...
Рейтинг: 0 / 0
23.09.2004, 20:22
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32709427
Зл0й
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зл0й
Участник
Давайте рассмотрим в общем случае как обрабатываются транзакции, чтобы всем стало понятно что "доморощенный" механизм предложенный уважаемым ASCRUS есть ничто иное как самодельный монитор транзакций. Я не говорю что он работать не будет - будет он работать, только плохо и вызывать будет немерянную головную боль у разработчиков.

Предположим что есть "поток транзакций", то есть с течением времени происходят запросы некоторых данных и запросы на их изменение. Требуется создать у клиентов порождающих эти запросы иллюзию того что они монопольно имеют доступ к данным. Иначе они будут друг другу "мешаться". Любому мало-мальски грамотному специалисту по СУБД известны такие понятия как "грязное чтение", "фантомы" итп. Эта "иллюзия" в случае чтения называется "согласованное чтение" (consistent read).

В случае если мы испольщуем СУБД как обработчик транзакций, то СУБД нам гарантирует некоторую семантику их выполнения. Семантика зависит от уровня изоляции транзакций. Более низкие уровни изоляции, например read commited, допускают некоторые виды несогласованности данных. Более высокий уровень serializable этого не допускают. В любом случае, СУБД нам гарантирует некое поведение, зависящее от уронвня изоляции. Например в случае serializable СУБД нам гарантирует что все данные которые мы читаем, будут "по состоянию на время начала читающей транзакции". Что это значит? Это значит что они во-первых commited до начала читающей транзакции, во-вторых любые изменения этих данных произошедшие после начала нашей транзакции нам не видны.

Что же мы видим в решении предложенном ASCRUS ? Есть ли там гарантия согласованности данных даваемая нам СУБД? Нет её. Есть некие таблицы, где мы помечаем данные timestamp'ом который потом вручную проверяем. То есть забота о согласованности данных на момент времени возложена на приложение а не на СУБД. Чтобы получить согласованные данные мне нужно в запросе указать этот самый timestamp.

Теперь разберемся с писателями. В решении предложенном ASCRUS мы попросту
- выстроили всех писателей в очередь
- завели один-единственный теневой (background) процесс который эти запросы выполняет.
Чем не MQ "в миниатюре"? Идея та же, выполнять транзакции по отной. Сериализовать то бишь. К чему приведет такое решение? Чем больше объем транзакций в еденицу времени (чем плотнее поток) тем больше время отклика. Ибо процесс один, а транзакций много. Будет масштабироваться такое решение? Не будет.

Современные СУБД имеют гораздо более совершенные механизмы обработки транзакций чем постановка оных в очередь и последовательое выполнение. По сути, физическая сериализация аналогична блокировке "на всю базу целиком". СУБД же умеют блокировать только те ресурсы которые нужны данной транзакции, да еще и выполняют их параллельно. Некотороые, "особо продвинутые" СУБД даже поддерживают механизм версий. СУБД - гораздо более прогрессивный механизм обработки транзакций чем очередь. К сожалению у СУБД-блокировщиков есть недостаток: они не позволяют одновременно читать данные на уровне serializable и писать эти данные. Как с этим бороться:
- Выстроить транзакции в очередь и выполнять последовательно
- Придумать собственный механизм "версий" данных, например добавив во все таблицы timestamp.

Как уже было сказано выше, производительность такой системы будет ерундовая. Во-первых из-за выполнения транзакций "по очереди" во-вторых объемы данных будут расти не по дням а по часам. Версии-то надо где-то хранить. Мы храним их в таблицах. Можно, конечно, убивать все записи где timestamp'у отроду день и больше. Это начинает очень сильно напоминать PostGreSQL где бедным администраторам приходится постоянно биться со сборкой мусора. Там тоже старые версии храняться в таблицах вместе с новыми, только timestamp там неявный.

В общем, производительность решения предложенного ASCRUS ИМХО будет крайне низкой, а головная боль связанная с поддержкой - постоянной.

А теперь отвечу на вопрос "разработчик я или администратор". Я разработчик с опытом администрирования. Поэтому я понимаю, что системы которые я разрабатываю, потом придется кому-то поддерживать. Я дорожу своей репутацией в компании где я работаю. Команда DBA меня уважает, поскольку мы с ними "говорим на одном языке" и системы которые я разрабатываю поддерживаются достаточно спокойно, и без головных болей. Потому, что все продумано и протестировано заранее. Поэтому если мне что-то от DBA надо, я все получаю сразу, без задержек и волокиты. А другие разработчики жалуются на DBA. Ну а в development environment я сам себе DBA. Раньше я сам был production DBA, просто надоело с пейджером ходить. Хочется покоя.
...
Рейтинг: 0 / 0
23.09.2004, 21:08
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32709460
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
Зл0й
оптимизированы на чтение. Если механизм версий будет читать данные из логов, сдается мне что производительность будет весьма паршивая. ИМХО Оракловое решение с сегментами отката - разумный компромисс.

Я бы сказал - нашлепка сверху. Изначально же в Oracle не было этой фичи с получением данных из сегмента отката. Потом добавили. Кстати, что они при этом физическую структуру этого сегмента отката переделали, чтобы оптимизировать для чтения - это еще вопрос. Конечно, он мог быть изначально оптимизированным и для чтения.

Зл0й
Соответсвенно вопрос, если Оракл - не версионник, тогда кто тогда версионник?


Интербаза. И файерберд пророк его.

Зл0й
А что будет в Юконе - мы поглядим когда его сделают. Помнится Сайбэйс тоже когда-то обещал блокировку на уровне записи. Обещанного три года ждут. В случае с Сайбэйсом даже дольше.


Че за поклепы ? Есть в Sybase -е row level locking , уже года три как.
(с версии 11.9)
...
Рейтинг: 0 / 0
23.09.2004, 21:56
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32709518
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
авторЯ бы сказал - нашлепка сверху. Изначально же в Oracle не было этой фичи с получением данных из сегмента отката. Потом добавили. Кстати, что они при этом физическую структуру этого сегмента отката переделали, чтобы оптимизировать для чтения - это еще вопрос. Конечно, он мог быть изначально оптимизированным и для чтения.

Сможешь вспомнить, когда, в каком году эта "нашлепка" была сделана?
...
Рейтинг: 0 / 0
24.09.2004, 00:56
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32709536
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Насчет изоляций спорить прекращаю. Хочу только сказать, что указанные опонентами проблемы на блокировочниках для serializable решаются:
1. С помощью временных локальных и глобальных таблиц
2. С помощью автоматически пересчитываемых аггрегатных постоянных таблиц
3. С помощью специального значения timestamp
4. Проектирование входящих таблиц так, чтобы в них только добавлялась, но редко изменялась и тем более удалялась информация
5. С помощью анти-фантомной блокировки, сужающей круг блокирующихся записей, если СУБД это умеет делать и присутствует подходящий уникальный индекс
6. Тщательным продумыванием применения наиболее подходящих для разных задач уровней транзакций
7. Проектированием "коротких" транзакций
8. Созданием таблиц-буферов
9. Созданием параллейных потоков с помощью событий и агентов расписаний.

SergSuperКстати, правильно ли я понял что эта версионность спасает только если данные "для посмотреть"? Что-то менять на основании этих данных я не могу - хоть они и закоммиченные, но всё равно могут быть устаревшие.
Хотелось бы услышать комментарии специалистов - неужели это правда ? Тогда какой толк в версионности Оракла, если согласованость данных у меня будет только внутри транзакции и не будет совпадать с реальными данными в БД ? Как вообще тогда решать задачи и реализовывать бизнес-логику обработки и расчета информации на хранимых процедурах PLSQL ? Я честно говоря в таком случае даже не представляю себе, как с этим можно жить. Наверное действительно кто что знает, тот так и думает :)
...
Рейтинг: 0 / 0
24.09.2004, 02:19
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32709662
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
ASCRUSНасчет изоляций спорить прекращаю. Хочу только сказать, что указанные опонентами проблемы на блокировочниках для serializable решаются:
1. С помощью временных локальных и глобальных таблиц
2. С помощью автоматически пересчитываемых аггрегатных постоянных таблиц
3. С помощью специального значения timestamp
4. Проектирование входящих таблиц так, чтобы в них только добавлялась, но редко изменялась и тем более удалялась информация
5. С помощью анти-фантомной блокировки, сужающей круг блокирующихся записей, если СУБД это умеет делать и присутствует подходящий уникальный индекс
6. Тщательным продумыванием применения наиболее подходящих для разных задач уровней транзакций
7. Проектированием "коротких" транзакций
8. Созданием таблиц-буферов
9. Созданием параллейных потоков с помощью событий и агентов расписаний.


как все сложно то

ASCRUS
SergSuperКстати, правильно ли я понял что эта версионность спасает только если данные "для посмотреть"? Что-то менять на основании этих данных я не могу - хоть они и закоммиченные, но всё равно могут быть устаревшие.
Хотелось бы услышать комментарии специалистов - неужели это правда ? Тогда какой толк в версионности Оракла, если согласованость данных у меня будет только внутри транзакции и не будет совпадать с реальными данными в БД ? Как вообще тогда решать задачи и реализовывать бизнес-логику обработки и расчета информации на хранимых процедурах PLSQL ? Я честно говоря в таком случае даже не представляю себе, как с этим можно жить. Наверное действительно кто что знает, тот так и думает :)

В чем проблема то? Программист пишет код, реализует бизнес-логику и в 90% случаев не забивает себе голову всякой чепухой из вышеотквоченного списка.
...
Рейтинг: 0 / 0
24.09.2004, 09:04
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32709767
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EugeneS
Участник
to Leonid

Народная мудрость гласит, что если бы у бабушки были я.....а,
то она бы была дедушкой.
...
Рейтинг: 0 / 0
24.09.2004, 10:11
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32709788
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EugeneS
Участник
killed авторЯ бы сказал - нашлепка сверху. Изначально же в Oracle не было этой фичи с получением данных из сегмента отката. Потом добавили. Кстати, что они при этом физическую структуру этого сегмента отката переделали, чтобы оптимизировать для чтения - это еще вопрос. Конечно, он мог быть изначально оптимизированным и для чтения.

Сможешь вспомнить, когда, в каком году эта "нашлепка" была сделана?

Я лично помню, что отдельный сегмент отката ( назывался before image)
был еще в версии Oracle 5 это район где-то 82-85 годов.

Слышал, что были люди которые работали с 4 версией.
...
Рейтинг: 0 / 0
24.09.2004, 10:19
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32709803
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EugeneS
Участник
killed[quot ASCRUS]Насчет изоляций спорить прекращаю. Хочу только сказать, что указанные опонентами проблемы на блокировочниках для serializable решаются:
1. С помощью временных локальных и глобальных таблиц
2. С помощью автоматически пересчитываемых аггрегатных постоянных таблиц
3. С помощью специального значения timestamp
4. Проектирование входящих таблиц так, чтобы в них только добавлялась, но редко изменялась и тем более удалялась информация
5. С помощью анти-фантомной блокировки, сужающей круг блокирующихся записей, если СУБД это умеет делать и присутствует подходящий уникальный индекс
6. Тщательным продумыванием применения наиболее подходящих для разных задач уровней транзакций
7. Проектированием "коротких" транзакций
8. Созданием таблиц-буферов
9. Созданием параллейных потоков с помощью событий и агентов расписаний.


В результате имеет увеличение стоимости проекта,
то есть деньги которые можно было бы заплатить за нормальный продукт, и не страдать, вы просто получите сами.
Это банальное перераспределение бюджета с затрат на СУБД на затраты на разработку , отладку и подержание этого механизма.
Вместо того чтобы заплатить за электродрель, вы берете обычную, покупаете электромотор и систему управления к ней и начинает конструировать свою электродрель.


А знаете что будет потом, если у вас более или менее серьезная контора?
После IT Аудита компании аудиторы найдут у вас рисков на пару лимонов зеленых денег и в результате руководсво почувствовав как зашаталось кресло, напомнит вам про велосипед и все что оно про вас думает.
Хорошо если вас не уволят.

Потому как с вами никто не будет считаться , если стоимость акций компании из-за непрохождения аудита упадет.
Просто произведут "зачистку" и все.
Таковы реалии сегодняшнего дня.
...
Рейтинг: 0 / 0
24.09.2004, 10:29
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32709820
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
killed
В чем проблема то? Программист пишет код, реализует бизнес-логику и в 90% случаев не забивает себе голову всякой чепухой из вышеотквоченного списка.
Ничего себе чепуха. Вот обьясните мне непонимающему что будет в следующей ситуации:
1. Есть Table1 и связанная с ней по FOREIGN KEY Table2.
2. Транзакция A начала добавлять записи в Table2, ссылаясь на родителей, уже существующих в Table1
3. Чуть позжее транзакция B начала выполнять запрос:
DELETE FROM Table
WHERE Table1_id NOT IN (SELECT Table1_id FROM Table2);
4. Пока транзакция A продолжала возиться, транзакция B выполнила COMMIT -ведь Оракл ничего не блокирует и подзапрос читатель B не будет ждать писателя A, а просто успешно удалит записи из таблицы Table1, на которые ссылаются добавляемые в этот момент из транзакции A, ведь правда ?
5. Транзакция A выполняет наконец таки COMMIT, делает CHECK ON COMMIT (кстати проверки всегда только на коммите выполняются ?), получает ошибку FOREIGN KEY на несуществующих родителей и откатывается.

Я все правильно понял или у Оракла есть механизм регулирования таких ситуаций ?
...
Рейтинг: 0 / 0
24.09.2004, 10:39
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32709876
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
EugeneS
Вас послушать, так у нас в странах СНГ только и работают проекты, обслуживающие огромные хранилища и тысячи конкурирующих сессий. Все Вами сказано применимо в России настолько к малой части проектов, что Ваш пример с электродрелью мягко говоря не удачен. Наоборот, я как раз все больше встречаю примеров несоответствующего задаче выбора платформы Оракл, там где и работает не спеша всего сотня пользователей и база данных размером даже до сотни гигабайт не дотягивает. Переворачивая Ваш пример в таком случае такое использование Оракла сильно смахивает на попытку насадить электродрель в качестве привода стеклоочистителя, где как раз был бы более уместен маленький компактный моторчик. Мой например круг задач вообще не требует ничего, что приводилось выше в качестве преимущества версионной модели перед блокировочной. Наоборот, для моих проектов в качестве важнейших требований выдвигаются встраиваемость в приложение (тиражность), низкие требования к аппаратной части, нулевое администрирование, быстрая и эффективная работа, надежность и расширенная функциональность, позволяющая реализовывать средствами ХП сложную бизнес-логику расчетов. В данном случае для таких задач главное быстро и правильно посчитать, в них существуют понятия расчетный и закрытый период, отчеты делаются не в реалтайме и участвует в них уже посчитанная и уже неизменяемая информация. Скажите с чего это мне друг по этим требованиям вдруг менять платформу и с Sybase ASA, у которого купив Platinum Disk я могу встраивать ее бесплатно в свое приложения, платя Sybase только за пользовательские лицензии , уходить на Оракл, отказываясь от минимальных аппаратных требований (P1-166 32RAM), нулевого администрирования, офф-лайн репликации и заметно поднимая цену продукта для клиента ? Зачем пихать Оракл в те дырки, где ему не место ? И зачем необоснованно в общем смысле обвинять блокировочники ? Как я уже и говорил, в базах данных существуют ниши, где блокировочники гораздо уместнее и эффективнее. Например на PocketPC и PalmOS версия UltraLite ASA весит всего 64 кб и имеет довольно таки неплохие возможности, близкие к ее полной версии. Было бы забавно посмотреть на версионный Оракл на КПК, на БД которого работает всего один пользователь, а Оракл делает сегменты отката :)
...
Рейтинг: 0 / 0
24.09.2004, 10:59
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32709885
aston
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aston
Участник
авторНичего себе чепуха. Вот обьясните мне непонимающему что будет в следующей ситуации:
1. Есть Table1 и связанная с ней по FOREIGN KEY Table2.
2. Транзакция A начала добавлять записи в Table2, ссылаясь на родителей, уже существующих в Table1
На записи(-ях) в Table1 Oracle в блоках данных поставил блокировку.


3. Чуть позжее транзакция B начала выполнять запрос:
DELETE FROM Table
WHERE Table1_id NOT IN (SELECT Table1_id FROM Table2);
Лезет в блок данных, наталкивается на блокировку и ждет на блокировке.


4. Пока транзакция A продолжала возиться, транзакция B выполнила COMMIT -ведь Оракл ничего не блокирует и подзапрос читатель B не будет ждать писателя A, а просто успешно удалит записи из таблицы Table1, на которые ссылаются добавляемые в этот момент из транзакции A, ведь правда ?
Oracle блокирует. Будет ждать. Команда DELETE - это не читатель.


. Транзакция A выполняет наконец таки COMMIT, делает CHECK ON COMMIT (кстати проверки всегда только на коммите выполняются ?), получает ошибку FOREIGN KEY на несуществующих родителей и откатывается.
Нет никакого CHECK ON COMMIT. Никогда проверки не выполняются при COMMIT'е. Все проверки выполняются по факту. Не получит ошибку.
...
Рейтинг: 0 / 0
24.09.2004, 11:03
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32709938
Guest_2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guest_2
Гость
авторВ результате имеет увеличение стоимости проекта,
то есть деньги которые можно было бы заплатить за нормальный продукт, и не страдать, вы просто получите сами.
А без словоблудия, обосновать свои умозаключения получится?

PS. К сожалению обоснованной критики ASCRUS'a у Yo!, Зл0го и Вас не получается.
...
Рейтинг: 0 / 0
24.09.2004, 11:19
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32709956
onstat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat
Гость
ASCRUS killed
В чем проблема то? Программист пишет код, реализует бизнес-логику и в 90% случаев не забивает себе голову всякой чепухой из вышеотквоченного списка.
Ничего себе чепуха. Вот обьясните мне непонимающему что будет в следующей ситуации:
1. Есть Table1 и связанная с ней по FOREIGN KEY Table2.
2. Транзакция A начала добавлять записи в Table2, ссылаясь на родителей, уже существующих в Table1
3. Чуть позжее транзакция B начала выполнять запрос:
DELETE FROM Table
WHERE Table1_id NOT IN (SELECT Table1_id FROM Table2);
4. Пока транзакция A продолжала возиться, транзакция B выполнила COMMIT -ведь Оракл ничего не блокирует и подзапрос читатель B не будет ждать писателя A, а просто успешно удалит записи из таблицы Table1, на которые ссылаются добавляемые в этот момент из транзакции A, ведь правда ?
5. Транзакция A выполняет наконец таки COMMIT, делает CHECK ON COMMIT (кстати проверки всегда только на коммите выполняются ?), получает ошибку FOREIGN KEY на несуществующих родителей и откатывается.

Я все правильно понял или у Оракла есть механизм регулирования таких ситуаций ?

Да есть назвывается
ORA-01555 snapshot too old: rollback segment number string with name "string" too small. И кто то покатится назад.
Для разруливания ситуации придется все делать в serializable.
И таблица будет заблокирована.
Потом вы идеолог проекта пойдет на http://asktom.oracle.com/pls/ask/f?p=4950:8:7028778449259009053::NO::F4950_P8_DISPLAYID,F4950_P8_B:839412906735,Y
Научится искать блокирующие сессии, напишет монитор для их отслкживания,
в код понаставляет commit-ов через строку.
И самое главное что все это будет проиходить после того как проект здан заказчику. И получение дополнительных денег на исправление ситуации не предвидится.

ASCRUS respect!!!!

С уважением, onstat
...
Рейтинг: 0 / 0
24.09.2004, 11:25
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32709997
Фотография PL99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PL99
Участник
astonНет никакого CHECK ON COMMIT. Никогда проверки не выполняются при COMMIT'е. Все проверки выполняются по факту. Не получит ошибку.Вы преувеличиваете, не все так плохо в Oracle по сравнению c ASA :-)
Oracle8 Enterprise Edition Documentation LibraryDEFERRABLE Constraints
You can specify table and column constraints as DEFERRABLE or NOT DEFERRABLE. DEFERRABLE means that the constraint will not be checked until the transaction is committed. The default is NOT DEFERRABLE.

If you specify DEFERRABLE, you can also specify the constraint's initial state as INITIALLY DEFERRED and thereby start the transaction in DEFERRED mode. Or you can specify a DEFERRABLE constraint's initial state as INITIALLY IMMEDIATE and start the transaction in NOT DEFERRED mode.


Oracle8 Enterprise Edition Documentation LibraryTo define a unique constraint on a column as INITIALLY DEFERRED DEFERRABLE, issue the following statement:

CREATE TABLE orders
(ord_num NUMBER CONSTRAINT unq_num UNIQUE (ord_num)
INITIALLY DEFERRED DEFERRABLE);


Oracle8 Enterprise Edition Documentation LibrarySee Oracle8 Administrator's Guide and Oracle8 Concepts for more information about deferred constraints.
...
Рейтинг: 0 / 0
24.09.2004, 11:35
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32710025
Фотография Я и ёжик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Я и ёжик
Участник
Зл0йНапример в случае serializable СУБД нам гарантирует что все данные которые мы читаем, будут "по состоянию на время начала читающей транзакции".
Это не так, в случае serializable СУБД нам гарантирует, что в результате выполнения некоторого набора транзакций мы получим результат который соответствует некоторому последовательному выполнению этих транзакций.
В случае чисто-блокировочного механизма реализации менеджера транзакций, все данные которые мы читаем в Serializable будут скорее "по состоянию на момент КОНЦА читающей транзакции".

MasterZiv Интербаза. И файерберд пророк его.
Это всего лишь один из вариантов реализации менеджера транзакций с версионным механизмом ("Менеджер транзакций на основе упорядочевания по временным меткам с механизмом контроля версий"), но далеко не единственно возможный, я про это уже писал здесь.

авторХотелось бы услышать комментарии специалистов - неужели это правда ? Тогда какой толк в версионности Оракла, если согласованость данных у меня будет только внутри транзакции и не будет совпадать с реальными данными в БД ?
1) Неправда, можно я не буду излагать теорию сериализации и механизмы шедулеров с версионным контролем? Желающие всегда это могут найти в сети или в книгах. Concurrency Control & Recovery in Database Systems, By Ph. Bernstein .
2) Что такое "реальные данные в БД"? Предположим у нас блокировочный шедулер, сессия чего то согласовано читает, другае изменяет, но висит на блокировке (выствленной нашей читающей). Первая закончила и показала данные на экран ( в отчет, или запихнула в какую то таблицу), блокировка освобожденя , изменяющая транзакция тут же изменила данные. Мы смотрим на наш экран и видим одни данные, а в базе они уже другие. Таким образом мы в любом случае получаем данные на какой то момент.
Согласованность данных внутри транзакции должна быть "по умолчанию" (это то самое свойство атомарности), а согласованность данных между транзакциями ( изолированность) как раз и обеспечивают менеджеры транзакций всевозможных типов, в том числе и с версионными механизмами, и обеспечит они её могут ( для Oracle например за счет невозможности изменить данные которые были изменены после начала serializable транзакции).
Тут стоит сделать заметку о том, что Oracle уровень Serializable, не совсем настоящий, в теории такой уровень обычно называют Snapshot, поскольку в нем возможны некоторые сценарии нарушающие критерий сериализации.

killedПрограммист пишет код, реализует бизнес-логику и в 90% случаев не забивает себе голову всякой чепухой из вышеотквоченного списка.
К сожалению так и просиходит, программист не забивает себе голову, даже тогда когда надо было забить... а потом появляются рассказы про "версионных монстров".

2 All
По поводу преимущества того или иного механизма управления паралельными заданиями, я думаю всегда можно найти задачи которые будут лучше выполнятся на том или другом механизме и если бы был однозначно лучший, другие бы давно вымерли. Реальные же задачи, наверное, всегда лежат где то между этими крайними случаями. Поэтому и интересны планировщики использующие разные механизмы или их комбинации. И Oracle был тут первым, за что ему наверное честь и хвала, но на мой взгляд он остановился в развитии этой модели, особенно в блокировочной части ( во многи наверное потому , что модель получилась очень удачной, но может пора проснутся?).
MS-SQL пытается выйти на эту же тропу, посмотрим, что получится.
...
Рейтинг: 0 / 0
24.09.2004, 11:44
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32710026
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EugeneS
Участник
ASCRUS EugeneS
отказываясь от минимальных аппаратных требований (P1-166 32RAM), нулевого администрирования, офф-лайн репликации и заметно поднимая цену продукта для клиента ? Зачем пихать Оракл в те дырки, где ему не место ? И зачем необоснованно в общем смысле обвинять блокировочники ? Как я уже и говорил, в базах данных существуют ниши, где блокировочники гораздо уместнее и эффективнее. Например на PocketPC и PalmOS версия UltraLite ASA весит всего 64 кб и имеет довольно таки неплохие возможности, близкие к ее полной версии. Было бы забавно посмотреть на версионный Оракл на КПК, на БД которого работает всего один пользователь, а Оракл делает сегменты отката :)

Ну если мы разговариваем о P1-166, мне просто нечего сказать.
У меня рабочая станция не первой свежести с P3-700 и 512МБ RAM и что теперь?

Просто если вы уж такой борец за ресурсы, может вам просто перейти на терминальную модель( символьные терминалы ). Она очень дешева, и проще как в управлении, и для своей работы требует всего 9600 но может работать и на 4800.


Я согласен с утверждение , что Oracle не следует совать везде, но согласитесть , что "натягивать" блокировочник, там где реально на те задачи где он не справляется как то не очень.
Ваш пример явно не от хорошей жизни иначе бы вы не изобретали велосипед.


Только не надо про 0 администрирование.
Я все это уже слышал и то Sybase и то что MSSQL не требует админа , и чем это обычно заканчивается, тоже знаю.

Я ничего не буду говорить про КПК это нескольку другая область.

Если бы у меня стояла задача что-то сделать не на Oracle, я бы все же обратил внимание на SAP DB и уж точно не на SYBASE.
В версии SAP DB которая поставляется с SAP есть механизм неблокирующего чтения.


http://%5D%7C>]http://]|> http://help.sap.com/saphelp_erp2004/helpdata/en/9b/bbd7fdf55511d6b2f700508b6b8a93/content.htm

авторConsistent View
liveCache uses consistent views to guarantee read access to an object, independently of any changes being made to the data by other transactions.
A consistent view can extend across one or more transactions (OMS version).
When a user starts a transaction, it is kept until the end of that user’s data view. Any later changes made to the data by other users do not change the data view of the first user.
When an object within a consistent view is accessed for the first time, this object data is copied to the OMS heap. If multiple consistent views want to access the same data, the appropriate data is copied to a separate area of the OMS heap for each consistent view. Ending the consistent view deletes the corresponding data in the OMD heap.


А вот то что касается стоимости.


авторMySQL AB offers MaxDB under the MySQL AB "dual licensing" model. The complete MaxDB offering is provided free of charge under the Free Software/Open Source GNU General Public License (GPL) and also a commercial license with no open source restrictions.

MaxDB is priced at $49 per named user on single-CPU systems with a minimum of five users. Alternatively, customers may choose to pay $1,490 per CPU, without user limitations. A "named user" is an actual end user who connects to the database directly or indirectly.

MySQL AB provides support to commercial licensees of MaxDB, both for SAP and non-SAP use. Please contact our sales team for more information.

В двух словах это значит, если вы распространяете свой код под GPL ничего не платите.


Согласитесть это выглядит намного привлекательней чем тот "гемор" на которые вы себя обрекли, из-за банального упорства.
...
Рейтинг: 0 / 0
24.09.2004, 11:44
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32710055
Фотография PL99
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
PL99
Участник
EugeneSТолько не надо про 0 администрирование.
Я все это уже слышал и то Sybase и то что MSSQL не требует админа , и чем это обычно заканчивается, тоже знаю. Поясните,какую именно СУБД от Sybase вы имеете ввиду? ASCRUS, насколько я понимаю, ведет речь об Adaptive SQL Anywhere, которая действительно не требует администрирования.
...
Рейтинг: 0 / 0
24.09.2004, 11:54
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32710064
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EugeneS
Участник
Guest_2 авторВ результате имеет увеличение стоимости проекта,
то есть деньги которые можно было бы заплатить за нормальный продукт, и не страдать, вы просто получите сами.
А без словоблудия, обосновать свои умозаключения получится?
PS. К сожалению обоснованной критики ASCRUS'a у Yo!, Зл0го и Вас не получается.


К хорошему быстро привыкаешь, потому вы и не понимаете то о чем они говорят.

Хорошо по-русски.
Вместо того чтобы сосредоточится на разработки бизне-логики проекта, вы вдобавок сосредотачиваетесь на логике самописного монитора транзакций.
Итого имеет
- разработать свой монитор транзакций
- разработать софт который требует заказчик.

Вместо
- просто разработать софт который требует заказчик.

Мы здесь наверно не будет обсуждать, то факт, что мол де у нас "дешевые программеры" или "наберем кучу студентов" , это только ухудшит ситуацию.

В дальнейшем когда автор самописного монитора покинет компанию ( такое часто случается и скорей всего случится ) и пользователь программного продукта обратиться к вам за подержкой кто будет разбираться в нюансах работы этого изделия?

Скорей всего никто, потому как этоб большие затраты на сопровождение со стороны компании разработчика. Скорей всего вас проигнорируют.
...
Рейтинг: 0 / 0
24.09.2004, 11:58
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32710106
aston
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
aston
Участник
PL99
Вы преувеличиваете, не все так плохо в Oracle по сравнению c ASA :-)
Конечно. DEFERRABLE появилось в 8-ке и, наверное, кто-то ее использует.
...
Рейтинг: 0 / 0
24.09.2004, 12:11
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32710241
Guest_2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guest_2
Гость
авторХорошо по-русски.
Вместо того чтобы сосредоточится на разработки бизне-логики проекта, вы вдобавок сосредотачиваетесь на логике самописного монитора транзакций.
Итого имеет
- разработать свой монитор транзакций
- разработать софт который требует заказчик.
Вместо
- просто разработать софт который требует заказчик.

А где Вы увидели в примере ASCRUS'a монитор транзакций?
То что он написал не выходит за рамки, говорю в Ваших же терминах, разработки бизне-логики проекта .
...
Рейтинг: 0 / 0
24.09.2004, 12:59
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32710368
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
авторК хорошему быстро привыкаешь, потому вы и не понимаете то о чем они говорят.

Хорошо по-русски.
Вместо того чтобы сосредоточится на разработки бизне-логики проекта, вы вдобавок сосредотачиваетесь на логике самописного монитора транзакций.
Итого имеет
- разработать свой монитор транзакций
- разработать софт который требует заказчик.

Вместо
- просто разработать софт который требует заказчик.
Да не делаем мы мониторы транзакций, ну что Вы к ним пристали ? :) Все как то предпочитаем пользоваться существующим механизмом блокировок, который гарантирует нормальную работу уровней изоляций и с помощью блокировок разруливает различные ситуации между читателями и писателями при работе конкурирующих сессий. Так что мы именно разрабатываем софт. Тот пример, что я тут приводил удачный он или нет в проектах я своих не использую, меня спросили как это можно на блокировочнике реализовать, я подал идею. Не надо нас обвинять в том, что мы никогда не делаем. Так как сама постановка примера с точки зрения архитектуры блокировочника не удачная, то соотвествующе и предложенные способы реализации были не самые красивые. И это не говорит о том, что блокировочник ничего не может. Это всего лишь говорит о том, что постановка задачи должна быть изменена на другую, более подходящую под архитектуру блокировочника, но с такой же смысловой нагрузкой. Стоит помнить, что на одну задачу всегда может быть множество решений и как раз важна не СУБД, а специалист, который может для своей СУБД выбрать правильное решение. Вот например, SQL.RU крутиться на MSSQL, и ничего же - вроде как не висим по 2 часа и не ждем при чтении форумов, пока писатели нам блокировки снимут ? :)

авторМы здесь наверно не будет обсуждать, то факт, что мол де у нас "дешевые программеры" или "наберем кучу студентов" , это только ухудшит ситуацию.
Нет не будем. Но тот факт, что у Sybase ASA дешевые администраторы, вернее их отсутствие, ставит мои продукты на более конкуретноспособную ступень для распостранения тиражного ПО по сравнению с Ораклом. Все администрирование этой СУБД закладывается проектировщиком на момент проектирования базы данных, ее ядро автоматически балансирует нагрузки в зависимости от кол-ва подключений, исполняющихся запросов, уровней изоляций сессий и даже наполнения содержания БД (статистика). Функциональность WatcomSQL позволяет полностью прописать ответ на любое происходящее событие в базе данных и СУБД, и предпринять нужные действия предупреждающего или управляющего характера. Так же выполнить действия может опытный пользователь через соотвествующие визарды утилит ASA или же можно вынести функциональность администрирования в собственное приложение, осуществляемое опять же с помощью обычных операторов WatcomSQL. В дополнение для администрирования удаленных СУБД есть специальные сервисы, позволяющие производить мониторинг состояния и администрирование СУБД даже когда они в оффлайн, то есть отложенное, что важно и критично для контор, у которых сотрудникик имеют КПК с установленной на них ASA и базой, реплицирующейся с центральным сервером.

авторВ дальнейшем когда автор самописного монитора покинет компанию ( такое часто случается и скорей всего случится ) и пользователь программного продукта обратиться к вам за подержкой кто будет разбираться в нюансах работы этого изделия?
У меня друг вот с Украины на ASA и PB накатал программу, на которой работают удаленные филиалы их газпрома. Он сейчас в Москве, программа продолжает работать там. По репликациям данные ежесуточно приходят в центр для дальнейшей их обработки. Самое забавное, что их команда ни разу в жизни за 4 года не выехала на какой нибудь удаленный филиал Украины - просто рассылались инсталяции и обновления, этого было вполне достаточно. Причем включить в инсталяцию ASA очень просто как ручками (просто скопировав меньше десятка DLL размером 8 мб и прописав пару строчек в реестре), так и через InstallShield, для которого ASA имеет Merge-пакеты. Думаю этот пример - лучшая рекомендация для СУБД, которая должна работать удаленно или иметь сотни тиражных копий без дополнительного сопровождения.

авторСогласитесть это выглядит намного привлекательней чем тот "гемор" на которые вы себя обрекли, из-за банального упорства.
Ну Вы еще начните нас как Антон Леонидович убеждать, что мы сами не понимаем, как мучаемся бедные, не видим своего счастья в лице Оракла из за своего банального упорства :) Всего то просто - переходим на Оракл и ни о чем думать больше не надо, как ни спроектируй БД, все равно она поедет, важен администратор, а не проектировщик, поэтому он больше и денег получает, поэтому все дружно при переходе будем менять свою квалификацию :)
...
Рейтинг: 0 / 0
24.09.2004, 13:41
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32710407
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Кстати вдогонку про друга - он сейчас в Москве тем же самым занимается, дописывает и сопровождает в команде проект, написанный на ASA и PB, только уже в качестве клиентов выступают Австралия, Китай, США и еще куча стран. И это нормальная ситуация для ASA, если залезть на сайт iAnywhere и посмотреть "Success Story", то как раз основная масса реализованных на ней решений работает по всему миру как тиражные продукты, ПО для удаленных филиалов и мобильные СУБД для КПК - всего в мире порядка 20 000 зарегестрированных разработчиков ASA и 8 миллионов инсталяций СУБД их ПО у клиентов и это говорит не о том, что ASA там популярна, а о только том, что ее способности работать без админов прекрасно находят применение во многих нишах.
...
Рейтинг: 0 / 0
24.09.2004, 13:55
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32710410
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EugeneS
Участник
Guest_2 авторХорошо по-русски.
Вместо того чтобы сосредоточится на разработки бизне-логики проекта, вы вдобавок сосредотачиваетесь на логике самописного монитора транзакций.
Итого имеет
- разработать свой монитор транзакций
- разработать софт который требует заказчик.
Вместо
- просто разработать софт который требует заказчик.

А где Вы увидели в примере ASCRUS'a монитор транзакций?
То что он написал не выходит за рамки, говорю в Ваших же терминах, разработки бизне-логики проекта .

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

2ASCRUS
вы предлагаете мерятся саксес стори оракла и сайбеза ? может друзьями ? :) я конечно понимаю что вас немного задело, но мы ж вроде не труд всей вашей жизни опустили. не стоит совсем терять лицо и пытатся затмить ошибки крутостью сайбеза. сайбез это для малого бизнеса и с ораклом совершенно не конкурирует и не нада нам сказки про банки, нефть и кластера, мы этого от оракла достаточно налушались, давайте завязывать с маркетингом и вернемся к техническим аспектам, у ?
...
Рейтинг: 0 / 0
24.09.2004, 14:18
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32710461
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EugeneS
Участник
ASCRUSКстати вдогонку про друга - он сейчас в Москве тем же самым занимается, дописывает и сопровождает в команде проект, написанный на ASA и PB, только уже в качестве клиентов выступают Австралия, Китай, США и еще куча стран. И это нормальная ситуация для ASA, если залезть на сайт iAnywhere и посмотреть "Success Story", то как раз основная масса реализованных на ней решений работает по всему миру как тиражные продукты, ПО для удаленных филиалов и мобильные СУБД для КПК - всего в мире порядка 20 000 зарегестрированных разработчиков ASA и 8 миллионов инсталяций СУБД их ПО у клиентов и это говорит не о том, что ASA там популярна, а о только том, что ее способности работать без админов прекрасно находят применение во многих нишах.

Уважаемый я не обсуждаю СУБД ни для ПК ни для КПК.
Для них с успехом подойдет старый добрый Fox-Pro или Access, да все что угодно.
...
Рейтинг: 0 / 0
24.09.2004, 14:18
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32710924
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Yo!2ASCRUS
вы предлагаете мерятся саксес стори оракла и сайбеза ? может друзьями ? :) я конечно понимаю что вас немного задело, но мы ж вроде не труд всей вашей жизни опустили. не стоит совсем терять лицо и пытатся затмить ошибки крутостью сайбеза. сайбез это для малого бизнеса и с ораклом совершенно не конкурирует и не нада нам сказки про банки, нефть и кластера, мы этого от оракла достаточно налушались, давайте завязывать с маркетингом и вернемся к техническим аспектам, у ?
Действительно Sybase ASA позиционируется как SMB и мобильные решения и я не вижу в этом ничего плохого - это реальная ниша с реальными финансовыми перспективами (в качестве доказательства я привел их success story, а не для того, чтобы меряться). А вот насчет высказывания "сайбез это для малого бизнеса и с ораклом совершенно не конкурирует" то я скажу наоборот - это Оракл в решениях SMB с Sybase ASA совершенно не конкурирует и проигрывает по всем позициям: цене, требованиям железу, стоимости разрабки и сопровождения решений, администрированию и т.д. Опять же я это говорю не к тому, чтобы "опустить" Оракл, а чтобы показать Вам, что задач много и для каждой может оказаться эффективным тот инструмент, который на другой задаче показал бы себя неэффективным. Когда Вы признаете сей простой факт и подтвердите тот факт, что Оракл может быть где то и крут, но не везде и не для всех решений, тогда мы сможем двинуться дальше и сможем завязать с маркетингом, у ? :)

авторУважаемый я не обсуждаю СУБД ни для ПК ни для КПК.
Ну как же - Вы же заявили, что версионник Оракл круче блокировочников. Sybase ASA является промышленной кроссплатформенной масштабируемой СУБД от КПК и ПК до уровня серверов без накладывания ограничений на кол-во процессоров или RAM, с реализацией механизма блокировщика. Соотвествующе Ваши высказывания относились и к ней, потому что в своих высказываниях Вы нигде не уточнили, что Оракл круче блокировочников именно для ниши больших корпоративных хранилищ данных с тяжелой нагрузкой и условиями работы в реалтайме. Уточнили бы, я и в спор с Вами ввязываться не стал, это не моя ниша и меня на текущий момент не интересуют такие вещи. Вот как появится необходимость освоения и эксплуатации Sybase IQ, тогда и тема для разговоров появиться на этом поприще :) И кстати вопросик - почему не обсуждаете то ? Считаете ниже собственного достоинства или же просто никогда не делали тиражных решений для SMB и не имеете достаточно опыта для обсуждения онных ?

авторДля них с успехом подойдет старый добрый Fox-Pro или Access, да все что угодно.
Забавно, Вы уже приравняли "не-Оракл" РСУБД к файл-серверным технологиям. Вспоминая предыдущее высказывания про наш "многострадальный геммор" у меня начинает возникать стойкое убеждение, что у Вас какие то личные предубеждения против всех остальных РСУБД. А может сильная финансовая заинтересованность, уж не знаю прямо что и подумать, обычно люди не рекламируют какие то продукты методами анти-рекламы конкурирующих с ними.

All
Так что если мы будем конкретизировать свои высказывания и оперировать фактами, а не высказываниями "Круто", "Революция", "Если", "Я думаю" и т.д., то тема топика вернется в конструктивное русло и вместо того, чтобы спорить, что круче - троллейбус или танк, может быть сможем перейти к непредвзятому обсуждению различных существующих СУБД, их достоинств и недостатков и перспектив развития, причем для каждой отдельно взятой ниши.
...
Рейтинг: 0 / 0
24.09.2004, 17:13
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711032
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EugeneS
Участник
авторНу как же - Вы же заявили, что версионник Оракл круче блокировочников. Sybase ASA является промышленной кроссплатформенной масштабируемой СУБД от КПК и ПК до уровня серверов без накладывания ограничений на кол-во процессоров или RAM, с реализацией механизма блокировщика.

Где доказательства. про масштабируемость?
То есть если софт работает на разных платформах, это еще не значит что он хорошо масштабирутеся , он просто работает.

Где тесты подтверждающие масштабируемость?
Какими тестами это подтверждается ?
Success story по вашему это достаточное подверждение?
Я технический специалист и мне нужны цифры, а не сказки типа "Success story" , коих полно у каждой компании производителе софта.
Это обычное маркетинговое фуфло, и не важно от кого оно от Oracle, Sybase или Microsoft. Cуть от этого не меняется.

авторСоотвествующе Ваши высказывания относились и к ней, потому что в своих высказываниях Вы нигде не уточнили, что Оракл круче блокировочников именно для ниши больших корпоративных хранилищ данных с тяжелой нагрузкой и условиями работы в реалтайме.
Уточнили бы, я и в спор с Вами ввязываться не стал, это не моя ниша и меня на текущий момент не интересуют такие вещи. Вот как появится необходимость освоения и эксплуатации Sybase IQ, тогда и тема для разговоров появиться на этом поприще :) И кстати вопросик - почему не обсуждаете то ? Считаете ниже собственного достоинства или же просто никогда не делали тиражных решений для SMB и не имеете достаточно опыта для обсуждения онных ?

1. Oracle насколько я знаю никогда к Real-time системам и не относился.
Он вообще-то СУБД общего назначения.
2. Почему мне не интерестны решения КПК?
Это очень просто, сделать софт для однопользовательского режима меня уже давно не "возбуждает", а вот софт для того чтобы с ним могли работать одновременно несколько сотен чел. это совсем другое.
Ну это из той серии почему мне не интересен Запорожец, а интересен Мерс.
Это лично мое мнение. Технических решений которые и
использовались при производстве Мерседеса в разы больше.
Далее, достоинства или необходимость механизма мульти-версионности, проявляется при конкурентном доступе, и соответственно мультиверсионность необходима для крупных решений или тяжелых, там где есть конкурентный доступ.
Я очень сильно сомневаюсь , что на КПК есть необходимость конкурентном доступе, поэтому тут подойдет любое решение, хоть плоский файл, хоть sql бд, лишь бы в ресурсы втиснуться.
Или вы сможете там развернуть БД объемом несколько GB ?
Предполагалось, что если вы заговорили про версионность речь идет о конкурентном доступе, а следовательно о крупных решения, ну минимун решениях уровня рабочих групп, ну никак не однопльзовательский режим.

3. Вы вообще на сайт Oracle когда-нибудь заходили ?
Достали вы меня со своими КПК.
Вас интересует есть ли у Oracle для этого продукты.
Да, есть ну и что?
Я не вижу никакого интереса в использовании Oracle на КПК, но если это будет необходимо, это возможно сделать.
То что вас интересует называется
авторOracle Database Lite
Key Product Features

Lightweight Enterprise class database for Windows CE, Palm Computing Platform, Symbian EPOC, and Windows 95/98/NT
Full JDBC & ODBC support on all platforms
Web-based centralized deployment and management on all platforms
Built-in, highly scaleable two-way data synchronization over any connection: Internet, wireless, LAN, etc.

Ну и что дальше?
Уверен у Sybase позиционирование продуктов подобное.
И то, что можно сделать на Enterprise server , нельзя сделать на KПК.
Что здесь удивительного?
Что вы мне хотели доказать?
Что мультиверсиионность не нужна, в однопльзовательском режиме ?
Так это и коню понятно.
...
Рейтинг: 0 / 0
24.09.2004, 17:52
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711109
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
хорошо, хорошо - вы убедили, просто давайте сайбез заменим на mysql, а оракл на сайбез, смотрите как смешно получается:

Действительно MYSQL позиционируется как SMB и я не вижу в этом ничего плохого - это реальная ниша с реальными финансовыми перспективами (в качестве доказательства я привел их success story про yahoo и NASA, а не для того, чтобы меряться). А вот насчет высказывания "MYSQL это для малого бизнеса и с SYBASE совершенно не конкурирует" то я скажу наоборот - это SYBASE в решениях SMB с MYSQL совершенно не конкурирует и проигрывает по всем позициям: цене, требованиям железу, стоимости разрабки и сопровождения решений, администрированию и т.д. Опять же я это говорю не к тому, чтобы "опустить" SYABSE, а чтобы показать Вам, что задач много и для каждой может оказаться эффективным тот инструмент, который на другой задаче показал бы себя неэффективным. Когда Вы признаете сей простой факт и подтвердите тот факт, что SYABASE может быть где то и крут, но не везде и не для всех решений, тогда мы сможем двинуться дальше и сможем завязать с маркетингом, у ? :)

MYSQL является промышленной кроссплатформенной масштабируемой СУБД от КПК (linux и не на таком живет) и ПК до уровня серверов без накладывания ограничений на кол-во процессоров или RAM (к стате mysql нихера и не накладывает), с реализацией механизма блокировщика. Соотвествующе Ваши высказывания относились и к ней, потому что в своих высказываниях Вы нигде не уточнили, что SYBASE круче блокировочников именно для ниши больших корпоративных хранилищ данных с тяжелой нагрузкой и условиями работы в реалтайме. Уточнили бы, я и в спор с Вами ввязываться не стал, это не моя ниша и меня на текущий момент не интересуют такие вещи. Вот как появится необходимость освоения и эксплуатации MYSQL MAX, тогда и тема для разговоров появиться на этом поприще :) И кстати вопросик - почему не обсуждаете то ? Считаете ниже собственного достоинства или же просто никогда не делали тиражных решений для SMB и не имеете достаточно опыта для обсуждения онных ?
---------

комизм в том что я набравшись пивом с умной рожой смогу вам часами рассказывать о крутости mysql ничуть не хуже чем вы мне про сайбез. :)
...
Рейтинг: 0 / 0
24.09.2004, 18:24
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711111
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
авторЭто обычное маркетинговое фуфло, и не важно от кого оно от Oracle, Sybase или Microsoft. Cуть от этого не меняется.
Согласен. Поэтому я и предпочитаю конкретные примеры, а не ссылки на тесты производительности Оракла, куда меня постоянно отсылают.

авторПредполагалось, что если вы заговорили про версионность речь идет о конкурентном доступе, а следовательно о крупных решения, ну минимун решениях уровня рабочих групп, ну никак не однопльзовательский режим.
Уважаемый, все что я говорил относилось к SMB (я даже это подчеркнул), SMB расшифровывается как Small Medium Buiness, то есть это не КПК, а те самые решения для рабочих групп, для которых насклолько я понимаю Вы тоже продолжаете утверждать, что Оракл будет выгоднее, чем использование Sybase ASA :) Если это так, то нам есть о чем поговорить, если Ваши утверждения касаются только крупных хранилищ данных, то тут я не спорщик, у меня другое направление работы, не касающееся этого направления.

авторЧто здесь удивительного?
Что вы мне хотели доказать?
Что мультиверсиионность не нужна, в однопльзовательском режиме ?
Так это и коню понятно.
Я хотел Вам просто доказать, что для каждого решения свой инструмент. я человек терпеливый и готов это доказывать в своем каждом топике :)

авторЭто очень просто, сделать софт для однопользовательского режима меня уже давно не "возбуждает", а вот софт для того чтобы с ним могли работать одновременно несколько сотен чел. это совсем другое.
Ну это из той серии почему мне не интересен Запорожец, а интересен Мерс.
Вы слишком эмоционально относитесь к данному спору. Возбуждает/Не возбуждает, Мерс/Запорожец - нет таких сравнений в мире IT. Не забывайте, что мы с Вами не художники и творцы, а специалисты, которым платят деньги не за перевозбуждение и осознание собственной значимости и крутизны, а за правильный выбор платформы и удачное решение. И уже давно доказано, что уровень специалиста зависит не от крутизны и стоимости платформы, на которой он работает, и даже не от его размера зарплаты, а от умения эффективно и профессионально решать поставленные задачи. Именно поэтому я лично никогда не позволю себе загнуть пальцы перед людьми, работающими на других, пусть и устаревших или неправильных с моей точки зрения технологиях и сказать им "То, на чем Вы работаете ребята - это отстой и прошлый век". Во первых они, работая на этом инструменте, поболее меня знают о достоинствах и недостатках своего продукта, во вторых может оказаться, что для их задач выбранный инструмент гораздо эффективнее и правильнее, чем то, что знаю я, а в третьих это просто не этично по отношению к ним - то же самое, как подьехать на своем "Мерсе", как Вы изволились выразиться, к "Запорожцу" и гордо показать средний палец, а потом засев по самое брюхо на иностранном Мерсе в грязь, с завистью смотреть, как украинский Запор рассекает по бездорожью в сторону своего хутора :)
...
Рейтинг: 0 / 0
24.09.2004, 18:25
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711135
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
2ASCRUS

про SMB и оракл - берем наш пример, берем грубо цены ASE ~ $1K, oracle one ~$5K = разница $4K. я лучше потрачу $4K на оракл, чем буду наблюдать как вы на мои деньги будете воротить плохо маштабируемую систему с ограничения типа "банковский день" с совершенно не гарантируемым результатом. зачем мне это если я даже не могу предпложить в какие деньги мне выльется подержка системы с таким хитрым алгоритмом. а если мне нужно будет баланс с другими табличками связать ? этот геморой не стоит 2х типовых писюков.
...
Рейтинг: 0 / 0
24.09.2004, 18:40
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711139
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EugeneS
Участник
ASCRUS
Вы слишком эмоционально относитесь к данному спору. Возбуждает/Не возбуждает, Мерс/Запорожец - нет таких сравнений в мире IT. Не забывайте, что мы с Вами не художники и творцы, а специалисты, которым платят деньги не за перевозбуждение и осознание собственной значимости и крутизны, а за правильный выбор платформы и удачное решение. И уже давно доказано, что уровень специалиста зависит не от крутизны и стоимости платформы, на которой он работает, и даже не от его размера зарплаты, а от умения эффективно и профессионально решать поставленные задачи. Именно поэтому я лично никогда не позволю себе загнуть пальцы перед людьми, работающими на других, пусть и устаревших или неправильных с моей точки зрения технологиях и сказать им "То, на чем Вы работаете ребята - это отстой и прошлый век". Во первых они, работая на этом инструменте, поболее меня знают о достоинствах и недостатках своего продукта, во вторых может оказаться, что для их задач выбранный инструмент гораздо эффективнее и правильнее, чем то, что знаю я, а в третьих это просто не этично по отношению к ним - то же самое, как подьехать на своем "Мерсе", как Вы изволились выразиться, к "Запорожцу" и гордо показать средний палец, а потом засев по самое брюхо на иностранном Мерсе в грязь, с завистью смотреть, как украинский Запор рассекает по бездорожью в сторону своего хутора :)

Это так кажется на первый взгляд, на самом деле мне безразлично.
Уровень специалиста тем выше , чем проще решения он предлагает.
Есть такой термин технологичность продукта.
Это, когда один сделал, а другой в его отсутствии завсегда исправить может без матюков.
Это когда открываешь чужой код и восхищаешься красотой, того что человек сделал.
А когда он правой ногой левое ухо чешет, ну что тут сказать.
Плакать надо. И при чем тут загибание пальцев?

Ваше решение , которое вы предлагали выше в этом топике, не из этой серии.
Об этом вам говорили куча народа, а вы упорно не соглашались с этим, занимаясь изобретениями "велосипедов".
Знаете я, за 10 лет уже такие "велосипеды" видел, меня редко чем можно удивить.

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

"Быстро, дешево, надежно - выбрать любые два"
(кажется так за точность не ручаюсь).
...
Рейтинг: 0 / 0
24.09.2004, 18:44
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711142
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EugeneS
Участник
Yo!2ASCRUS

про SMB и оракл - берем наш пример, берем грубо цены ASE ~ $1K, oracle one ~$5K = разница $4K. я лучше потрачу $4K на оракл, чем буду наблюдать как вы на мои деньги будете воротить плохо маштабируемую систему с ограничения типа "банковский день" с совершенно не гарантируемым результатом. зачем мне это если я даже не могу предпложить в какие деньги мне выльется подержка системы с таким хитрым алгоритмом. а если мне нужно будет баланс с другими табличками связать ? этот геморой не стоит 2х типовых писюков.

Точно в яблочко.
...
Рейтинг: 0 / 0
24.09.2004, 18:45
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711149
-----------
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
-----------
Гость
EugeneS[quot автор]
Что вы мне хотели доказать?
Что мультиверсиионность не нужна, в однопльзовательском режиме ?
Так это и коню понятно.Не знаю чем занимаются на компьютере кони,
а у меня в виндах режим хоть и однопользовательский, но многозадачный
...
Рейтинг: 0 / 0
24.09.2004, 18:48
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711152
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EugeneS
Участник
----------- EugeneS[quot автор]
Что вы мне хотели доказать?
Что мультиверсиионность не нужна, в однопльзовательском режиме ?
Так это и коню понятно.Не знаю чем занимаются на компьютере кони,
а у меня в виндах режим хоть и однопользовательский, но многозадачный

И вы конечо в разных окнах одновременно сможете создать ну просто сумашедший поток транзакций ?

На КПК надо полагать тоже?

Да, пятница явно удалась.
...
Рейтинг: 0 / 0
24.09.2004, 18:50
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711157
EugeneS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
EugeneS
Участник
EugeneS Yo!2ASCRUS

про SMB и оракл - берем наш пример, берем грубо цены ASE ~ $1K, oracle one ~$5K = разница $4K. я лучше потрачу $4K на оракл, чем буду наблюдать как вы на мои деньги будете воротить плохо маштабируемую систему с ограничения типа "банковский день" с совершенно не гарантируемым результатом. зачем мне это если я даже не могу предпложить в какие деньги мне выльется подержка системы с таким хитрым алгоритмом. а если мне нужно будет баланс с другими табличками связать ? этот геморой не стоит 2х типовых писюков.

Точно в яблочко.

Еще добавлю, если взять разницу в 3к, это для приличного программера на Украине ЗП за 3 мес одному.
Рисковать данными банка за 3 мес зарплату?
Тем более банки не такие бедные, чтобы на таком экономить.

Простой пример задачка "учет материальных ценостей"
Для обычных предприятий стоил -100$
Аналогичный софт для банка обходился в 500-700$
( это было в мою бытность работы в банке, вряд ли что-то по другому стало сейчас ).
...
Рейтинг: 0 / 0
24.09.2004, 18:56
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711182
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Yo!2ASCRUS
про SMB и оракл - берем наш пример, берем грубо цены ASE ~ $1K, oracle one ~$5K = разница $4K. я лучше потрачу $4K на оракл, чем буду наблюдать как вы на мои деньги будете воротить плохо маштабируемую систему с ограничения типа "банковский день" с совершенно не гарантируемым результатом. зачем мне это если я даже не могу предпложить в какие деньги мне выльется подержка системы с таким хитрым алгоритмом. а если мне нужно будет баланс с другими табличками связать ? этот геморой не стоит 2х типовых писюков.
Ограничения "типа банковский день", расчетный месяц в зарплате или кварплате или еще чего - это вообще то условие постановки задачи, описанное законодательством, а не ограничение. Исходя из него Вы по любому в понятиях "опердень" (или банковский день) будете фиксировать остатки/баланс на определенный момент времени. Если же Вы не будете соблюдать постановку задачи и вместо хранения остатков все время пересчитывать аггрегатами по табличкам с входящей информацией, думаю вряд ли найдете для своего продукта клиентов по соотвествующему решению. Ваши же рассуждения, что деньги "пофиг", главное чтобы круто было, мы уже вместе обсуждали и не раз. У меня, например, уже находится в опытной эксплуатации проект "Управление персоналом предприятия", в комплект которого входит расчет заработной платы, что для РФ не самая легкая задача, планируемый обьем клиентов - сотни, требования к продукту - низкие аппаратные требования (вряд ли конторка из 50 человек будет себе навороченный сервак для расчета зп и кадров покупать), низкая конкуретноспособная цена (у нас СУБД ASA будет входить как встраиваемая СУБД в состав продукта и бесплатно поставляться вместе с ним, клиенты будут оплачивать только лицензии из примерного расчета 100$ на одно рабочее место, что снижает общую стоимость всего продукта), масштабируемость (программе должно быть все равно, сколько рабочих мест - 1 или 100 и сколько народу считать - 50 сотрудников или 100 000, во всех случаях нужно высокое быстродействие), нулевое администрирование (интересно посмотреть, как без этого требования можно сопровождать свой продукт у сотен клиентов) и функциональность (из за непрерывного изменения трудового и налогового кодекса РФ и сложности алгоритмов расчетов неплохое решение для такой задачи - это перенос всей бизнес-логики и расчетов на ХП, с организацией хранения истории изменения самих алгоритмов расчета, которое вытекает из за возможности изменения почти любой входящей информации пользователями задними числами, с последующим сторнированием в расчетах, т.е. в закрытых периодах, наличие которых Вы упорно отвергаете). Вот пожалуйста - вот Вам и задача, на которой как раз Оракл окажется не выгодным и для которой как раз на нем кроме геммороя с установкой и администрированием и завышенной стоимости разработки и цены продукта ничего не получишь.

авторберем грубо цены ASE ~ $1K, oracle one ~$5K
На всякий случай: Sybase ASA (разработчик - iAnywhere Solution, бывший Watcom) != Sybase ASE (разработчик - Sybase) ни в чем, разве что на уровне поддержки в качестве дополнительного диалекта TSQL для совместимости с ASE. Я с Sybase ASE не работал и поэтому не могу обсуждать ее достоинства, недостатки и ценовую политику. Так что давайте обсуждать, то что хорошо знаете Вы и то, что неплохо знаю я :)
...
Рейтинг: 0 / 0
24.09.2004, 19:08
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711195
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
EugeneSВаше решение , которое вы предлагали выше в этом топике, не из этой серии.
Об этом вам говорили куча народа, а вы упорно не соглашались с этим, занимаясь изобретениями "велосипедов".
Знаете я, за 10 лет уже такие "велосипеды" видел, меня редко чем можно удивить.
Ну давайте и здесь померяемся :) Я за 13 лет профессиональной работы тоже не мало велосипедов насмотрелся, ими вообще никого не удивишь :) А сам лично велосипедов не изобретаю - Вас послушать, так я только и делаю ежедневно, что борюсь с блокировками своих СУБД :) Повторяю еще раз лично для Вас - здесь задали вопрос, как вот это сделать на блокировочнике , я подал идею, как это можно было бы сделать , если уж сильно бы прижало именно так сделать . Сам я так никогда не делаю , потому что у меня нет дурной привычки бороться с блокировками и вообще механизмами работы СУБД, наоборот я их люблю, ценю и пользуюсь их преимуществами, там и для тех задач , где они действительно являются преимуществами и в реальной жизни никогда не делаю так, как предложили в примере по той простой причине, что так на блокировочнике не принято делать . Думаю теперь мы вполне достаточно осветили вопрос велосипедов, убедились в высоком профессионализме друг друга и не будем обвинять других в том, чего нет, у ? :)

авторДа, пятница явно удалась.
Угу. А вообще это полезно - учиться правильно спорить, не скатываясь на голословные утверждения и безосновательные выводы, так что день прошел не зря, я получил массу удовольствия :)
...
Рейтинг: 0 / 0
24.09.2004, 19:22
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711228
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
мне не мнтересны сказки про ваш чудесный велосипед, вы это лучше клиентам своим рассказываете. мы обсуждали конкретный пример с конкретной реализацией.
итак я утверждаю что реализация SMB задачи "онлаин казино" по описанаму вами алгоритму где 100 онлаин клиентов будет на оракле дешевле, надежней, более маштабируема и прочее. аргументы:

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

ЗЫ. oracle standart one стоит $149 на рабочее место vs 100$ сайбеза. это составляет 10 молочных коктелей по ценам Pulp Fiction ...
...
Рейтинг: 0 / 0
24.09.2004, 19:42
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711229
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
killed авторЯ бы сказал - нашлепка сверху. Изначально же в Oracle не было этой фичи с получением данных из сегмента отката. Потом добавили.

Сможешь вспомнить, когда, в каком году эта "нашлепка" была сделана?


Я могу ошибаться конечно, но кажется это было году в 94, может раньше.
Там какая-то новая версия Оракла выходила, и они писали, что вот де - появилась новая такая фича. Это я точно помню, читал. Возможно, немного напутал год, но уж что не в 85, как тут говорили - это уж точно. И еще - сергмент отката был (наверное) всегда, а вот читать из него данные Оракл не всегда умел.
...
Рейтинг: 0 / 0
24.09.2004, 19:42
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711236
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
автор Сам я так никогда не делаю, потому что у меня нет дурной привычки бороться с блокировками и вообще механизмами работы СУБД, наоборот я их люблю, ценю и пользуюсь их преимуществами, там и для тех задач, где они действительно являются преимуществами и в реальной жизни никогда не делаю

OK, считаем тот алгоритм не удачным ! предложите другой, вы профи с 13 летним стажем для вас это не должно составить труда. задача "онлайн казино" - есть баланс, есть движение по счетам, есть длинные отчеты.
...
Рейтинг: 0 / 0
24.09.2004, 19:48
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711265
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
авторитак я утверждаю что реализация SMB задачи "онлаин казино" по описанаму вами алгоритму где 100 онлаин клиентов будет на оракле дешевле, надежней, более маштабируема и прочее. аргументы:
Пожалуйста более детально опишите постановку задачи. Я никогда в жизни не писал онлайн-казино и даже не играл, так что без постановки не могу оценить Ваше высказывание насчет эффективности и стоимости разработки и сопровождения данного решения для конкретных СУБД.

автор- ограничение в банковский день не приемлимо, пусть даже это трижды прописано в сотнях законах РФ.
Сурово, ничего не скажешь :)

автор- оплата зряплаты для вышеописаного алгоритма может легко превысить разницу в лицензиях оракла и сайбеза.
- если в будущем баланс нужно связать с другими табличками то сумма зряплаты может превысить лицензию EE edition оракла.
Прошу уточнения, какой именно алгоритм имеется ввиду ? Если Вы насчет таблички, в которой хранятся аггрегатные значения баланса на каждого клиента, то еще хочу поинтересоваться - а Вы правда что ли каждый раз баланс рассчитываете по всей истории клиентов ? (просто стало интересно)

Yo!ЗЫ. oracle standart one стоит $149 на рабочее место vs 100$ сайбеза. это составляет 10 молочных коктелей по ценам Pulp Fiction ...
Еще пару вопросиков - разрешается ли мне включать в комплект своего ПО сам сервер бесплатно, есть ли у этой версии Оракла какие либо ограничения на размер БД, границу поддержки конфигурации сервера и т.д. Так же интересует - могу ли я включить Оракл как пакет для инсталяции вместе со своим приложением (например в InstallShield), чтобы он автоматически инсталировался при инсталяции программы ?

Ну и последние вопросики - насколько эта версия Оракла требует наличия администратора, может ли она после инсталяции самостоятельно настроиться и привязаться к конфигурации сервера клиента и работать без какого либо требования, за исключением критических ситуаций, к присутствию человеческого фактора (в том числе по расписанию делать проверки, различные виды Backup-ов, в онлайне, в офлайне, с зеркалированием на другой сервер, с их хранением на другом сервере и т.д.). И можно ли средстами Оракла подключить к своему ПО реакцию на эти критические ситуации и написав свой интерфейс только силами клиента восстанавливать работоспособность БД от поднятия бакупов и накладывания логов, до автоматической перезагрузки структуры и данных БД в новую ?

P.S. Про криптографию БД и логов не спрашиваю, и так знаю, что в Оракле ее нет :)

авторOK, считаем тот алгоритм не удачным ! предложите другой, вы профи с 13 летним стажем для вас это не должно составить труда. задача "онлайн казино" - есть баланс, есть движение по счетам, есть длинные отчеты.
Для SMB решения, где максимальное кол-во пользователей 100 и БД не дотягивает до 100гб, вполне приемлимым решением будет повесить на табличку "Движение" триггер AFTER INSERT FOR EACH STATEMENT, который будет к балансу просто прибавлять/отнимать суммы, прошедшие по движению в проводимой транзакции, причем одним запросом. Длинного отчета в SMB к сожалению не получится из за кол-ва клиентов и обьема БД, можно правда смодулировать долгий отчет, однако в данном случае в ХП такого отчета будет достаточно обьявить DECLARE LOCAL TEMPORARY TABLE NOT TRANSACTIONAL, в режиме serializable загрузить в нее нужные данные с баланса и сделав COMMIT делать свой долгий отчет сколько влезет. Даже если у 100 клиентов будет по 100 счетов, то это будет ровно 10 000 записей в балансе, которые в нелогируемую времянку перенесутся буквально за секунды и никто из клиентов, продолжающих пополнять свой счет особо не пострадает.

Вот что касается решения для SMB, причем без всяких велосипедов, где правильность и целостность данных будет гарантировать сама СУБД, разруливая читателей и писателей на блокировках. Для более обьемной БД решение не буду приводить, так как этим не занимался и тут сначала требуется внимательное изучение постановки задачи и составления списка граблей, на которые можно было бы наступить.
...
Рейтинг: 0 / 0
24.09.2004, 20:20
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711275
Зл0й
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зл0й
Участник
По поводу предложенного ASCRUS решения, согласен с Yo, монитора транзакций там действительно нет. Ибо процесс выполняющий транзакции там ОДИН, соответственно координировать там нечего. Мы просто поставили транзакции в очередь и выполняем по одной. Зачем нам тогда вообще СУБД? При таком подходе можно вообще все в файлы писать, только надо написать фоновый процесс архивирующий логи и приблуду позволяющюю их накатить "если что".

ASCRUS
1. С помощью временных локальных и глобальных таблиц
2. С помощью автоматически пересчитываемых аггрегатных постоянных таблиц
3. С помощью специального значения timestamp
4. Проектирование входящих таблиц так, чтобы в них только добавлялась, но редко изменялась и тем более удалялась информация
5. С помощью анти-фантомной блокировки, сужающей круг блокирующихся записей, если СУБД это умеет делать и присутствует подходящий уникальный индекс
6. Тщательным продумыванием применения наиболее подходящих для разных задач уровней транзакций
7. Проектированием "коротких" транзакций
8. Созданием таблиц-буферов
9. Созданием параллейных потоков с помощью событий и агентов расписаний.


По первому пункту - временные таблицы, это конечно хорошо, как и различного рода буфера и прочее. Концептуально все это - некий кэш не гарантирующий согласованное чтение. А чтобы достичь согласованное чтение мы вручную проверяем timestamp. Вдобавок есть куча ограничений на то какие таблицы можно совместно использовать в одной транзакции. Все это жутко неудобно, трудоемко в реализации, и черевато трудноустранимыми ошибками. Извините за грубое слово, но это - геморрой.

Что до параллельных потоков и их координации с помощью событий, уважаемый ASCRUS видимо плохо представлячет масштаб этой задачи. Задача - что-то типа BEA Tuxedo написать, грубо-то говоря. Беремся за такую задачу, или ну его нафиг? Я лично не берусь, ибо ресурсов и бюджета у меня на такое не хватит. Если у вас хватит - рад за вас. Иначе получится некий полиатив.

Тщательной продумывание транзакций - просто "здоровый подход" к решению любой задачи. В том числе и данной.

А вот проектирование "коротких" транзакций - вынужденная необходимость в СУБД-блокировщиках. В СУБД-версионниках в случае состязания читатели-писатели такого требования нет. В случае состязания писатели-писатели, на уровне идеи, проблема решается одинаково вне зависимости от СУБД. Синтаксис разный, поведение по умолчанию разное, а принцип "разруливания" один и тот же - блокировка.

ASCRUS
Ничего себе чепуха. Вот обьясните мне непонимающему что будет в следующей ситуации:
1. Есть Table1 и связанная с ней по FOREIGN KEY Table2.
2. Транзакция A начала добавлять записи в Table2, ссылаясь на родителей, уже существующих в Table1
3. Чуть позжее транзакция B начала выполнять запрос:
DELETE FROM Table
WHERE Table1_id NOT IN (SELECT Table1_id FROM Table2);
4. Пока транзакция A продолжала возиться, транзакция B выполнила COMMIT -ведь Оракл ничего не блокирует и подзапрос читатель B не будет ждать писателя A, а просто успешно удалит записи из таблицы Table1, на которые ссылаются добавляемые в этот момент из транзакции A, ведь правда ?
5. Транзакция A выполняет наконец таки COMMIT, делает CHECK ON COMMIT (кстати проверки всегда только на коммите выполняются ?), получает ошибку FOREIGN KEY на несуществующих родителей и откатывается.

Я все правильно понял или у Оракла есть механизм регулирования таких ситуаций ?


Совершенно верно поняли, уважаемый ASCRUS, такой механизм в Оракле конечно есть. В Оракле по умолчанию ограничения целостности проверяются сразу, а не по коммиту. Если уровень изоляции read_commited (по умолчанию), то на шаге 3 ваша транзакция В заснет на блокировке. Соответственно commit она выполнить не сможет. А когда транзакция А выполнит commit, то транзакция В получит отлуп "ORA-02292:integrity constraint ... violated - child record found".

Естественно в Оракле constraint может проверяться не сразу, а по commit'у. Последний в оракле называется deffered. Кроме того он может быть "on delete set null" или "on delete cascade". Играясь с уровнями изоляции транзакций, разными типами constraint'ов, и select ... for update nowait я могу добиться ЛЮБОГО разумного (и иногда неразумного) поведения в данной ситуации. Скажите какое "разумное" поведение в данной ситуации вас устраивает, а я вам скажу как это сделать в Оракле с использованием стандартных механизмов данной СУБД.
...
Рейтинг: 0 / 0
24.09.2004, 20:35
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711292
onstat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat
Гость
Yo!
итак я утверждаю что реализация SMB задачи "онлаин казино" по описанаму вами алгоритму где 100 онлаин клиентов будет на оракле дешевле, надежней, более маштабируема и прочее. аргументы:


Yo!

OK, считаем тот алгоритм не удачным ! предложите другой, вы профи с 13 летним стажем для вас это не должно составить труда. задача "онлайн казино" - есть баланс, есть движение по счетам, есть длинные отчеты.



Опа ........

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

По oracle никакого решения пока представлено вообще небыло.

Когда ASCRUS предлагал решение, задача была очень общей,
теперь мы ее конкретизируем и расставим все точки на i.


Предлагаю Отчеты
Кличестово(сумма) фишек в банке?
Количество(сумма) фишек в игре(размер ставок на текущий момент).
Количество (сумма) фишек выигранных игроками?
количество (сумма) фишек проигранных игроками?

Как будем идентифицировать играков и их ставки, если будем?

Главный критерий многопользовательский доступ.

Транзакции предлагаю грузить через sqlldr паралельно в 10-50 сессий.
Отчеты формировать паралельно(одновременно) через sqlplus одновременно с загрузкой.

количество транзакций ~10 000 000 .

Жаль я незнаю названия соответствующих утилит для Sybase.

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

Согласны ?

С уважением onstat.
...
Рейтинг: 0 / 0
24.09.2004, 21:10
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711295
onstat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat
Гость
onstat
количество транзакций ~10 000 000 .




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


нет это слишком просто, такое я на mysql гораздо эфективней реализую.

2ASCRUS
у нас стремительный 21 век и передовые технологиепусть будет система расчета риска и прогнозирования. берем наших юзеров и раскладываем на тучу профайлов. типа страна, диапозон даты регистрации, текущий баланс, кол-во выйграных партий, и т.п. это дело анализируем и получаем что-то типа англичане с карточкой маэстро в bank of amercica играющие в преферанс от 3х до 5 лет, зарабытывающие хоть в одной игре 50 очей в пуле имеют высокий шанс увеличить свой текущий баланс. расставляем грузы и в результате у нас некая система которая прогнозирует выйгрыши и если прогноз зашкаливает некую отметку мы сигнализуруем. естественно подробности алгоритма нам не важны главное что мы знаем что оно предположительно расчитывается не менее 5 минут и для расчета ему нужен лог выйгрышей и текущий баланс. мы ставим этот алгоритм в джоб раз в 10 минут чтоб вовремя сигнализировать (прогонять такое во время каждой транзакции не реально).

теперь система - есть лог выйгрышей/проигрышей, баланс игрока, расчет риска и 10 транзакций в секунду в лог выйгрышей/проигрышей.

ЗЫ. не нравится казино (я там тоже небыл) предложите сферу деятельности я легко поменяю персонажи.
ЗЗЫ. мне казалось что по меркам штатов SMB это оборот в $10 лимонов, а 50 юзеров это ниша фокспро. но готов поверить наслово что это не так :)
...
Рейтинг: 0 / 0
24.09.2004, 22:30
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711314
Зл0й
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зл0й
Участник
я и ёжик
Зл0й

Например в случае serializable СУБД нам гарантирует что все данные которые мы читаем, будут "по состоянию на время начала читающей транзакции".

Это не так, в случае serializable СУБД нам гарантирует, что в результате выполнения некоторого набора транзакций мы получим результат который соответствует некоторому последовательному выполнению этих транзакций.
В случае чисто-блокировочного механизма реализации менеджера транзакций, все данные которые мы читаем в Serializable будут скорее "по состоянию на момент КОНЦА читающей транзакции".

Я не уточнил, что имел ввиду поведение Оракла, а не поведение предписанное ANSI-стандартом, наблюдаемое в СУБД-блокировщиках. Согласно ANSI-стандарту у транзакций должна быть иллюзия их последовательного выполнения. Если транзакции друг другу мешают, то одна работает а остальные её ждут. Достигается это с помощью блокировки. В Оракле иллюзии последовательного выполнения нет. То есть, в Оракле, если обе сессии serializable:

время: сессия: событие
-------------------------------
T0: S0: select max(id) into :s0_var from my_table --s0_var := 25
T0: S1: select max(id) into :s1_var from my_table --s1_var := 25
-------------------------------
T1: S0: insert into my_table values(s0_var, 'session 0'); commit; --отработает нормально
T1: S1: insert into my_table values(s1_var, 'session 1') --вернет ошибку ORA-00001: unique constraint ... violated

Иллюзия того что сессии работают последовательно нарушена. Согласно ANSI-стандату она должна быть. В СУБД-блокировщиках она достигается путем блокирующего чтения, в ущерб масштабируемости. В Оракле, если захочу, я тоже могу иметь блокирующее чтение с помошью select ... for update и достигну того же результата что и блокировщик. А могу и не иметь, если не хочу. Могу например использовать для генерации id такую штуку как sequence. Масштабироваться будет заметно лучше чем selec max(id)+1 с блокировкой.
...
Рейтинг: 0 / 0
24.09.2004, 22:41
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711322
Зл0й
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зл0й
Участник
Что касается задачи с казино, тут как раз все не так уж и страшно. Берем 10 сессий sqlldr говорим им что-то типа rows=1, ибо мы пытаемся имитировать короткие OLTP-транзакции. Казалось бы случай для Оракла хреновый - как только транзакция закоммичена оракл имеет право писать поверх нее.

Как с этим бороться: берем некислый (на пол-терабайта) дисковый массив, RAID 1+0, и говорим что это наш любимый rollback storage. Дальше тестируем. Не хватает - берем еще один массив на 500 гиг. Опять не хватает? Берем второй сервер ставим его в hot standby и открываем на чтение. Первый сервер, где происходит OLTP, присылает второму логи, второй их накатывает. Отчеты гоняем на втором сервере, в "near real time". То есть отчеты будут с незначительной задержкой, но они будут заведомо согласованные, без ошибок обусловленных фантомами и "грязным чтением". Это если мы "не мудрствуя лукаво" решаем эту задачу в лоб.

Можно почесать репу, померить responce time, понять что при достаточно большом объеме транзакций НИКАКАЯ из современных СУБД эту задачу сама по себе не решает. Просто происходит "затык" чисто по записи, даже без чтения. Тогда к СУБД прицепляют внешний монитор транзакций, типа например Tuxedo. И живут долго и счастливо. Можно еще "раскидать" поток транзакций по узлам кластера или просто по разным базам, но тогда с онлайновыми отчетами придется попрощаться. Ибо хорошо нагруженные OLTP-базы репликацию не очень любят. Хотя, можно к каждой OLTP-базе прицепить standby и гонять отчеты по ним, используя репликацию.

К чему это я все говорю: все эти фичи типа "hot standby", растут из возможности одновременно писать в базу (накатывать лог) и читать базу. В Оракле проблема большого траффика решается этими фичами, адекватной железякой и кое-где дополнительным софтом типа например Tuxedo. Безо всякого изобретательства "на коленке".

А по поводу пожирания ресурсов - вам закон Мура напомнить? У сегодняшних карманных кантуперов 32-х битные RISC-процессора частотой в 233 мгц. У меня не так давно одна СУБД работала на 32-х битной 100мгц RISC-машине HP 715/100 под hp-ux. Не очень шустро работала, но работала. "Раздетая" версия Оракла для карманных компьютеров есть. Нормально работает, "карманные задачи" вполне решает. Для меня аргумент "оно работает на 486 машине" уже давно не аргумент. Железо настолько дешевле софта, что купить машину обычно - "не вопрос".
...
Рейтинг: 0 / 0
24.09.2004, 23:20
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711495
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
c127
Гость
2 Зл0й

>Для меня аргумент "оно работает на 486 машине" уже давно не аргумент. Железо настолько дешевле софта, что купить машину обычно - "не вопрос".

Бывают всякие морозоустойчивые, удароустойчивые компьютеры, они существенно (в разы) дороже обычных и если таких компьютеров нужно поставить несколько, то это аргумент. Стоят там какие-то смешные по нынешним временам процессора. Не знаю почему. Кроме того, пентюхи требуют активного охлаждения, а 486 нет. Тоже может оказаться решающим фактором при некоторых обстоятельствах. Кроме того бывают бездисковые компьютеры и задачи для них, и очевидно нужно чтоб сервер ел поменьше ресурсов.

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

не стоит смешить людей 486ми, такие машины в SMB работает только у отмороженых руководителях. какие к черту морозо устойчивые в офисе в москве ? вы откуда с дальнего востока ? там много SMB ?
зайдите на hp.com, dell.com и т.п. ну посмотрите что такое small buisness - это не бизнес по собиранию бутылок, это 2х процесорные xeion'ы, это oracle standart one за $150. похоже вы будете удивлены, но даже маленькому бизнесу тоже нужны стабильные системы, а не собраное на коленке безобразие из деталей найденых на помойке.

я очень уважаю сайбез он врядли сможет составить конкуренцию foxpro или mysql на 486 ...
...
Рейтинг: 0 / 0
25.09.2004, 14:09
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711606
onstat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat
Гость
Зл0й

А могу и не иметь, если не хочу. Могу например использовать для генерации id такую штуку как sequence. Масштабироваться будет заметно лучше чем selec max(id)+1 с блокировкой.



Все уважающие себя базы данных имеют либо sequnce либо автоинкрементальный тип. Не надо делать необоснованные заявления если не знаете.


Yo!
нет это слишком просто, такое я на mysql гораздо эфективней реализую.


Типа съехал ;-)

Yo!
2ASCRUS
у нас стремительный 21 век и передовые технологиепусть будет система расчета риска и прогнозирования. берем наших юзеров и раскладываем на тучу профайлов. типа страна, диапозон даты регистрации, текущий баланс, кол-во выйграных партий, и т.п. это дело анализируем и получаем что-то типа англичане с карточкой маэстро в bank of amercica играющие в преферанс от 3х до 5 лет, зарабытывающие хоть в одной игре 50 очей в пуле имеют высокий шанс увеличить свой текущий баланс. расставляем грузы и в результате у нас некая система которая прогнозирует выйгрыши и если прогноз зашкаливает некую отметку мы сигнализуруем. естественно подробности алгоритма нам не важны главное что мы знаем что оно предположительно расчитывается не менее 5 минут и для расчета ему нужен лог выйгрышей и текущий баланс. мы ставим этот алгоритм в джоб раз в 10 минут чтоб вовремя сигнализировать (прогонять такое во время каждой транзакции не реально).

теперь система - есть лог выйгрышей/проигрышей, баланс игрока, расчет риска и 10 транзакций в секунду в лог выйгрышей/проигрышей.



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

Для справки ведущий разработчик(идеолог) получает $200 000 в год.
И еще десяток его помошников около $100 000.
И коллектив кодеров около 20 чел по $50 000 каждый.

2ASCRUS Соглашайся это хорошие деньги и интересная работа.

А Меня возьмете?


с уважением, onstat.
...
Рейтинг: 0 / 0
25.09.2004, 16:48
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711627
Фотография Scott Tiger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Scott Tiger
Участник
Зл0йМогу например использовать для генерации id такую штуку как sequence. Масштабироваться будет заметно лучше чем selec max(id)+1 с блокировкой.

Лучше, но нелинейно. Для прокачки больших объёмов данных сиквенсами лучше не пользоваться. В OLTP проблем обычно нет (хотя, может, я не видел OLTP с таким количеством insert-ов в секунду :) ).
...
Рейтинг: 0 / 0
25.09.2004, 17:53
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32711724
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
c127
Гость
2 Yo!

>похоже вы будете удивлены, но даже маленькому бизнесу тоже нужны стабильные системы, а не собраное на коленке безобразие из деталей найденых на помойке.

Я вроде не упоминал малый бизнес и нестабильные системы. Малые компьютеры автоматически не значат малый бизнес. Компьютеры, о которых я говорил как раз и отличаются тем, что не собраны на коленке, а собраны особо тщательно из специално изготовленных деталей. Стоит такая машина почему-то $2-3K и дешевле не найдете, хотя процессор там смешной.

>не стоит смешить людей 486ми, такие машины в SMB работает только у отмороженых руководителях. какие к черту морозо устойчивые в офисе в москве ?

Москвой планета не ограничивается, бывают и другие города. Хотелось бы посмотреть на руководителя, сидящего в офисе среди сугробов, например, на автоматической заправке для грузовиков, работающей на Аляске. Аляска это такой штат в США, который когда-то принадлежал России. Там холодно почти как в Сибири. А на такой же заправке, например, в Техасе - жарко, и тоже нет руководителя поблизости.

>я очень уважаю сайбез он врядли сможет составить конкуренцию foxpro или mysql на 486 ...

Еще как. Что, фокспро и мускл для покетов уже появились? А если да, то когда и какие там ограничения? А ASA появилась сразу, ограничения только на репликацию (из-за выньЦЕ), т.е. это тот же сервер, что и для обычного компьютера. Но кроме того что ASA ресурсов жрет не больше (подозреваю что меньше) чем фокспро или mysql, он еще и полноценный SQL сервер.

Подумайте о чем Вы спорите. Вы фактически настаиваете на том, что для решения абсолютно всех задач оракл подходит лучше любого другого продукта. Но ведь это несерьезно. Всегда можно найти задачу, для которой наперед заданный продукт подходит лучше чем другой заданный продукт. Как сказал Гедель: мощность задач - R (континуум), а мощность решений - N (счетное множество).
...
Рейтинг: 0 / 0
26.09.2004, 00:02
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32712107
andy st
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andy st
Гость
Yo!2 c127

не стоит смешить людей 486ми, такие машины в SMB работает только у отмороженых руководителях. какие к черту морозо устойчивые в офисе в москве ? вы откуда с дальнего востока ? там много SMB ?
зайдите на hp.com, dell.com и т.п. ну посмотрите что такое small buisness - это не бизнес по собиранию бутылок, это 2х процесорные xeion'ы, это oracle standart one за $150. похоже вы будете удивлены, но даже маленькому бизнесу тоже нужны стабильные системы, а не собраное на коленке безобразие из деталей найденых на помойке.

я очень уважаю сайбез он врядли сможет составить конкуренцию foxpro или mysql на 486 ...

стоит промышленная машинка... p100... 16M памяти... qnx4.25... sybase sql anywhere 5.5... пашет лет 5: принимает, обрабатывает, выдает данные о технологическом процессе... в самом худшем случае, если уж сильно поплохеет - богатые дяди в Москве недосчитаются 2-3M$... не считая репутации...
забыл добавить: рабочий диапазон температур: -30 - +40, вибрация, пыль, в т.ч. металлическая...
это я к тому, что если сравнивать с этой стороны, то все
Yo! 2х процесорные xeion'ы, это oracle standart one за $150.
выглядят не более, чем
Yo!собраное на коленке безобразие из деталей найденых на помойке.
...
Рейтинг: 0 / 0
27.09.2004, 09:13
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32712333
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
onstat
Yo!
OK, считаем тот алгоритм не удачным ! предложите другой, вы профи с 13
Давайте конкретизируем задачу,
а потом предоставим схему базы и логику работы, а тогда уже будем меряться перцами.


Кончайте маразмом заниматься. Есть определения ANSI-шные, и реализации их в контретных серверах. Если Oracle позволяет читателям в длинных транзакциях читать старые данные на фоне выполнения OLPT, то как я ни люби MS SQL и Sybase, но это лучше, чем реализация предоставляемая ими. Какие еще блин примеры надо ?
Будете тут пол года в записейках копаться - заблокировал, не заблокировал, старую прочитал , новую изменил ...
Тьфу!!
...
Рейтинг: 0 / 0
27.09.2004, 11:29
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32712438
onstat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat
Гость
MasterZiv
Кончайте маразмом заниматься. Есть определения ANSI-шные, и реализации их в контретных серверах. Если Oracle позволяет читателям в длинных транзакциях читать старые данные на фоне выполнения OLPT, то как я ни люби MS SQL и Sybase, но это лучше, чем реализация предоставляемая ими. Какие еще блин примеры надо ?
Будете тут пол года в записейках копаться - заблокировал, не заблокировал, старую прочитал , новую изменил ...
Тьфу!!


Не спорю для общего случая это лучше.
Это как коробка автомат в общем случае лучше ручного переключателя скоростей, странно, что я не видел внедорожников с коробкой автомат.
Почему, она же лучше? Но наверное, не для приложения внедорожник.

Есть требования накладываемые приложением,
за счет упрощения по неблокирующему чтению на блокировочнике
конкретное приложение можно зделать более производительным и гибким.
Это мы бы и доказали, в случае тестирования конкретного приложения
на блокировочнике по сравнению с общим решением от Oracle.

Что мне еще нравится в блокировчниках, что я могу проверить, что и как делает любая пользовательская сессия( вкючив грязное чтение на своей сессии).


С уважением onstat.
...
Рейтинг: 0 / 0
27.09.2004, 12:12
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32712479
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
2andy st

тут речь идет о SMB, а не промышленых предприятиях. давайте уж на нем сосредоточимся, а то какие-то КПК, промышленые агрегаты ... не я конечно и тут шпециалист :) но давайте сначала с SMB разберемся.


к стате а где линк на саксес стори про $2-3M ? или опять все на словах ?
вот например у оракла есть решения для хим производства
http://www.oracle.com/pls/cis/Profiles.print_html?p_profile_id=6236
там кексы Saved $2-$4 million in hardware and facility expenses
...
Рейтинг: 0 / 0
27.09.2004, 12:27
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32713119
andy st
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andy st
Гость
Yo!2andy st
тут речь идет о SMB, а не промышленых предприятиях. давайте уж на нем сосредоточимся, а то какие-то КПК, промышленые агрегаты ... не я конечно и тут шпециалист :) но давайте сначала с SMB разберемся.

ну нифига себе " разберемся с SMB"... ;)
постоянно упомнаются, как требования: банковский день, баланс в реальном времени и т.п.
я это к тому, что SMB - это не только зарплата, накладные и прочие финансы (как по москве), но и производство (как по России). ;)
и задачи там не менее ответственные с финансовой точки зрения.
я бы сказал, что даже более: ибо нет производства - нет финансов.
а упомянул я ту систему потому, что работает там sybase.
как танк... а оракула, при всей его многоплатформенности, на qnx 4.25 нету...
Yo!
к стате а где линк на саксес стори про $2-3M ? или опять все на словах ?
вот например у оракла есть решения для хим производства
http://www.oracle.com/pls/cis/Profiles.print_html?p_profile_id=6236
там кексы Saved $2-$4 million in hardware and facility expenses
описал я не success story, а возможную (и, тьфу-тьфу-тьфу, не случавшуюся еще ни разу) malfunction story. как мне кажется, такие стори вряд ли ЛЮБОЙ производитель СУБД будет выкладывать на своем сайте, хотя такие истории, как пить дать, прут косяками... ;)
...
Рейтинг: 0 / 0
27.09.2004, 15:56
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32713300
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
авторЭто как коробка автомат в общем случае лучше ручного переключателя скоростей, странно, что я не видел внедорожников с коробкой автомат.

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

да их как грязи

оффтоп,
Ездил на таком - гамно редкостное, ему всегда нужно подсказывать, что вот ЗДЕСЬ нужна ПЕРВАЯ, а то "слишком умный" и не тянет ни хрена на второй.
...
Рейтинг: 0 / 0
27.09.2004, 22:27
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32714028
DimaR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DimaR
Участник
to Рыжий Кот
Что за бред несут в последних нескольких топиках про "автомат",

Сторонники MSSQL всегда говорили, что его не надо настраивать, он сам все делает.

В то время как возможности настроек, и анализа работы СУБД в Oracle, называли сложными и ставили это в укор Oracle.
...
Рейтинг: 0 / 0
28.09.2004, 10:04
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32714103
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
DimaRto Рыжий Кот
Что за бред несут в последних нескольких топиках про "автомат",

Сторонники MSSQL всегда говорили, что его не надо настраивать, он сам все делает.

В то время как возможности настроек, и анализа работы СУБД в Oracle, называли сложными и ставили это в укор Oracle.



Вы немножко путаете, речь шла о разработке софта, и программировании
бизнесс логики.
Професиональный разработчик приложения,
должен знать все хорошее и плохие стороны используемого продукта и использовать или обходить их.

Причем тут настройка сервера?


С уважением, onstat
з.ы. Складывается впечатление, что на этом форуме я нахожусь среди
футбольных фанов, а не профессионалов в области баз данных.
...
Рейтинг: 0 / 0
28.09.2004, 10:34
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32714636
DimaR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DimaR
Участник
to onstat


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

Сами придумали или в какой газете прочитали?
В какой если не секрет?


Это мы бы и доказали, в случае тестирования конкретного приложения
на блокировочнике по сравнению с общим решением от Oracle.
Так доказали или нет?
Можно опубликовать результаты тестирования?


Что мне еще нравится в блокировчниках, что я могу проверить, что и как делает любая пользовательская сессия( вкючив грязное чтение на своей сессии).
Это очень сомнительное достоинство.
...
Рейтинг: 0 / 0
28.09.2004, 13:38
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32714795
Константин Лисянский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Константин Лисянский
Участник
Что мне еще нравится в блокировчниках, что я могу проверить, что и как делает любая пользовательская сессия( вкючив грязное чтение на своей сессии).

Ну, для этого, наверное, средства администратора существуют. При чём здесь грязное чтение?


С уважением,
Константин Лисянский
http://lissianski.narod.ru
...
Рейтинг: 0 / 0
28.09.2004, 14:27
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32714877
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
к стате а зачем сервер субд на КПК ? разве не достаточно в файлик писать, конкурирующих транзакций нет ... зачем сервер ?
и на счет отмороженых прцессоров, разве на агрегатах не просто датчики стоят ? зачем проц (слабый но дорогой) на него взгромождать ?
...
Рейтинг: 0 / 0
28.09.2004, 14:59
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32714952
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Yo!к стате а зачем сервер субд на КПК ? разве не достаточно в файлик писать, конкурирующих транзакций нет ... зачем сервер ?
А что - файлики уже позволяют делать репликации с центральным сервером ? Можно конечно альтернативно - каждый раз с центральной БД все данные в файлики выкачивать и носить их с собой, роясь и правя их в нотепаде, или же всегда держать КПК в онлайн и через веб напрямую работать :) Вот только как то чего то неудобно получается.
...
Рейтинг: 0 / 0
28.09.2004, 15:22
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32715010
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
DimaRto onstat


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


Сами придумали или в какой газете прочитали?
В какой если не секрет?


Я это сказал на основании опыта
эксплуатации и разработки систем для разных СУБД.
Это мое ИХМО.

DimaR

Это мы бы и доказали, в случае тестирования конкретного приложения
на блокировочнике по сравнению с общим решением от Oracle.
Так доказали или нет?
Можно опубликовать результаты тестирования?


Я не получил ни от кого из учасников форума согласия участвовать в тестировании, условия смотрите по топику выше.
Я готов сгенерировать входные данные и представить решение
для блокировочника (СУБД Informix). Решение от защитников Oracle можете предоставить вы.
Я могу протестировать для платформ informix7,9 и oracle 8, 9 на приблизительно одинаковом железе. 4xPIV Xeon + Raid.

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

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

DimaR

Что мне еще нравится в блокировчниках, что я могу проверить, что и как делает любая пользовательская сессия( вкючив грязное чтение на своей сессии).
Это очень сомнительное достоинство.

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

Константин Лисянский

Ну, для этого, наверное, средства администратора существуют. При чём здесь грязное чтение?



А как вы думаете как это делают утилиты администратора на блокировочниках?
Вы не поверите, они включают грязное чтение, потому, что по другому увидеть
данные заблокированные другой сессией просто невозможно.
Или вы никогда не видели(делали) "progress bar" для базы блокировочника?

С уважением.
...
Рейтинг: 0 / 0
28.09.2004, 15:46
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32715058
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
2ASCRUS
а субд зачем ? ну есть файлик, есть для sql интерфейс, типа mSqls или breklyDB, ну можно его (файлик) синхронизировать с центральной субд. зачем эту файлику что-либо от субд - транзакции, блокировки, паралельное выполнение, оптимайзер наконец ?

2onstat-
просто большинство считает тесты реальной задачи SAP benchmarks достаточно авторитетными и не думают, что смогут организовать что-либо более авторитетное.
...
Рейтинг: 0 / 0
28.09.2004, 16:03
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32715244
Фотография Рыжий Кот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Рыжий Кот
Участник
Yo!2ASCRUS
а субд зачем ? ну есть файлик, есть для sql интерфейс, типа mSqls или breklyDB, ну можно его (файлик) синхронизировать с центральной субд. зачем эту файлику что-либо от субд - транзакции, блокировки, паралельное выполнение, оптимайзер наконец ?

Все что вы перечислили - разве это плохо, когд оно есть? Практически невесомое, легкое.
А чтобы прошла репликация :), нужна блокировка, чтобы репликатор взял завершенные транзакции и т.д. Так что все нужно. И очень хорошо, что это сделано на т.н. начальном уровне. Завтра железо повзрослеет, а проблем с софтом нет, неужели это плохо?
...
Рейтинг: 0 / 0
28.09.2004, 17:09
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32715558
Зл0й
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зл0й
Участник
Уважаемый onstat,

В Оракле тоже есть способы посмотреть кто, что и где заблокировал. На грубом уровне ищем в словаре (data dictionary). Более тонко, на уровне записи все находится с помощью второй сессии, пытающейся сделать блокировку. Делается это достаточно редко, ибо обычно необходимость в этом не возникает. Тем не менее в оракловом форуме sql.ru все достаточно подробно расписано, поэтому в детали вдаваться не буду.

Что касается тестирования, то тестирование СУБД "самой по себе" бессмыслено. Ибо оно ничего не показывает. Точно так же как и тесты TPC-* показывают только то насколько хорошо данная СУБД решает данную конкретную тестовую задачу. Как только в некой СУБД Х появляется фича хорошо подходящая для данной задачи, то эта СУБД Х сразу оказывается "на голову выше" всех остальных. Ценность такого теста ИМХО крайне сомнительна, особенно учитывая "искусственность" тестовой задачи. Что до тестов SAP то там, по крайней мере, мы имеем вполне реальное (хоть и криво написанное - поубивал бы!) приложение. Ответить на праздный вопрос "что лучше Оракл или Информикс" эти тесты конечно не позволяют, ибо на него вообще невозможно ответить. Зато они позволяют ответить на вопрос "что лучше подходит для установки SAP Оракл или Информикс". Поскольку этот вопрос не праздный, то эти тесты ИМХО имеют определенную (хотя и ограниченную) ценность.

Предположим мы с вами затеяли тестирование "что лучше Оракл или Информикс" и даже сравнили результаты. В конечном итоге мы получили ответ на вопрос "кто лучше умеет писать приложения onstat или Зл0й" а не на вопрос "что лучше Оракл или Информикс".

Я такую работу делаю, только если есть конкретное приложение которое надо протестировать, плюс если мне за нее платят 100-120 долларов в час. Как говорится "Всякий труд должен быть оплачен". От себя добавлю "адекватно оплачен".

Про sequence и автоинкрементный тип, намек был на то что если мы допускаем "дырки" в последовательности id, то отпадает необходимость в жесткой сериализации (в смысле ANSI-стандарта) а можно обойтись Оракловой сериализацией (по науке называемой snapshot). Оракловая при всех прочих рабных будет масштабироваться лучше, ибо допускает параллелизм. Дело не в том у кого какая фича есть (ибо подобная фича есть почти в любой СУБД), а в том как оно работает, и как масштабируется.
...
Рейтинг: 0 / 0
28.09.2004, 20:17
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32715840
andy st
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andy st
Гость
Yo!
и на счет отмороженых прцессоров, разве на агрегатах не просто датчики стоят ? зачем проц (слабый но дорогой) на него взгромождать ?
А управлять всем будет мужит в валенках с туевой хучей рычагов? ;)
это особенно эффективно, когда время реакции - миллисекунды.
а слабый проц мало жрет, соотв, мало (или совсем не) греется (аналогично чипсет и память). ну и т.п....
...
Рейтинг: 0 / 0
29.09.2004, 09:31
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32715930
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
andy st Yo!
и на счет отмороженых прцессоров, разве на агрегатах не просто датчики стоят ? зачем проц (слабый но дорогой) на него взгромождать ?
А управлять всем будет мужит в валенках с туевой хучей рычагов? ;)
это особенно эффективно, когда время реакции - миллисекунды.
а слабый проц мало жрет, соотв, мало (или совсем не) греется (аналогично чипсет и память). ну и т.п....

не тормози - на агрегате датчики, управление с процессором в соседней комнате.
...
Рейтинг: 0 / 0
29.09.2004, 10:24
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32716025
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
Зл0йУважаемый onstat,

В Оракле тоже есть способы посмотреть кто, что и где заблокировал. На грубом уровне ищем в словаре (data dictionary). Более тонко, на уровне записи все находится с помощью второй сессии, пытающейся сделать блокировку. Делается это достаточно редко, ибо обычно необходимость в этом не возникает. Тем не менее в оракловом форуме sql.ru все достаточно подробно расписано, поэтому в детали вдаваться не буду.


И не нужно, я сам приводил ссылку на best way FAQ
по работe с блокировками непосредственно от Oracle в этом топике.

Зл0й
Что касается тестирования, то тестирование СУБД "самой по себе" бессмыслено. Ибо оно ничего не показывает. Точно так же как и тесты TPC-* показывают только то насколько хорошо данная СУБД решает данную конкретную тестовую задачу. Как только в некой СУБД Х появляется фича хорошо подходящая для данной задачи, то эта СУБД Х сразу оказывается "на голову выше" всех остальных. Ценность такого теста ИМХО крайне сомнительна, особенно учитывая "искусственность" тестовой задачи. Что до тестов SAP то там, по крайней мере, мы имеем вполне реальное (хоть и криво написанное - поубивал бы!) приложение.


Согласен по поводу SAP. Его разработчики пытаются усидеть на нескольких стульях(базах данных) и поэтому ответственность за целоснтость на базу не возлагают. Что там есть стоящего это методология, и соответствие международным стандартам учета.
Как очень часто бывает, идея хорошая - реализация дерьмо.
Никого не хотел обидеть.

Зл0й
Ответить на праздный вопрос "что лучше Оракл или Информикс" эти тесты конечно не позволяют, ибо на него вообще невозможно ответить. Зато они позволяют ответить на вопрос "что лучше подходит для установки SAP Оракл или Информикс". Поскольку этот вопрос не праздный, то эти тесты ИМХО имеют определенную (хотя и ограниченную) ценность.


Я не пытался доказать что лучше.

Зл0й
Предположим мы с вами затеяли тестирование "что лучше Оракл или Информикс" и даже сравнили результаты. В конечном итоге мы получили ответ на вопрос "кто лучше умеет писать приложения onstat или Зл0й" а не на вопрос "что лучше Оракл или Информикс".
Я такую работу делаю, только если есть конкретное приложение которое надо протестировать, плюс если мне за нее платят 100-120 долларов в час. Как говорится "Всякий труд должен быть оплачен". От себя добавлю "адекватно оплачен".


Я завел речь о тестировании для того чтобы доказать некоторым, что сам по себе продукт (будь то Oracle M$SQL или informix) требует професионального онтошения, Не нужно говорить, что в 90% случаем ни о чем думать не нужно.
Один бестолковый програмист может повесить на блокировку работу всей организации(есть опыт эксплуатации такого софта под Oracle).
Так, что думать нужно в зависимости от критичности приложения.

Зл0й
Про sequence и автоинкрементный тип, намек был на то что если мы допускаем "дырки" в последовательности id, то отпадает необходимость в жесткой сериализации (в смысле ANSI-стандарта) а можно обойтись Оракловой сериализацией (по науке называемой snapshot). Оракловая при всех прочих рабных будет масштабироваться лучше, ибо допускает параллелизм. Дело не в том у кого какая фича есть (ибо подобная фича есть почти в любой СУБД), а в том как оно работает, и как масштабируется.


Что значит при прочих равных? О чем вы говорите?
Откуда оракловая сериализация в других базах данных?
Маштабируемие чего? Опять 25 .
Вами названная сериализация это инструмент(фича) базы Oracle и закладываться(сравнивать) на него(его) при работе с другими базами
по крайней мере не конструктивно в споре ( и не професионально в работе).
Согласитесь, что это упрощение в по работе с блокировками
(относительно стандарта),
которое имеет свои слабые стороны,
о которых нужно знать при написании приложения.
Если бы это была панацея, все базы данных поддерживали бы такой
вид сериализации, и спорить былобы уже не очем.

По поводу дырок в последовательности ID я вобще ничего не понял.

С уважением.
...
Рейтинг: 0 / 0
29.09.2004, 10:58
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32716889
andy st
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andy st
Гость
Yo!не тормози - на агрегате датчики, управление с процессором в соседней комнате.
;)
ну это смотря какой агрегат и какие датчики... некоторые датчики по сути пром.компьютеры или контроллеры и на ура могут управлять системой.
да и соседнюю комнату не всегда найдешь...
...
Рейтинг: 0 / 0
29.09.2004, 15:15
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32717430
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ASCRUSКстати не понятно, если все с Ораклом так хорошо, то почему та самая пресловутая MB вешается с ним каждый день
А Вы не пробовали спрашивать у самой МВ? Как только туда взяли хорошего главного админа, Оракл вешаться практически перестал. Хотя на тему проектирования базы там можно медитировать куда больше, чем над приведенными здесь примерами.

ASCRUSи содержит не малый по размерам штат администраторов ?
... в количестве двух человек (было три; может, снова взяли третьего). Заодно спросите о количестве серверов в той же пресловутой МВ.

ASCRUSНо как же тогда спрашивается супер-версионный механизм Оракла, который по идее сам должен разруливать любые ситуации,
Вы правы - кривые ручки. А теперь - проясните пожалуйста; "не-Оракл" хорош потому, что Оракл не способен заблокировать все возможности криворучек? Потому что админ таки может поставить его раком, если задастся такой целью?

Может. А с "неораклом" это не так?

ASCRUSP.S. И кстати что делать, если по бизнес-логике потребуется специально заблокировать некоторые данные, чтобы их никто не мог изменить до подтверждения заблокировавшей их транзакции ?
Читать доки. На предмет оператора select .. for update.
...
Рейтинг: 0 / 0
29.09.2004, 17:48
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32717586
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
softwarer
Все мои отцитированные Вами фразы были взяты из контекста моей речи, где я убедительно (надеюсь) пытался доказать, что дело не в СУБД, а человеческом факторе. Утверждения некоторых товарищей, что Оракл однозначно, везде и всегда лучше блокировочников, в том числе и при кривых ручках, по меньшей мере смешно. В принципе Вы в своем посте это и высказали и многие другие это делали уже не раз, хотя судя по всему до сих пор не все ораклисты согласились с этим высказыванием - но это как говорится уже их личные проблемы, с чем соглашаться, а чем нет. Лично я и не против, чтобы Оракл был крут, но не могу о нем высказать компетентное мнение, так как не работаю с ним с точки зрения писателя БД, хотя приходиться работать с точки зрения читателя чужих БД, что в принципе не дает ничего полезного в плане его анализа, разве что кроме частого удивления, почему так много разработчиков Оракла не пользуются всем тем, что в нем есть, программируют по старинке и частенько криво. По теоретической базе насчет возможностей Оракла и PLSQL я более менее знаю, что он умеет, а что нет, доки и форум Оракла на sql.ru почитывать иногда приходится :)
...
Рейтинг: 0 / 0
29.09.2004, 18:37
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32717867
Зл0й
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зл0й
Участник
Про "дырки" в последовательности ID вот какая штука:
1. можно требовать чтобы ID присваивались строго по порядку 1,2,3,4,5,...
2. можно допускать 1,4,7,9 и требовать чтобы более поздние ID были больше более ранних
3. можно просто требовать только уникальности ID без каких-то иных ограничений.

Разные задачи - разные требования. В случае 1. ничто, кроме жесткой сериализации в полном соответствии с ANSI-стандартом, не спасет "отца русской демократии". Это тот случай когда от ораклового serializable (который на самом деле snapshot) толку не много. Производительность будет примерно одинаково паршивая, ибо мы фактически исключаем параллельность транзакций.

Варианты 2 и 3 реализуемы на оракловом уровне изоляции snapshot, причем за счет
параллельности транзакций работают быстрее чем 1. То есть, при всех прочих равных (например когда все - в Оракле) 3. быстрее чем 2. быстрее чем 1.

Проблема с блокировщиками в том, что варианты 2. и 3. в них зачастую выполняются так же медленно как и 1. Если предположить что разработчики Оракла не глупее и не умнее других, что первый вариант работает в Оракле и Информиксе (DB2, Sybase, MSSQL) примерно одинаково. Соответственно для реализации 1. все равно какую СУБД брать. Зато для реализации вариантов 2. и 3. предпочтительнее Оракл.

ЗЫ а на самом деле, обычно ставят ту СУБД которая в организации уже есть. Под которую уже есть опытные админы, итп. Надежность и отсутствие "сюрпризов" перевешивает все технические достоинства и недостатки СУБД. Ибо решения принимает менеджмент, которому важнее всего чтобы "не падало".
...
Рейтинг: 0 / 0
30.09.2004, 03:39
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32718026
f2f
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
f2f
Гость
Какие-то бездоказательные рассуждения (и неверные на мой взгляд рассуждения) и не понятно к чему
...
Рейтинг: 0 / 0
30.09.2004, 09:40
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32718267
onstat-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat-
Участник
Зл0йПро "дырки" в последовательности ID вот какая штука:
1. можно требовать чтобы ID присваивались строго по порядку 1,2,3,4,5,...
2. можно допускать 1,4,7,9 и требовать чтобы более поздние ID были больше более ранних
3. можно просто требовать только уникальности ID без каких-то иных ограничений.


Дальше по тексту вы эти 3 варианта имеете ввиду?
Так ка других нет то наверное.

Зл0й
Разные задачи - разные требования. В случае 1. ничто, кроме жесткой сериализации в полном соответствии с ANSI-стандартом, не спасет "отца русской демократии". Это тот случай когда от ораклового serializable (который на самом деле snapshot) толку не много. Производительность будет примерно одинаково паршивая, ибо мы фактически исключаем параллельность транзакций.


Паралельные транзакции исключаются с пересекающимися данными,
если же данные не пересекаются то паралелить можно сколько угодно.
Единица блокирования у нас запись(результат условия where).
А также если приложение позволяет зделать предположение о работе
соседней сессии, то можно включить грязное чтение и достать еще незокмиченные данные( если нужно). В oracle с этим большие проблемы.
Скорость генерация ID(sequnce) несоимеримо мала относительно времени выполнения любой другой транзакции.

Зл0й
Варианты 2 и 3 реализуемы на оракловом уровне изоляции snapshot, причем за счет
параллельности транзакций работают быстрее чем 1. То есть, при всех прочих равных (например когда все - в Оракле) 3. быстрее чем 2. быстрее чем 1.
Проблема с блокировщиками в том, что варианты 2. и 3. в них зачастую выполняются так же медленно как и 1. Если предположить что разработчики Оракла не глупее и не умнее других, что первый вариант работает в Оракле и Информиксе (DB2, Sybase, MSSQL) примерно одинаково. Соответственно для реализации 1. все равно какую СУБД брать. Зато для реализации вариантов 2. и 3. предпочтительнее Оракл.


Я не совсем понимаю что вы хотели сказать.
Если мы имеем ввиду изоляцию commited read, то чтение производится
паралельно если никто ничего не меняет. Я пока не вижу проблем в распаралеливании выполнения. Все зависит от задачи.
При правильном проектировании в блокировчнике никто на блокировках не ждет. Зато в оракле нужно помнить, что если вы открыли кусрсор, а в
это время кто-то изменит значение, то у вас будут еще старые данные.
Я где то видел пример с одновременным дебетованием двух счетов,
который для корректного разрешения требует serializable,
что автоматом приводит либо нарушении целосности данных, либо необходимости явного блокирования записи.
Т.Е. чтобы подстраховать целостность данных oracle програмист должен
работать на вашем уровне 1. И запретить распаралеливание, хотя
блокировочник сможет паралелиться на чтении и при этом корректно обработать эту ситуацию.
В данном случае неявная блокировка записи на изменение у болкировчника,
гораздо масштабируемие Вашего снапшота.


Зл0й
ЗЫ а на самом деле, обычно ставят ту СУБД которая в организации уже есть. Под которую уже есть опытные админы, итп. Надежность и отсутствие "сюрпризов" перевешивает все технические достоинства и недостатки СУБД. Ибо решения принимает менеджмент, которому важнее всего чтобы "не падало".


Здесь согласен, возразить нечему.

С уважением, onstat.
...
Рейтинг: 0 / 0
30.09.2004, 11:16
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32718538
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Всегда и везде палка о 2-х концах при сравнении любых технологий :)

Наше бремя (блокировочник)
авторЕсли мы имеем ввиду изоляцию commited read, то чтение производится
паралельно если никто ничего не меняет. Я пока не вижу проблем в распаралеливании выполнения. Все зависит от задачи.
При правильном проектировании в блокировчнике никто на блокировках не ждет.
Еще как ждет, причем в serializable :) Примитивный примерчик:
Код: plaintext
1.
2.
3.
4.
SELECT *
FROM Table
UNION ALL
SELECT *
FROM Table;
В таблице записи никогда не изменяются и не удаляются, только добавляются. Казалось бы READ COMMITED и все счастливы. Но на самом деле: пока по таблице идет первый проход, в нее добавляется с другой транзакции запись и коммитится. Во втором проходе она уже войдет в запрос и в итоге у нас получится несоотвествие возвращаемых данных и запроса, то есть на одну запись больше :) Это и есть так называемый нестабильный курсор.

Если есть поле TIMESTAMP, то для данного запроса можно выкрутиться таким способом и на READ COMMITED:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
DECLARE @LastTime timestamp;

SELECT Max(LastTime)
INTO @LastTime
FROM Table;

SELECT *
FROM Table
WHERE LastTime <= @LastTime
UNION ALL
SELECT *
FROM Table;
WHERE LastTime <= @LastTime
В данном случае мы фиксируем время последнего подтвержденного в таблице COMMIT и уже проводим выборку, имея на руках строгую точку ограничения записей. Соотвествующе если в запросе участвует 10 табличек, то придется для каждой получать время последнего COMMIT, причем именно в изоляции serializable. В итоге можно констатировать, что все таки при очень интенсивных вставках и изменениях данных только уровень изоляции serializable может 100% гарантировать достоверный результат выполнения запроса. Так что в этом плане, ораклисты правы, говоря о недостатках (хотя это слишком громко, я бы сказал фичах) блокировочников. Это не означает, что это плохо, это означает, что нужно знать особенности блокировочников и использовать те приемы и рекомендации, которые разработаны для блокировочников, т.е. не затягивать транзакции, пользоваться времянками, применять TIMESTAMP, если этого достаточно, если система не требует данных на реальный момент времени, перекидывать их на аналитические сервера и т.д.

Бремя Оракла (версионник)
авторЯ где то видел пример с одновременным дебетованием двух счетов,
который для корректного разрешения требует serializable,
что автоматом приводит либо нарушении целосности данных, либо необходимости явного блокирования записи.
Т.Е. чтобы подстраховать целостность данных oracle програмист должен
работать на вашем уровне 1. И запретить распаралеливание, хотя
блокировочник сможет паралелиться на чтении и при этом корректно обработать эту ситуацию.
Ораклисты могут возразить, что это просто фича, а не недостаток, и при правильном проектировании и отсутствие кривых рук все будет тип топ и я буду с ними полностью согласен, так же как и все тип топ у блокировочника в моих предыдущих высказываниях.

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

про прямые ручки - так что у нас на счет задачки с казино, есть что нибудь более удачное чем очередь на евентах ?

ЗЫ. на самом деле спор разрешит MS когда юкон в tpc-c будет выступать в режиме snapshot.
...
Рейтинг: 0 / 0
30.09.2004, 13:49
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32718775
onstat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat
Гость
Yo!2ASCRUS

про прямые ручки - так что у нас на счет задачки с казино, есть что нибудь более удачное чем очередь на евентах ?

ЗЫ. на самом деле спор разрешит MS когда юкон в tpc-c будет выступать в режиме snapshot.


Прямизну Ваших ручек на оценить было не на чем.
Мы могли оценить только ширину растопырки пальцев.
Может для начала вы нам предоставите какое либо предварительное
решение для Oracle.

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

С уважением.
...
Рейтинг: 0 / 0
30.09.2004, 14:35
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32719073
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ASCRUS softwarer
Все мои отцитированные Вами фразы были взяты из контекста моей речи, где я убедительно (надеюсь) пытался доказать, что дело не в СУБД, а человеческом факторе. Утверждения некоторых товарищей, что Оракл однозначно, везде и всегда лучше блокировочников, в том числе и при кривых ручках, по меньшей мере смешно.
Ну, как минимум фраза про немалый по размерам штат админов точно показывает только не доскональное владение приводимым примером.

Насчет некоторых товарищей - не могу сказать, что я внимательно прочитал все предыдущие страницы топика :) - но кардинальной активности такого рода здесь не заметил.

Насчет человеческого фактора - он, безусловно, важен везде. С моей точки зрения, можно и нужно сравнивать примерно эквивалентные уровни криворукости и их последствия. Лично у меня нет знаний, позволяющих делать это грамотно. Вот только сегодня я узнал, что MS SQL не поддерживает параметризованные клиентские запросы - меня так это шокировало, если честно.

ASCRUSкроме частого удивления, почему так много разработчиков Оракла не пользуются всем тем, что в нем есть, программируют по старинке и частенько криво.
Хм. Воспользоваться всем, что в нем есть, имхо довольно трудно.

Недавно была вакансия, где требовалось "95-процентное знание оракла". Я, с моей точки зрения, знаю оракл процентов на пятьдесят - однако, выслушал ряд комплиментов и не пошел туда. Имхо это довольно точно отражает реальную ситуацию :)
...
Рейтинг: 0 / 0
30.09.2004, 19:03
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32719084
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
авторНу, как минимум фраза про немалый по размерам штат админов точно показывает только не доскональное владение приводимым примером.
Я не работал в MB, информация у меня была на руках от лиц, работающих там, в этом Вы полностью правы. Но все равно же там админов > 1 ??? Для меня и это уже целый штат админов, так как для того, на чем я работаю (Sybase ASA) и параллейно изучаю (Sybase IQ) один админ - это уже по самое не хочу :)
...
Рейтинг: 0 / 0
30.09.2004, 19:13
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32719100
Мимо пробегал...
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимо пробегал...
Гость
softwarerВот только сегодня я узнал, что MS SQL не поддерживает параметризованные клиентские запросы - меня так это шокировало, если честно

Видимо Вы не все узнали....наверное потому что о MS SQL "за сегодня" все узнать невозможно :) Попытаюсь вывести вас из шока. В MS SQL есть определяемые пользователем функции, функционал которых без проблем позволяет выполнять такого рода действия ( и не только их). То, что это действие оформлено не как запрос, а как функция ИМХО не должно напрягать, тем более, что пользовать их можно точно так же как и любые другие таблицы и запросы.

То есть, прежде чем о чем то говорить, надо об этом ОЧЕНЬ МНОГО знать.... а иначе это будет не жисть, а сплошной шок
...
Рейтинг: 0 / 0
30.09.2004, 19:23
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32719164
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
MasterZiv
Участник
softwarer
Вот только сегодня я узнал, что MS SQL не поддерживает параметризованные клиентские запросы - меня так это шокировало, если честно.

Это каких-таких запросов нет в MSSQL ? Фсе там есть.
...
Рейтинг: 0 / 0
30.09.2004, 20:05
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32719170
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
2 ASCRUS
Давно хочу спросить Вас: "А как Вы вообще вышли на Sybase в нашей стране?"
Про Оракл и MSSQL и даже DB2 понятно. А вот про Sybase нет. Первые три особенно 1 и 3 лидируют и в мире по числу инстоляций по 36%. Второй 16%. Но MS в нашей стране лидирует по операционке - это дает дорогу и другим MS продуктам. В лит-ре про БД эти СУБД упорно упоминаются, на их примерах многое обсуждается. А вот остальные СУБД для меня полная загадка. Откуда они то нарисовались тут? Хотя Sybase и упоминается в лит-ре по БД, но как-то без излишних восхвалений.
...
Рейтинг: 0 / 0
30.09.2004, 20:12
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32719243
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
авторЯ не работал в MB, информация у меня была на руках от лиц, работающих там, в этом Вы полностью правы. Но все равно же там админов > 1 ??? Для меня и это уже целый штат админов, так как для того, на чем я работаю (Sybase ASA) и параллейно изучаю (Sybase IQ) один админ - это уже по самое не хочу

а что вас удиаляет ? то что более сложным прграмным комплексои сложнее управлять ? понятно что sybase есть 1 вид индексов - btree, плоские таблички и все ... администрить практически нечего.
но если действительно интересно почитайте как оракл RACом ставят ... :)
...
Рейтинг: 0 / 0
30.09.2004, 21:48
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32719296
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Yo!а что вас удиаляет ? то что более сложным прграмным комплексои сложнее управлять ? понятно что sybase есть 1 вид индексов - btree, плоские таблички и все ... администрить практически нечего.
но если действительно интересно почитайте как оракл RACом ставят ... :)
Интересно, Вам не надоело выставлять себя безграммотным аппелиционным ... ? :) Прежде чем делать какие либо заявления, неплохо бы иногда знакомиться с тем, что пишут авторы, а заодно и с предметом Ваших заявлений. Итак даю ссылки Вам, как новичку, который по наивности думает, что название СУБД у Sybase - Sybase и их оказывается аж целых 3:
http://www.sql.ru/faq/faq_topic.aspx?fid=178
Странно что весь этот многостраничный топик Вам твердят, что не надо путать ASE, ASA и IQ, что у них и производители разные, только общая торговая марка Sybase, но пока Вы это еще как видно никак переварить не можете :)

Немного технические характеристики всех 3 СУБД:
http://sybase.sql.ru/asa9/ASE-ASA-IQ.pdf

Более подробные ссылки о Sybase IQ, котором я говорил (и который кстати да будем Вам известно является версионником)
- Отсюда можно начинать читать о том, что это такое:
http://www.sybase.com/products/informationmanagement/sybaseiq

- И есть результаты его тестирования в так любимом Вами tpc.org:
http://www.tpc.org/tpch/results/tpch_price_perf_results.asp

Если хоть раз в жизни удосужитесь ознакомиться с материалом (именно познавательных целях, а не с целью выискивания, где что покритиковать), то заодно узнаете, сколько индексов и каких держит IQ, как он хранит данные и за счет чего выигрывает в скорости, во сколько раз сжимает информацию БД и почему его размер БД нужно умножать, чтобы получить реальный размер данных, на каких платформах работает и т.д. и т.п. Я лично Вам ничего рассказывать или тестово писать не буду, както участвовать в шоу клоунов не хочется, где один серьезно что то пытается рассказать, а второй строит при этом мины, даже не вникая в то, чего ему говорят. Хотите цирк, велком, но без меня, я наличием свободного времени особо не страдаю :)

vadiminfo Давно хочу спросить Вас: "А как Вы вообще вышли на Sybase в нашей стране?"
Про Оракл и MSSQL и даже DB2 понятно. А вот про Sybase нет. Первые три особенно 1 и 3 лидируют и в мире по числу инстоляций по 36%. Второй 16%. Но MS в нашей стране лидирует по операционке - это дает дорогу и другим MS продуктам. В лит-ре про БД эти СУБД упорно упоминаются, на их примерах многое обсуждается. А вот остальные СУБД для меня полная загадка. Откуда они то нарисовались тут? Хотя Sybase и упоминается в лит-ре по БД, но как-то без излишних восхвалений.
Познакомился с Sybase ASA совершенно случайно. От знакомых с Украины я наслышался о Sybase Power Builder и решил с ним познакомиться поближе, так как давно хотелось найти то средство построения клиентских приложений, которое было бы заточено именно под это и позволяло лепить приличный и легко поддерживаемый интерфейс с минимум кодирования и усилий. Ну а в составе PowerBuilder в качестве встроенной демонстрационной СУБД и шла урезанная версия Sybase ASA :) Вот уже полтора года я работаю с ASA и PB, разработано множество решений, компонент, технологий и проектов и я очень доволен своим выбором. Особенно доволен ASA, которая постоянно с каждым ежемесячным патчем становится мощнее и функциональнее, а главное движется строго туда, куда мне и хочется, что и не удивительно, учитывая, что работа iAnywhere по развитию ASA ведется вместе вживую с разработчиками по материалам форумов и каждый желающий может принять участие и предложить, куда и как лучше развиваться или же выложить на исправление найденные баги.
...
Рейтинг: 0 / 0
30.09.2004, 23:59
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32719301
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Кстати вдогонку - "тот самый" Sybase ASE, который как говорят являлся прародителем MSSQL и которого именно и вспоминают, говоря СУБД Sybase, я так ни разу в жизни и не видел и даже не представляю, что это такое :) Знаю только его примерные возможности по диалекту TSQL в ASA, который доработан специально для совместимости с ASE и MSSQL и далеко отстает от развития родного диалекта WatcomSQL хотя бы по той причине, что в него "разрешают" добавления только при движении TSQL в ASE и MSSQL, а WatcomSQL подгоняют по семантике и возможностям под PL/SQL и DB2, причем вводя еще и свои полезные фичи.
...
Рейтинг: 0 / 0
01.10.2004, 00:06
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32719428
Фотография Рыжий Кот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Рыжий Кот
Участник
авторПро Оракл и MSSQL и даже DB2 понятно. А вот про Sybase нет. Первые три особенно 1 и 3 лидируют и в мире по числу инстоляций по 36%. Второй 16%. Но MS в нашей стране лидирует по операционке - это дает дорогу и другим MS продуктам. В лит-ре про БД эти СУБД упорно упоминаются, на их примерах многое обсуждается. А вот остальные СУБД для меня полная загадка. Откуда они то нарисовались тут? Хотя Sybase и упоминается в лит-ре по БД, но как-то без излишних восхвалений.

По количеству инсталляций лидирует акцец.
З.Ы. Поменьше смотрите рекламу.

...
Рейтинг: 0 / 0
01.10.2004, 08:58
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32719484
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
>По количеству инсталляций лидирует акцец.

акцец не считается - все-таки это СУБД другого класса. Файл серверная, офисная, учебная. Там тогда пришлось бы еще и фокспро учитывать и все такое. Я и сам использую акцец. Если считать, то тогда конечно его почти столько сколько и Вордов установлено - сколько офисов. А это почти вся наша страна.
...
Рейтинг: 0 / 0
01.10.2004, 09:40
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720111
Pi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pi
Участник
Рыжий Кот
По количеству инсталляций лидирует акцец.
З.Ы. Поменьше смотрите рекламу.


По количеству инсталляций газовые плиты впереди автомобилей. Но рынок авто в той же России - миллиардов 8, а всей белой техники - чуть более миллиарда.

Это во-первых. А во-вторых, в 80 % случаев вместо Access можно поставить Oracle, из оставшихся (я имею в виду устаревшее железо, нехватку ОЗУ и прочие нищенские траблы) в 15% - MS SQL . Не ставят только потому, что МОЖНО не ставить. А Вы попробуйте продавать билеты на все поезда или все авиарейсы России на Access.

Так что ездите на своем велосипеде, но на форуме автолюбителей лучше помолчите.
...
Рейтинг: 0 / 0
01.10.2004, 14:41
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720126
Pi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pi
Участник
ASCRUS Но все равно же там админов > 1 ??? Для меня и это уже целый штат админов, так как для того, на чем я работаю (Sybase ASA) и параллейно изучаю (Sybase IQ) один админ - это уже по самое не хочу :)

Все же количество админов - это больше вопрос предприятия, чем софта.
Приведу такой пример. В операционной системе OS/400 (я работал еще на старой - в.2.2) нет суперюзера как класса. Если Вы Офицер Безопасности - пожалуйста, настройте все политики. Но сделать ничего нельзя. Надо зайти как Системный оператор - и все сделать (естесвенно, изменить в политиках ничего нельзя). Вот Вам пример защиты от человесекого фактора. В Советском Союзе, кстати, в стратегических системах строилась защита от сговора двоих. А Вы -про одного админа.
...
Рейтинг: 0 / 0
01.10.2004, 14:54
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720191
Guest_2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guest_2
Гость
авторА во-вторых, в 80 % случаев вместо Access можно поставить Oracle, из оставшихся (я имею в виду устаревшее железо, нехватку ОЗУ и прочие нищенские траблы) в 15% - MS SQL . Не ставят только потому, что МОЖНО не ставить. А Вы попробуйте продавать билеты на все поезда или все авиарейсы России на Access.
У Вас, лично, Oracle купленный, а ли краденый?
Похоже, что краденый, раз предлагаете, краденый Access на краденый Oracle всем менять.
...
Рейтинг: 0 / 0
01.10.2004, 15:16
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720232
Pi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pi
Участник
ASCRUS
Бремя Оракла (версионник)
авторЯ где то видел пример с одновременным дебетованием двух счетов,
который для корректного разрешения требует serializable,
что автоматом приводит либо нарушении целосности данных, либо необходимости явного блокирования записи.
Т.Е. чтобы подстраховать целостность данных oracle програмист должен
работать на вашем уровне 1. И запретить распаралеливание, хотя
блокировочник сможет паралелиться на чтении и при этом корректно обработать эту ситуацию.
Ораклисты могут возразить, что это просто фича, а не недостаток, и при правильном проектировании и отсутствие кривых рук все будет тип топ и я буду с ними полностью согласен, так же как и все тип топ у блокировочника в моих предыдущих высказываниях.


Dear ASCRUS,
Вы так здорово расписали проблемы блокировочников, и главное - показали решения этих проблем, что остается сказать
БОЛЬШОЕ СПАСИБО!

Но вот что касается версионика - ничего не понял. Какое распаралеливание запретить? Кто это где это читал? Может, не дебетирование двух счетов, а дебетирование одного счета с кредитированием другого в агло-саксонском конто? Так это вроде проблема именно блокировочника!
Простите за бестолковость, но можно ли на примерах?
...
Рейтинг: 0 / 0
01.10.2004, 15:24
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720289
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
авторЕсли хоть раз в жизни удосужитесь ознакомиться с материалом (именно познавательных целях, а не с целью выискивания, где что покритиковать), то заодно узнаете, сколько индексов и каких держит IQ, как он хранит данные и за счет чего выигрывает в скорости, во сколько раз сжимает информацию БД и почему его размер БД нужно умножать, чтобы получить реальный размер данных, на каких платформах работает и т.д. и т.п. Я лично Вам ничего рассказывать или тестово писать не буду, както участвовать в шоу клоунов не хочется, где один серьезно что то пытается рассказать, а второй строит при этом мины, даже не вникая в то, чего ему говорят. Хотите цирк, велком, но без меня, я наличием свободного времени особо не страдаю :)


у вас просто одержимость других считать глупее себя, зря ;)
у syabase настроек минимум, админ повлиять на процессы в субд практически не может, поэтому и надобность в нем минимальная.
то что эти настройки сделали предефинены и разнесли в 3 субд сути не меняет. что можно настраиват в ASA ? как можно повлиять на скорость конкретной задачи ? добать индекс - все. сравните с ораклом. что есть IQ ? как можно повлиять на скорость запроса ? сравните с ораклом.

на счет прайс перфоменс у mysql он круче ну и что ? мне например не понятно в чем тайный смысл IQ, который в ad hoc ничего показать не может , но при этом требует еще и OLPT сервер, цена которого почему то в price/perfomenc как то не фигурирует ... я понимаю terradata - которая там оракл в 2-3 раза делала.
...
Рейтинг: 0 / 0
01.10.2004, 15:45
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720370
onstat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat
Гость
Pi

авторЯ где то видел пример с одновременным дебетованием двух счетов,
который для корректного разрешения требует serializable,
что автоматом приводит либо нарушении целосности данных, либо необходимости явного блокирования записи.
Т.Е. чтобы подстраховать целостность данных oracle програмист должен
работать на вашем уровне 1. И запретить распаралеливание, хотя
блокировочник сможет паралелиться на чтении и при этом корректно обработать эту ситуацию.

Dear ASCRUS,
Вы так здорово расписали проблемы блокировочников, и главное - показали решения этих проблем, что остается сказать
БОЛЬШОЕ СПАСИБО!

Но вот что касается версионика - ничего не понял. Какое распаралеливание запретить? Кто это где это читал? Может, не дебетирование двух счетов, а дебетирование одного счета с кредитированием другого в агло-саксонском конто? Так это вроде проблема именно блокировочника!
Простите за бестолковость, но можно ли на примерах?

Я хотел привести пример с одновременным дебетованием счета двумя сессиями, ошибся, признаю.
А вы нам раскажите как избежать нарушения целосности данных
, please


Сесия 1 открывает транзакцию , считывае данные счета.
дебетует его.
Сессия 2 открывает транзацию и берет состояние того-же счета.
(Откуда она его берет? Правильно из сегмента отката. ) И дебетует его.
транзакция 2 комитится.
Транзакция 1 комитится.


с уважением onstat.
...
Рейтинг: 0 / 0
01.10.2004, 16:10
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720400
Pi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pi
Участник
Зл0йПро "дырки" в последовательности ID вот какая штука:
1. можно требовать чтобы ID присваивались строго по порядку 1,2,3,4,5,...
2. можно допускать 1,4,7,9 и требовать чтобы более поздние ID были больше более ранних
3. можно просто требовать только уникальности ID без каких-то иных ограничений.

Разные задачи - разные требования. В случае 1. ничто, кроме жесткой сериализации в полном соответствии с ANSI-стандартом, не спасет "отца русской демократии". Это тот случай когда от ораклового serializable (который на самом деле snapshot) толку не много. Производительность будет примерно одинаково паршивая, ибо мы фактически исключаем параллельность транзакций.

Варианты 2 и 3 реализуемы на оракловом уровне изоляции snapshot, причем за счет
параллельности транзакций работают быстрее чем 1. То есть, при всех прочих равных (например когда все - в Оракле) 3. быстрее чем 2. быстрее чем 1.

Проблема с блокировщиками в том, что варианты 2. и 3. в них зачастую выполняются так же медленно как и 1. Если предположить что разработчики Оракла не глупее и не умнее других, что первый вариант работает в Оракле и Информиксе (DB2, Sybase, MSSQL) примерно одинаково. Соответственно для реализации 1. все равно какую СУБД брать. Зато для реализации вариантов 2. и 3. предпочтительнее Оракл.

ЗЫ а на самом деле, обычно ставят ту СУБД которая в организации уже есть. Под которую уже есть опытные админы, итп. Надежность и отсутствие "сюрпризов" перевешивает все технические достоинства и недостатки СУБД. Ибо решения принимает менеджмент, которому важнее всего чтобы "не падало".

Такой вот недоуменный (puzzled) вопрос - какая такая сериализация нужна для пунктов 2 и 3 на Oracle? уровень изоляции snapshot? А что, sequence не устраивает? И почему, собственно, вариант 3 быстрее будет на Oracle?

Да и, честно говоря, быстродействие системы будет зависеть от описываемой проблемы только в случае истинно "кривых ручек". Выбор версионник-блокировщик как раз важен в других случаях, например, в случае отчетов из активной базы данных. Обратите внимание, что Microsoft бесплатно сует в версию SQL Server еще и Analyse server. А уж Билла Сами-знаете-какого в непонимании конкуренции обвинить трудно.
...
Рейтинг: 0 / 0
01.10.2004, 16:19
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720461
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
>У Вас, лично, Oracle купленный, а ли краденый?
Я на одном предприятии использую краденый акцес, а на другом как разработчик работаю на бесплатном Oracle. Вот я и думаю, что оба такую маркетинговую политику ведут, чтобы если есть деньги то платили, а если нет то лучше пусть пользуются этим продуктами, чем другими бесплатными или ворованными. Больше спецов по ним будет. А фирма, которая платит выберет продукт у которого больше спецов в округе найдется. Только Oracle откровенно предлагает бесплатный для разработки, а MS якобы против, но их ворованных продуктов полно. Но естественно для эксплуатации оба ворованные, но суть та же. Поэтому ворованность продукта не вызыает у меня моральных страданий - производителю это нужно в стратегических целях.
Может я ошибаюсь?
...
Рейтинг: 0 / 0
01.10.2004, 16:40
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720495
Фотография Рыжий Кот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Рыжий Кот
Участник
Pi Рыжий Кот
По количеству инсталляций лидирует акцец.
З.Ы. Поменьше смотрите рекламу.


По количеству инсталляций газовые плиты впереди автомобилей. Но рынок авто в той же России - миллиардов 8, а всей белой техники - чуть более миллиарда.

Это во-первых. А во-вторых, в 80 % случаев вместо Access можно поставить Oracle, из оставшихся (я имею в виду устаревшее железо, нехватку ОЗУ и прочие нищенские траблы) в 15% - MS SQL . Не ставят только потому, что МОЖНО не ставить. А Вы попробуйте продавать билеты на все поезда или все авиарейсы России на Access.

Так что ездите на своем велосипеде, но на форуме автолюбителей лучше помолчите.

В начале моего поста был смайлик.
Извините, что замахнулся на святое - Oracle, сравнив его с Аксесом.
Мой "велосипед" (проект на ASA) едет быстро, а самое главное одновременно в трех странах, операционисты уходят домой в 6, раньше при том же штате уходили в 9.
...
Рейтинг: 0 / 0
01.10.2004, 16:54
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720534
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
автору syabase настроек минимум, админ повлиять на процессы в субд практически не может, поэтому и надобность в нем минимальная.
то что эти настройки сделали предефинены и разнесли в 3 субд сути не меняет. что можно настраиват в ASA ? как можно повлиять на скорость конкретной задачи ? добать индекс - все. сравните с ораклом. что есть IQ ? как можно повлиять на скорость запроса ? сравните с ораклом.
А я и не сомневался в таком ответе :) Sybase ничего не делала и никуда ничего не разносила по той простой причине, что у всех 3-х продуктов свои команды, которые кстати между собой в процессе разработки никак на связаны и каждое СУБД движется своим путем.

"Добать" индекс вполне удачное решение для OLTP, там большего и не надо. Что в ASA с успехом и используется. Все остальное о том, что сделано для разруливания запросов в ASA можете смело почитать в доке. Если сказать одной фразой - "разруливанием занимается проектировщик БД на этапе ее проектирования".

Ну а насчет Sybase IQ - хорошо же Вы "читаете" приведенные ссылки, где расписано за счет чего она быстро обрабатывает большие массивы данных и почему в ней не надо влиять на скорость запроса в не зависимости от его селективности, что соотвествующе и приводит к тому, что в ней не нужны люди, которые при критических нагрузках буквально начинают ее держать ручками :) Если Вы думаете, что без вмешательства админа IQ будет выполнять любой сложности и селективности аггрегатные запросы на террабайтной БД дольше стандартного времени отклика системы, то можете считать так дальше, переубеждать Вас никто и не собирается, как впрочем и чего то разьяснять в техническом плане.

авторна счет прайс перфоменс у mysql он круче ну и что ? мне например не понятно в чем тайный смысл IQ, который в ad hoc ничего показать не может , но при этом требует еще и OLPT сервер, цена которого почему то в price/perfomenc как то не фигурирует ... я понимаю terradata - которая там оракл в 2-3 раза делала.
Интересно, а Вам никогда не приходила в голову мысль, что на сайте tpc.org выложены только те результаты тестов, которые были когда то и кем то проведены и выложены ? Даже на их сайте есть предупреждение, что эти результаты не говорят ни о чем, кроме как о том, что вот на такой то платформе в такой то конфигурации такой то сервер показал такие то результаты и стоимость владения на каждое его подключение составила столько то денег. Я смотрю для Вас этот сайт вроде ветхого завета, что там написано, только то в жизни и существует. Я все как то предпочитаю своими глазами смотреть - вот например, я своими глазами видел IQ на простеньком однопроцессорном PC с 512 RAM - скорость выполнения аггрегированного тяжелого запроса, охватывающего по фильтру миллионы записей - нажимаешь в ISQL кнопочку F5 и сразу же получаешь ответ, даже секунды не проходит и никаких оптимизаций, индексов и ручных настроек :) А еще мне показывали запрос на 8 страничек формата A4, который так же выполнялся за 2-3 секунды по террабайтной БД и опять никакого ручного фактора. Вот тут наглядно и видно, что сервер заточен именно под выполнение аналитических запросов, поэтому он и не проседает и админ ему нужен только для отслеживания политики безопасности и закачки данных с OLTP серверов.
...
Рейтинг: 0 / 0
01.10.2004, 17:09
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720554
Pi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pi
Участник
Scott Tiger Зл0йМогу например использовать для генерации id такую штуку как sequence. Масштабироваться будет заметно лучше чем selec max(id)+1 с блокировкой.

Лучше, но нелинейно. Для прокачки больших объёмов данных сиквенсами лучше не пользоваться. В OLTP проблем обычно нет (хотя, может, я не видел OLTP с таким количеством insert-ов в секунду :) ).

А что тогда, собственно? Насколько я помню документацию 7-й версии Oracle (а тогда основная проблема была производительность OLTP), то там рекомендовали вообще не использовать индексов, ну, кроме уникального ключа. Однако ж sequence существовали, к разряду проблемных их не относили, только предлагали их прокэшировать. Ну, и где-то в 8-ке появились инвертные ключи...
...
Рейтинг: 0 / 0
01.10.2004, 17:16
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720630
Pi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pi
Участник
onstat
А вы нам раскажите как избежать нарушения целосности данных
, please


Сесия 1 открывает транзакцию , считывае данные счета.
дебетует его.
Сессия 2 открывает транзацию и берет состояние того-же счета.
(Откуда она его берет? Правильно из сегмента отката. ) И дебетует его.
транзакция 2 комитится.
Транзакция 1 комитится.

с уважением onstat.

Ну, я делал это по-разному.
Если такое происходит как что-то внутреннее (например, изменение главной книги при отпуске товара), то Сесия 1 открывает транзакцию select...for update [nowait] далее, я думаю понятно.
Если же речь идет о записи в книге отпуска товара (так сказать, заглавный update)
то тут уже могу и так:
Сесия 1 открывает транзакцию , считывае данные счета.
дебетует его....
Транзакция 1 проверяет неизменность строки и в случае ее "стабильности" - комитится.

Парадокс состоит в том, что при некоторых условиях режим serializable на Oracle работает быстрее (sorry за отсутствие ссылки).

А что, MS SQL предлагает что-то другое?

А вот возвращаясь к Вашему же примерчику

авторSELECT *
FROM Table
UNION ALL
SELECT *
FROM Table;
то все становится на свои места - в Oracle я даже не задумывался над проблемами, о которых Вы рассказали. Я без иронии. Их там, в Oracle , просто нет. А ведь мы еще не дошли до транзакций Read-only...

Искренне Ваш,
любопытствующий Pi
Ктстати, может Вы подскажете мне ответ на этот вопрос
...
Рейтинг: 0 / 0
01.10.2004, 17:41
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720648
Pi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pi
Участник
ASCRUS
Интересно, а Вам никогда не приходила в голову мысль, что на сайте tpc.org выложены только те результаты тестов, которые были когда то и кем то проведены и выложены ? Даже на их сайте есть предупреждение, что эти результаты не говорят ни о чем, кроме как о том, что вот на такой то платформе в такой то конфигурации такой то сервер показал такие то результаты и стоимость владения на каждое его подключение составила столько то денег.

Как-то со временем у всех выветрилось из головы, что tpc.org тестирует компьютеры , а не софт.
Вендор говорит - у меня сервер лучше вашего, быстрее. А конкуренты - с чего бы это? А вот - смотрите тесты
Только при таком раскладе все на своих местах - и почему базы тестовые такие примитивные (по 5 таблиц), и почему кто-то из вендоров СУБД не играет в эти тесты - и ничего, лица не теряет. Теряет лицо только поставщик железяки
...
Рейтинг: 0 / 0
01.10.2004, 17:50
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720654
Pi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pi
Участник
К моему предыдущему постингу:

Меня тут вот коллеги поправляют- посмотрите на результаты тестов
Какие там компании? Что, там есть Oracle, Sybase, Miscrosoft?
Нет, там - Sun, HP, Dell.
...
Рейтинг: 0 / 0
01.10.2004, 17:53
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720666
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
автор"Добать" индекс вполне удачное решение для OLTP, там большего и не надо.

чтоб получить посредственую скорость - согласен. но админ оракла обычно еще задумывается а не нужно ли разбить на партиции, выяснить какой из 4 видов btree индексов будет более эфективен или лучше bitmap индекс пременить, создать materialized view, какую сволочь ограничить в проце и т.п. я понимаю что в ASA/IQ/ASE этого нет и настраивать соответствено нечего.
нет настроек, нет админа, все логично.

авторЯ все как то предпочитаю своими глазами смотреть - вот например, я своими глазами видел IQ на простеньком однопроцессорном PC с 512 RAM

опять душетрепательные истории :) вы вам верим ... и сами можем в любой момент на 512 RAM любую агрегацию за 1 секунду выдать хоть по сотням терабайтов. почитайте историю историю про то как в 98ом оракл давал милион если кто-то докажет что mssql на TPC-H не в тысячу раз медленее ... в 99 правда похоже отдал, но смысл в том что хранить агрегатные значения в materialized view много ума ненада.
а на счет сказок ... вы тесты давайте, тесты, а сказки детям.

2Pi
в tpc встечаются тесты разных субд на одной и той же железяке + производители субд любят таким тестом гордится у себя на сайте
...
Рейтинг: 0 / 0
01.10.2004, 17:56
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720687
Pi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pi
Участник
ASCRUS
А вот насчет высказывания "сайбез это для малого бизнеса и с ораклом совершенно не конкурирует" то я скажу наоборот - это Оракл в решениях SMB с Sybase ASA совершенно не конкурирует и проигрывает по всем позициям: цене, требованиям железу, стоимости разрабки и сопровождения решений, администрированию и т.д.

Я абсолютно лояльно отношусь ко всем базам,
но вышеприведнный аргумент лишен логики, на мой взгляд.

Если
Oracle дороже, требовательнее к железу, стоимости разработки, сопровождению и администрированию - то несоменно, что Oracle более тяжелое решение, а Sybase ASA - более легкое . И, соответственно, более пригоден для малого бизнеса

Это вывод сделан на основании Вашего утверждения и аристотелевой логики...
...
Рейтинг: 0 / 0
01.10.2004, 18:08
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720712
onstat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
onstat
Гость
Pi onstat
А вы нам раскажите как избежать нарушения целосности данных
, please


Сесия 1 открывает транзакцию , считывае данные счета.
дебетует его.
Сессия 2 открывает транзацию и берет состояние того-же счета.
(Откуда она его берет? Правильно из сегмента отката. ) И дебетует его.
транзакция 2 комитится.
Транзакция 1 комитится.

с уважением onstat.

Ну, я делал это по-разному.
Если такое происходит как что-то внутреннее (например, изменение главной книги при отпуске товара), то Сесия 1 открывает транзакцию select...for update [nowait] далее, я думаю понятно.



Вы вынуждены делать так всегда когда собираетесь
что либо делать с записью. А если ее кто то просто читает,
то ваша сессия будет ждать пока читающий отпустит запись(закроет курсор).

Так в чем же преймущество перед блокировочником которому для проведения
этих операций не нужно явно блокировать запись на изменение?


Pi

Если же речь идет о записи в книге отпуска товара (так сказать, заглавный update)
то тут уже могу и так:
Сесия 1 открывает транзакцию , считывае данные счета.
дебетует его....

Транзакция 1 проверяет неизменность строки и в случае ее "стабильности" - комитится.


Каким образом вы можете определить стабильность? Если не серкрет.
И в чем преймущество такого подхода?.

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


Pi

Парадокс состоит в том, что при некоторых условиях режим serializable на Oracle работает быстрее (sorry за отсутствие ссылки).


Понятное дело, не нужно тратить ресурсы на перенос
данных в сегмент отката.

ИХМО Не очень дешевое удовольствие, этот сегмент отката.
И выгода от него сомнительна для вышеперечисленных случаев.


Pi

А что, MS SQL предлагает что-то другое?

А вот возвращаясь к Вашему же примерчику

авторSELECT *
FROM Table
UNION ALL
SELECT *
FROM Table;
то все становится на свои места - в Oracle я даже не задумывался над проблемами, о которых Вы рассказали. Я без иронии. Их там, в Oracle , просто нет. А ведь мы еще не дошли до транзакций Read-only...


Ну это рассказал не я. И это большая проблема чем проверять
курсор на стабильность.

А давайте дойдем до транзакций Read-only, и там тоже сравним.


С уважением, onstat
...
Рейтинг: 0 / 0
01.10.2004, 18:20
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720724
Pi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pi
Участник
ASCRUS
P.S. Про криптографию БД и логов не спрашиваю, и так знаю, что в Оракле ее нет :)


ASCRUS, скажите пожалуйста, а в Sybase это есть?

Если есть, то какие преимущества это дает по сравнению с криптографией на уровне операционной системы?

И уж последний вопрос, логически направшивающийся - backup криптографированной базы тоже криптографирован?

Был бы очень благодарен за ответ и за соответсвующие ссылки.

Все так же искренне Ваш
любопытствующий Pi
...
Рейтинг: 0 / 0
01.10.2004, 18:28
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720760
Pi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pi
Участник
onstat Pi onstat
А вы нам раскажите как избежать нарушения целосности данных
, please


Сесия 1 открывает транзакцию , считывае данные счета.
дебетует его.
Сессия 2 открывает транзацию и берет состояние того-же счета.
(Откуда она его берет? Правильно из сегмента отката. ) И дебетует его.
транзакция 2 комитится.
Транзакция 1 комитится.

с уважением onstat.

Ну, я делал это по-разному.
Если такое происходит как что-то внутреннее (например, изменение главной книги при отпуске товара), то Сесия 1 открывает транзакцию select...for update [nowait] далее, я думаю понятно.



Вы вынуждены делать так всегда когда собираетесь
что либо делать с записью. А если ее кто то просто читает,
то ваша сессия будет ждать пока читающий отпустит запись(закроет курсор).

Так в чем же преймущество перед блокировочником которому для проведения
этих операций не нужно явно блокировать запись на изменение?

Был вопрос как это сделать - я показал (в надежде, что может, расскажут что интересного еще).
Теперь о преимуществе блокировочника. Его нет. В приведенном случае. Выше в форуме уже четко писалось г-ом ЗлОй - при конкуренции писатель-писатель "всякие йогурты одинаково полезны".
Мне показалось, что Ваша ошибка - в фразе для проведения этих операций не нужно явно блокировать запись на изменение
Нужно! Просто он - блокировщик, - даже прочитать ее не сможет, пока другой не отпустит. А Oracle - сможет.
Я начинал с 7-й версии Oracle и там было хорошо сказано - писатели не блокируют читателей. По умолчанию. А писателей - да, блокируют. А как иначе? Впрочем о Блокировках, модах изоляции и прочих скучных предметах Вы сможет прочитать здесь
...
Рейтинг: 0 / 0
01.10.2004, 18:50
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720766
Pi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pi
Участник
onstat Pi
Парадокс состоит в том, что при некоторых условиях режим serializable на Oracle работает быстрее (sorry за отсутствие ссылки).

Понятное дело, не нужно тратить ресурсы на перенос
данных в сегмент отката.
ИХМО Не очень дешевое удовольствие, этот сегмент отката.
И выгода от него сомнительна для вышеперечисленных случаев.

С уважением, onstat

Если Вы имеете ввиду под сегментами отката Rollback segement, то я все годы работал с мыслью, что
Oracle8i Concepts
Rollback Segments
Each database contains one or more rollback segments. A rollback segment records the old values of data that were changed by each transaction (whether or not committed). Rollback segments are used to provide read consistency, to roll back transactions, and to recover the database.

Выделено - мною
...
Рейтинг: 0 / 0
01.10.2004, 18:57
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720772
Pi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pi
Участник
onstat Pi

А что, MS SQL предлагает что-то другое?

А вот возвращаясь к Вашему же примерчику

авторSELECT *
FROM Table
UNION ALL
SELECT *
FROM Table;
то все становится на свои места - в Oracle я даже не задумывался над проблемами, о которых Вы рассказали. Я без иронии. Их там, в Oracle , просто нет. А ведь мы еще не дошли до транзакций Read-only...


Ну это рассказал не я. И это большая проблема чем проверять
курсор на стабильность.
А давайте дойдем до транзакций Read-only, и там тоже сравним.
С уважением, onstat

Я не совсем понял Ваше замечание И это большая проблема чем проверять
курсор на стабильность . Поясните, если будет возможность, пожалуйста!

А транзакция Read-only в Oraсle гарантирует согласованность на момент начала транзакции - но! не держит писателей при этом. Как это можно на блокировщике - я не знаю.

Преимущество транзакции Read-only Oraсle - это, естественно, очень сложные запросы к активно работающей базе данных. Без деградации скорости записи в базу.

А что Вы имели в виду?
...
Рейтинг: 0 / 0
01.10.2004, 19:03
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720783
Pi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pi
Участник
Leonid To Oracle-адепты:
Народ, а чем вы будете крыть, когда Yukon выйдет, где версионность "похитрее", чем версионность в Oracle ;)

А хорошо бы ссылочку!

Может, жизнь прожита зря?
...
Рейтинг: 0 / 0
01.10.2004, 19:06
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720797
Pi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pi
Участник
Зл0й

Можно почесать репу, померить responce time, понять что при достаточно большом объеме транзакций НИКАКАЯ из современных СУБД эту задачу сама по себе не решает. Просто происходит "затык" чисто по записи, даже без чтения. Тогда к СУБД прицепляют внешний монитор транзакций, типа например Tuxedo. И живут долго и счастливо.



Ув-мый г. ЗлОй,
еще со времен работы в КП ВТИ (бывшый Юго-Запад ЭВМ-Комплекс) получил привитую коллегами уверенность, что внешний монитор транзакций очень хорош в разнородных средах, но не в интенсивных - тем более на всего 10 пользователях, как в Вашем примере).
Или это уже не так?
Чтобы не перерывать груды хлама, не бросите ли Вы свою любимую ссылочку по этому вопросу?

Искренне Ваш
любопытствующий Pi
...
Рейтинг: 0 / 0
01.10.2004, 19:14
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720810
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
Leonid
To Oracle-адепты:
Народ, а чем вы будете крыть, когда Yukon выйдет, где версионность "похитрее", чем версионность в Oracle ;)

А чего нам беспокоиться? У Оракла тоже есть и хитрая версионнось Workspace Manager с помощью, которой поддерживается многоверсионность таблиц. Не знаю насколько полно это реализует теоретические концепции на этот счет, но пока не сталкивался с задачей где это надо.
...
Рейтинг: 0 / 0
01.10.2004, 19:24
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720950
Зл0й
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зл0й
Участник
Pi
еще со времен работы в КП ВТИ (бывшый Юго-Запад ЭВМ-Комплекс) получил привитую коллегами уверенность, что внешний монитор транзакций очень хорош в разнородных средах, но не в интенсивных - тем более на всего 10 пользователях, как в Вашем примере).
Или это уже не так?
Чтобы не перерывать груды хлама, не бросите ли Вы свою любимую ссылочку по этому вопросу?


Монитор транзакций удобен в разнородных средах тем, что если мы выполняем транзакцию против нескольких систем, например Oracle и DB2, то он координирует эту распределенную транзакцию. Головная боль о том "как обеспечить чтобы commit прошел в обеих базах или в обеих произошел rollback" уходит. Мы отдали монитору транзакцию а он нам вернул успех/неудачу, гарантируя синхронизацию между Oracle и DB2. Это замечательное свойство монитора транзакций можно использовать для масштабирования "вширь" (scale out). Грубо говоря если одна СУБД не справляется с потоком, мы его разбросаем по нескольким. Есть и другие способы масштабироваться с помощью монитора транзакций, см ниже.

Понятие "хорош" несколько неконкретное, поэтому рассмотрим более конкретные (измеримые) понятия:

Время отклика - время которое проходит от момента когда клиент запустил транзакцию, до момента когда он получил информацию о её успешном (или не успешном) завершении.

Пропускная способность - количество транзакций которое система обрабатывает в еденицу времени.

Максимальная пропускная способность СУБД - максимум транзакций в еденицу времени которые может обработать данная конфигурация (СУБД+железяка+...). Если поток транзакций превышает этот "порог" производительность начинает ухудшаться. Начинается пэйджинг-своппинг и иные проблемы.

Понятно, что пожертвовав временем отклика можно увеличивать пропускную способность. Поставили транзакции в очередь, чем длиннее очередь, тем больше время отклика. Зато, если размер очереди настроен так, что поток транзакций от монитора к СУБД не превышает её "порог", то мы гарантируем пропускную способность вплоть до максимальной.

Эту конструкцию можно представить себе ввиде труб. Поток транзакций - вода. В монитор транзакций входит широченная труба. У СУБД на входе труба, сечение которой = максимальной пропускной способности данной СУБД. Монитор транзакций - бассейн, достаточно большой, чтобы никогда не переполнялся. Вода (транзакции) течет от клиентов через широченную трубу в бассейн (монитор), а оттуда по более узкой трубе в СУБД. В случае масштабирования "вширь" имеем N узких труб и СУБД.

Что до ссылок - советую посмотреть TPC тесты где участвуют мониторы транзакций. Результаты там обычно весьма внушительные.
...
Рейтинг: 0 / 0
02.10.2004, 00:50
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32720953
Зл0й
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Зл0й
Участник
Небольшой ОФФ на тему "а что если..." и "что мы будем делать когда..."

Во-первых, когда M$ наконец разродится, тогда и посмотрим. Я работал с различными СУБД (Oracle, Informix, DB2, Teradata, MSSQL, MySQL). Сделают клевый MSSQL - будем с ним работать. Разумеется при условии что на нем будут работы за которые будут хорошо платить.

Пока в США расклад такой: Sybase преобладает на восточном побережье, его много в инвестиционных банках. Oracle преобладает на западном побережье. На среднем западе - территория Microsoft. Остальные СУБД не встречаются равномерно, вне зависимости от географии. Естественно при желании можно "нарыть" инсталляции опровергающие мою картинку. Но с высоты "птичьего полета" все выглядит именно так.

Глядя на историю Оракла, думаю что он не будет сидеть "сложа руки" пока M$ будет в муках "рожать" версионник. Думаю к тому моменту Оракл доведет до такой кондиции свой RAC, что сравнивать будут уже Oracle против Teradata. А сравнение Оракла с MSSQL просто будет мало кому интересно.
...
Рейтинг: 0 / 0
02.10.2004, 01:04
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32721001
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Pi ASCRUS
P.S. Про криптографию БД и логов не спрашиваю, и так знаю, что в Оракле ее нет :)


ASCRUS, скажите пожалуйста, а в Sybase это есть?

Если есть, то какие преимущества это дает по сравнению с криптографией на уровне операционной системы?

И уж последний вопрос, логически направшивающийся - backup криптографированной базы тоже криптографирован?

Был бы очень благодарен за ответ и за соответсвующие ссылки.

Все так же искренне Ваш
любопытствующий Pi
Есть только в Sybase Anywhere Studio (ASA) по 128-ключу алгоритмом AES. Криптуются БД, логи, временные файлы во время работы и конечно же бакупы. Если на БД еще включить опцию CHECKSUM PAGE, то так же СУБД будет вести проверки на попытку стороннего изменения данных в БД (ну или сбойный сектор диска). В итоге в ASA получается 3 уровня защиты:
1. Хранение всех мета-данных, в том числе и о пользователях и правах в БД наглухо убирает возможность перенести БД на другую машину с свежеинсталированным СУБД и подключится к ней там под встроенной записью системного администратора (был случай, когда сисадмин в Австралии "забыл" пароль овнера БД - довольно печальным для него случай оказался, так как тут и бакупы ничем для него помочь не могли, хотя сам виноват).
2. Криптография БД по ключу и криптография протокола передачи данных (по Certicom или RSA)
3. Поддержка режима "U.S. Government TCSEC C2 requirements" (есть для всех версий, но официально лицензия выдана на версию 7, которая в свое время и ставилась для правительства).

В других СУБД от Sybase криптографии нет. В DSS сервере Sybase IQ собственный формат хранения данных, где БД полностью хранится в сжатом виде, а по страницам хранятся не записи таблиц, а каждое поле отдельно (фактически перевернули на 90 градусов).Отсюда у него и высокая скорость обработки информации (расжать быстрее, чем считать) и быстрое выполнение аггрегатов (фактически в нем каждая колонка уже сама собой является bitmap индексом и при выполнении аггрегата он уже работает только с нужными колонками, не заботясь особо, сколько их в таблице). Отсюда кстати и медленная скорость записи информации в транзакциях - фактически вставка одной записи с 5 полями означает запись в 5 страниц с их последующим сжатием (а из за сжатия странички в IQ с 64кб начинаются размером). Отсюда и вывод - что Sybase IQ хорош только как читатель (DSS) и ему необходим партнер-писатель (OLTP) и организация процесса периодического переноса информации на него (делаться может 2-мя путями - через выгрузку/загрузку данных в CSV файле или же подлючением OLTP к IQ в качестве удаленного сервера). Самое что мне например нравится в IQ - это то, что в отличие от OLAP не нужно проектировать кубы и преобразовывать информацию. Являясь внешне полноценной РСУБД, он позволяет создать на нем такую же структуру данных, как и у баз данных OLTP, один в один перегружать всю в нее исходную информацию, без какой либо ее предварительной подготовке или аггрегации, а дальше уж сам по ней может обычными запросами обрабатывать и добывать аналитическую информацию. Еще бы они доделали в него поддержку репликаций ASA MobiLink и такая связка стала бы очень удачной - где ASA может в оффлайне удаленно собирать и подготавливать информацию, потом файлом/почтой/ftp/online закатывать изменения в центральное хранилище данных IQ. Сейчас же приходится рядом с IQ ставить промежуточную ASA, репликации идут на нее и уж с нее потом на IQ.

Резюмируя (но не для Yo!, чтобы он снова критиковать не начал) - думаю все согласятся что если рассматривать Оракл (во всяком случае у нас в России), то он очень выгоден для централизованных решений (ставить его по десяткам удаленных точек без администратора как то мало людей соглашалось по моему опыту). Так же Оракл делает ставки на человеческий фактор (администраторов), так как грамотный специалист будет эффективнее AI любой сложности (на текущий момент времени не заглядывая в будующее). Такая архитектура Оракла позволяет все держать в одном месте, одновременно производить в реальном времени сбор и анализ информации, обрабатывать огромные массивы данных и обслуживать одновременно большое кол-во подключений, как читателей, так и писателей.

У Sybase в связке ASA (OLTP) + IQ (DSS) наоборот на лицо стремление к децентрализации и мобилизации решений, где все СУБД - являются автоматами и их архитектура изначально предназначена к работе без человеческого фактора в условиях удаленного функционирования и множеством способов передачи данных (вплоть до тети на поезде с дискеткой). Из за децентрализации получается, что изначально ASA работает с не такими большими по обьему БД и малым кол-вом подключений, что вполне позволяет успешно справлятся с работой. А из за того, что у Sybase IQ нет постоянных транзакций, то есть работает он в основном только как читатель, то соотвествующе это и позволило ему иметь собственную версию формата физического хранения БД, что вкупе с приличным интеллектуальным оптимизатором запросов автоматически ускоряет выполнение запросов без вмешательства человеческого фактора и необходимости ввода квот и ограничений на приоритеты, обьемы выполняемых запросов или кол-во подключений.

Какая из этих схем лучше ? Да никакая - это просто разные схемы и соотвествующе в них участвуют изначально разные СУБД. Их можно сравнивать между собой сколько угодно, но толку от этого будет мало - фичи Оракла не сдались в схеме, предложенной Sybase, фичи Sybase выглядят смешными в схеме работы Оракла. Можно ли сравнивать схемы ? Нет, тоже нельзя, так как для разных задач будет подходить лучше или схема централизации или схема децентрализации. Наш коллега Yo! уже давным давно утверждал, что централ всегда лучше и страшно огорчился, когда узнал, что выделенка оказывается по России еще есть не везде. Его высказывания по поводу КПК тоже были однозначно направлены в сторону аксиомы "или централ или вообще СУБД не нужна". Мне кажется, что он слишком плотно засел в колею "централизованных решений" и выглянуть из нее и оглядеться по сторонам уже не может (или не хочет), что кстати доказывает только то, что он просто никогда не делал децентрализованных решений и ничего более :)
...
Рейтинг: 0 / 0
02.10.2004, 09:52
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32721014
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Yo!чтоб получить посредственую скорость - согласен. но админ оракла обычно еще задумывается а не нужно ли разбить на партиции, выяснить какой из 4 видов btree индексов будет более эфективен или лучше bitmap индекс пременить, создать materialized view, какую сволочь ограничить в проце и т.п. я понимаю что в ASA/IQ/ASE этого нет и настраивать соответствено нечего.
нет настроек, нет админа, все логично.

Если хотите, я Вам могу лично по почте BOL выслать по Sybase ASA и Sybase IQ, чтобы Вы точно могли знать, что они имеют, а что нет. А то неравноценно как то получается - я, прежде чем чего то написать хоть про Sybase, хоть про Оракл, трачу время, ищу информацию в интернете, аргументирую. А Вы просто скандачка рубите фразами, особо не вдумываясь, насколько они соотвествуют действительности.
...
Рейтинг: 0 / 0
02.10.2004, 10:55
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32721103
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
ASCRUS
Резюмируя (но не для Yo!, чтобы он снова критиковать не начал) - думаю все согласятся что если рассматривать Оракл (во всяком случае у нас в России), то он очень выгоден для централизованных решений (ставить его по десяткам удаленных точек без администратора как то мало людей соглашалось по моему опыту).

Не все. Способность СУБД поддерживать распределенные БД, т.е. по сути претендовать на название распределенной не определяется возможностью отсутствия администрирования как такового на удаленных точках. Там во главу вопроса ставится прозрачность распределения данных. И у Оракла для этого кое-что есть. Мы ведь создаем информационные системы не для того, чтобы только сократить администрирование. Есть и другие цели, иначе самая лучшая ИС та, которой нет, потому что тогда она точно не нуждается в администрировании. Т.е. нельзя сказать, что Оракл безнадежно проиграл какой-либо из СУБД в достижениях в области распределенной обработки информации. Надо трижды подумать какую СУБД выбрать для таких задач, иначе можно доиграться. А при учете админства лучше ориентироваться на то, каких спецов обитает в достатке, и какой продукт достаточно распространен. Все-таки это более традиционный подход.

У нас на фирме есть проект с распределенной БД. На удаленных точках - в разных частях страны стоят Ораклы и в центре (Центральный офис). Админами там просто кого-то назначили (там даже нет должности АБД). Написали доку с четким указанием что им и как смотреть - тоже не требует особых знаний. Впрочем, многие из них не утруждали себя и ее чтением. Практика показала - отказов в течении 2 лет было не много - около 10. Большинство было связано с сетью - решали админы сетей, хотя обнаруживали АБД.
Хотя до Томаса Кайта и мне - разработчику этой части задачи далеко, а тем админам, некоторые из которых вообще не замарачиваются на чтениях литры или только начали работать с Ораклом - тем более. Т.е. вопросы квалификации админа не критичны. Однако, на одной точке опытный админ, но у него 10 серверов и с другими задачами.

Кроме того, мне не совсем ясно, что значит отсутствие администрирования как такового. Есть теория надежности, согласно, которой любое устройство обязано рано или поздно отказать, и чем сложнее система, тем вероятность отказа увеличивается при прочих равных условиях. А БД все время меняет свое состояние - как минимум увеличивается в объеме. Т.е. какое-то админство не избежно. Те, кто ставят ИС без админства вообще рано или поздно могут быть сильно разочарованы в этой системе.
Впрочем, в том проекте по одному админу (совмещаюему админство с другими обязанностями) и когда он уходит в отпуск, то по сути можно говорить об отсутствии там админа вообще. Оракл достаточно надежен, хотя багов в нем хватает.
Поэтому тут мне совсем ясно про то, что Оракл можно рассматривать только для централизованных решений.



ASCRUS
Так же Оракл делает ставки на человеческий фактор (администраторов), так как грамотный специалист будет эффективнее AI любой сложности (на текущий момент времени не заглядывая в будующее).

На человеческий фактор делать ставки придется в алгоритмических системах, иначе нужно ждать прогресса в области искусственного интеллекта.
Например, из общих достижений в развитии БД мы знаем, что существует масса алгоритмов по извлечению данных из БД. В разных состояниях БД одни лучше, другие хуже. С другой стороны, чтобы система могла вычислить какой лучше в текущем состоянии нужно больше информации о состоянии таблиц, участвующих в запросе. Однако это информация больше ни для чего не нужна. Если ее все время собирать то это отнимет ресурсы, а проблема с медленными запросами не так часто встает. Тем более, что причина замедления может быть вызвана и другими причинами. Т.е. ее поиск в общем случае задача, не подающаяся алгоритму (интеллектуальная задача), тем более не отнимающему никаких ресурсов системы . Почему бы не перепоручить человеческому фактору принять решение о том, что его не устраивает время выполнения запроса и собрать эту дополнительную информацию, а потом когда она не нужна убрать?

ASCRUS
Самое что мне например нравится в IQ - это то, что в отличие от OLAP не нужно проектировать кубы и преобразовывать информацию. ... а дальше уж сам по ней может обычными запросами обрабатывать и добывать аналитическую информацию.

Воощето-то это не совсем сравнение с Ораклом. Оракл старется предлагать все известные средства работы с DSS. Среди прочих и OLAP . Там есть даже Data Mining - последние так сказать технологии в этой области, правда не знаю на каком уровне. Просто OLAP наиболее популярен на сегодняшний момент. Там у Оракла свой движек для специальных вычислений. А не нужны, он тоже имеет обычные средства, дополняя их всяким материализованными представлениями, аналитическими функциями запросы SQL. Это просто дает различные возможности проектировщику для различных задач.

ASCRUS
У Sybase в связке ASA (OLTP) + IQ (DSS) наоборот на лицо стремление к децентрализации и мобилизации решений, где все СУБД - являются автоматами и их архитектура изначально предназначена к работе без человеческого фактора в условиях удаленного функционирования и множеством способов передачи данных (вплоть до тети на поезде с дискеткой).

Вообще-то ОРАКЛ шел когда-то по этому пути. У него был Express Server. Но Оракл от этого отказался. А значение человеческого фактора в виде мобильности пользователя, возможно, от этого только уменьшается. Теперь не надо осваивать несколько продуктов. Кроме того, вопрос о том, что приобретать, упростился – все в одном. А при создании БД с помощью мастера можно указать планируется ее использование как OLAP, DSS или и то и другое. Лично мне это много больше нравится.
...
Рейтинг: 0 / 0
02.10.2004, 16:07
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32721134
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
авторНаш коллега Yo! уже давным давно утверждал, что централ всегда лучше и страшно огорчился, когда узнал, что выделенка оказывается по России еще есть не везде. Его высказывания по поводу КПК тоже были однозначно направлены в сторону аксиомы "или централ или вообще СУБД не нужна". Мне кажется, что он слишком плотно засел в колею "централизованных решений" и выглянуть из нее и оглядеться по сторонам уже не может (или не хочет), что кстати доказывает только то, что он просто никогда не делал децентрализованных решений и ничего более :)

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

ну да и когда был последний раз мне показалось что Москва в этом смысле не сильно отличается, и в принципе я считал что в городах милиониках инет тоже не проблема ... похоже ошибся.
у нас в спальный районах появляется оптика, цены начиная ~$30/месяц ... сравниваем с ценой лицензии на субд ... и получаем 2-3 mbs оптика+радиолинк (дублирование) выходит на порядок дешевле лицензии субд. понятно что такое далеко не везде, но в ЕС скоро будет везде.
плюс у нас получилось вынести сервера к провайдеру из офиса дешевле, т.к. в офисе дорого организовать дизельные генераторы, пожаргую фигню, кондишки по $2k и т.п.

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

на счет затрат на обслуживание - чесно говоря не совсем врубаюсь как sybase представляет некую ERP на своих субд если там и файловая помойка (в субд) и документоборот, бухгалтерия, олап отчеты и т.п. онож местами OLPT местами DSS и как такое предполагается крутить на ASA+IQ ?

2ASCRUS
можно через запятую перечислить что может предпринять дба чтоб ускорить запрос select sum(shit) from table group by fuck
а) на ASE
б) IQ
...
Рейтинг: 0 / 0
02.10.2004, 18:48
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32721162
Фотография Рыжий Кот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Рыжий Кот
Участник
авторРискуя быть оплеванным, я тоже считаю, что централизованные решения более надежны и эффективны, стоимость обслуживания - ниже.

Так категирично не пойдет.
Не всегда разумно гонять результаты выборки по сети.
Быть может когда от любой машины к любой машине во всем мире будет что-то вроде мегабиты/сек., тогда да... Но решения нужны и сегодня, вернее вчера. У вас в распоряжении слабенькие каналы. Что вы, как сторонник идеи, что " централизованные решения более надежны и эффективны ", можете предложить мне как клиенту?

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

Разумеется, если у вас филиалы раскиданы по всей стране (это для всех актуально), то никуда не деться, будет набор удаленных серверов. Что приведет к усложнению системы в целом. Но в любом случае вопрос здесь сведется к организации надежного транспорта. Только при чем здесь СУБД ?
...
Рейтинг: 0 / 0
02.10.2004, 20:44
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32721249
Фотография Рыжий Кот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Рыжий Кот
Участник
Что значит "в инфраструктуру вкладываться прежде всего." ?
Вы мне предлагаете за свой счет прокладывать каналы?

...приведет к усложнению системы в целом. Но в любом случае вопрос здесь сведется к организации надежного транспорта. Только при чем здесь СУБД ?

При том, что Sybase предлагает уже готовое решение по созданию распределенной БД при не очень надежном транспорте.

...
Рейтинг: 0 / 0
03.10.2004, 10:13
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32721279
Guest_2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guest_2
Гость
авторя вам предложу в инфраструктуру вкладываться прежде всего.
как клиенту :)
Термин Wan Selling, Вам знаком?
Если знаком, то расскажите пож-ста, про инфраструктуру, в которую надо вкладываться.
...
Рейтинг: 0 / 0
03.10.2004, 12:18
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32721445
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
Рыжий КотЧто значит "в инфраструктуру вкладываться прежде всего." ?
Вы мне предлагаете за свой счет прокладывать каналы?


Странный вопрос. Вы лицензии СУБД и железо за свой счет покупаете? Если да, то значит каналы - тоже за свой счет.


...приведет к усложнению системы в целом. Но в любом случае вопрос здесь сведется к организации надежного транспорта. Только при чем здесь СУБД ?

При том, что Sybase предлагает уже готовое решение по созданию распределенной БД при не очень надежном транспорте.


Ну и что?
...
Рейтинг: 0 / 0
04.10.2004, 00:54
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32721448
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
мда, прочел "покупать" вместо вашего "прокладывать" ...

Разумеется покупать. Это я и имел в виду, говоря про инфраструктуру. И что сейчас большая проблема купить надежные каналы? Только не нужно про деревню Гадюкино рассказывать...
...
Рейтинг: 0 / 0
04.10.2004, 01:02
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32721469
Guest_2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guest_2
Гость
KilledИ что сейчас большая проблема купить надежные каналы? Только не нужно про деревню Гадюкино рассказывать...
Про розничную продажу с колес, слышали? А теперь, про широкие каналы, начните нам рассказывать, которые купить не проблема... А данные реплицировать тем не менее надо, причем даже до возвращения фургона на базу.
...
Рейтинг: 0 / 0
04.10.2004, 06:05
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32721526
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
надежный != широкий. Читайте внимательнее
...
Рейтинг: 0 / 0
04.10.2004, 08:59
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32721654
Guest_2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guest_2
Гость
Ok, читаю внимательнее.
И насколько надежен Connect через GPRS модем?

Хорошо, какой транспорт (или канал, если хотите) будет надежным при продаже с колес?
...
Рейтинг: 0 / 0
04.10.2004, 10:20
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32721705
Фотография Рыжий Кот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Рыжий Кот
Участник
Я знаю только то, что ничего не знаю :)
Строить централизованное решение хорошо. Только не каждое предприятие может себе это позволить это, если цена за "имение" канала будет составлять львиную долю его дохода.
Деревня Гадюкино должна же с чего-то начинать...
Кстати, все кроме Москвы и еще пары-тройки городов, - деревни, что ж теперь, сидеть сложа руки?

...
Рейтинг: 0 / 0
04.10.2004, 10:48
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32721733
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
Рыжий КотЯ знаю только то, что ничего не знаю :)
Строить централизованное решение хорошо. Только не каждое предприятие может себе это позволить это, если цена за "имение" канала будет составлять львиную долю его дохода.
Деревня Гадюкино должна же с чего-то начинать...
Кстати, все кроме Москвы и еще пары-тройки городов, - деревни, что ж теперь, сидеть сложа руки?



Кот, а может ну его нафиг такое предприятие? У которого нет средств арендовать канал? :) Может бизнес этого предприятия не дорос еще до распределенных систем? И денег судя по всему много там не заработать.
Я говорил не только про Москву. Скажем так, пара местных провайдеров сейчас найдется практически в любом более-менее крупном городе.
...
Рейтинг: 0 / 0
04.10.2004, 11:02
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32721749
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
Guest_2Ok, читаю внимательнее.
И насколько надежен Connect через GPRS модем?

Хорошо, какой транспорт (или канал, если хотите) будет надежным при продаже с колес?

Зачем вам в фургоне держать СУБД ? Фургон - это фактически касса? И что может быть надежнее в смысле передачи данных чем вариант с фтп?
...
Рейтинг: 0 / 0
04.10.2004, 11:05
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32721796
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Коллеги, давайте не будем по второму кругу пускать обсуждение каналов и СУБД для фургонов, так как это уже все обсуждалось и читать/писать одно и тоже честно говоря не хотелось бы :) Лично я выбирал СУБД Anywhere Studio (которая официально считается Workgroup) по другим мотивам - в ней меня устроила ее хорошая функциональность языка запросов и хранимых процедур WatcomSQL, интеллектуальность оптимизатора, нулевое администрирование, криптография БД и полное соотвествие стандартам встраиваемой СУБД (от ценовой лицензионной политики до включение ее в установку приложения, где пользователь даже и не знает, что у него установлена и работает РСУБД). Могу со всей серьезностью заявить, что эта СУБД является самой легкой по освоению и сопровождению из всех, которые я видел. Она одновременно имеет как малый вес цены и размера, так и довольно мощный функционал (включая встроенные офф-лайн репликации, КПК-версию, механизм гетерогенных репликаций, поддержку read-only сжатых БД и Java как ХП и обьекты в таблицах). В общем она имеет все, что мне нужно для создания удаленных и тиражных приложений. Я уверен, что на Оракле можно достичь всего того же (возможно чуть большей ценой вложений). Однако мне говорили очень многие знакомые ораклисты, что все таки пускать в тираж сотнями копий БД на Оракле рискованно для контор, где просто вообще нет и такого понятия, как сисадмин. Сам я это не проверял, но если присутствующие тут коллеги, знающие Оракл говорят, что это неправда, значит так оно и есть и спорить тут особо не о чем. Будем иметь ввиду, вот и все дела :)
...
Рейтинг: 0 / 0
04.10.2004, 11:26
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32721802
Фотография Рыжий Кот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Рыжий Кот
Участник
killed Рыжий КотЯ знаю только то, что ничего не знаю :)
Строить централизованное решение хорошо. Только не каждое предприятие может себе это позволить это, если цена за "имение" канала будет составлять львиную долю его дохода.
Деревня Гадюкино должна же с чего-то начинать...
Кстати, все кроме Москвы и еще пары-тройки городов, - деревни, что ж теперь, сидеть сложа руки?



Кот, а может ну его нафиг такое предприятие? У которого нет средств арендовать канал? :) Может бизнес этого предприятия не дорос еще до распределенных систем? И денег судя по всему много там не заработать.
Я говорил не только про Москву. Скажем так, пара местных провайдеров сейчас найдется практически в любом более-менее крупном городе.

Хорошо, тогда по другому.
Идет инспекция/погрузка далеко в поле, на терминале. Там нет связи ни надежной, ни широкой. И прокладывать канал никто не будет (Даже BP, Lukoil), поскольку использование IT-технологий должно оправдывать вложенные в них средства. Наиболее целесообразно периодически связываться с центральным узлом и сбрасывать изменения, при этом получая изменения из центрального узла о положении на других узлах. Для этого достаточно канал в 9600 :). Выборки гоняются локально, изменения передаются периодически. Кстати, по-моему это есть ответ и на ваш вопрос к Guest_2.
Согласен с ASCRUS, это уже сто раз обсуждалось. Только разработчики на ASA всегда в роли "оправдывающихся" :).
...
Рейтинг: 0 / 0
04.10.2004, 11:29
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32721852
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Рыжий КотТолько разработчики на ASA всегда в роли "оправдывающихся" :).
Да нам то чего оправдываться ? У нас на самом деле тьфу тьфу все хорошо и с каждым месячным EBF все лучше :) Пусть другие оправдываются, кому есть в чем оправдываться :)
...
Рейтинг: 0 / 0
04.10.2004, 11:48
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32721949
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
Код: plaintext
1.
Идет инспекция/погрузка далеко в поле, на терминале. Там нет связи ни надежной, ни широкой. И прокладывать канал никто не будет (Даже BP, Lukoil), поскольку использование IT-технологий должно оправдывать вложенные в них средства. Наиболее целесообразно периодически связываться с центральным узлом и сбрасывать изменения, при этом получая изменения из центрального узла о положении на других узлах. Для этого достаточно канал в  9600  :). Выборки гоняются локально, изменения передаются периодически. Кстати, по-моему это есть ответ и на ваш вопрос к Guest_2.

Не знаю чего вы там в полях грузите. :)) Но знаю что года два-три назад в Норвегии была запущена система для геодезии на связке с iAS. Вот там люди тоже по полям ходят с КПК. Проблем то нет особых.
...
Рейтинг: 0 / 0
04.10.2004, 12:25
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32721956
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
кстати, строго говоря то о чем вы говорите не есть распределенная база. Это просто обмен данными с удаленными узлами.
...
Рейтинг: 0 / 0
04.10.2004, 12:29
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32722096
Guest_2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Guest_2
Гость
авторкстати, строго говоря то о чем вы говорите не есть распределенная база. Это просто обмен данными с удаленными узлами.
Дык никто и не говорит, что это есть распределенная БД.

PS. А про Норвегию - это хорошо, ближе примеров похоже не нашлось.
...
Рейтинг: 0 / 0
04.10.2004, 13:32
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32722143
Фотография Рыжий Кот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Рыжий Кот
Участник
авторНе знаю чего вы там в полях грузите. :))

Поля, морские терминалы, центр города, ареал велик.
Нефть, нефтепродукты, пломбировка, расчет весов по нескольким стандратам ГОСТ, АСТМ, анализы. В день проходит до 400 цистерн.
В качестве сервера выступала машина 300 с чем-то мегагерц, правда сейчас заменили на П4, дань моде так сказать...
Клиент наблюдает за отчетностью через веб.
Это все ASA. :)
Проблем тоже никаких. Правда :) это не Норвегия, а СНГ: Азербайджан, Грузия, Казахстан (может к следующему году подключится Туркменистан).

авторкстати, строго говоря то о чем вы говорите не есть распределенная база. Это просто обмен данными с удаленными узлами.
Я не буквоед, пусть будет так.
...
Рейтинг: 0 / 0
04.10.2004, 13:58
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32722354
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
авторПоля, морские терминалы, центр города, ареал велик.
Нефть, нефтепродукты, пломбировка, расчет весов по нескольким стандратам ГОСТ, АСТМ, анализы. В день проходит до 400 цистерн.
В качестве сервера выступала машина 300 с чем-то мегагерц, правда сейчас заменили на П4, дань моде так сказать...

И какой процент от общих расходов у вас занимает плата за каналы? Что-то мне кажется, там под микроскопом не разглядеть будет
...
Рейтинг: 0 / 0
04.10.2004, 15:14
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32722449
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
killedИ какой процент от общих расходов у вас занимает плата за каналы? Что-то мне кажется, там под микроскопом не разглядеть будет
Вы уже не одно сообщение пытаетесь обсуждать необходимость создания каналов. Извините, но очень напоминает попытку доказать, что если будет "Так", то "Это" будет самым выгодным. Давайте при сравнении СУБД не подгонять условия задачи по эксплуатации под них, а наоборот - их сравнивать в предложенных задачей условиях эксплуатации.
...
Рейтинг: 0 / 0
04.10.2004, 15:49
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32722461
Фотография killed
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
killed
Участник
ASCRUS killedИ какой процент от общих расходов у вас занимает плата за каналы? Что-то мне кажется, там под микроскопом не разглядеть будет
Вы уже не одно сообщение пытаетесь обсуждать необходимость создания каналов. Извините, но очень напоминает попытку доказать, что если будет "Так", то "Это" будет самым выгодным. Давайте при сравнении СУБД не подгонять условия задачи по эксплуатации под них, а наоборот - их сравнивать в предложенных задачей условиях эксплуатации.

Ничего я не пытаюсь доказать. Не нужно пытаться читать между строк, и придумывать то, чего нет. В конце концов могу я поинтересоваться чем-то, если при этом упомяну, что сайбез рулез?
...
Рейтинг: 0 / 0
04.10.2004, 15:57
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32722652
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
killedВ конце концов могу я поинтересоваться чем-то, если при этом упомяну, что сайбез рулез?
Sybase совсем не рулез :( Вот его дочерние конторы, которые разрабатывают качественное и продуманное ПО достойны уважения с софтверной точки зрения. Sybase же своим "кривым" маркетингом только портит и мешает развитию данных продуктов. Единственное, что Sybase делает мудро - умудряется покупать перспективные технологии и направления (Watcom, PowerSoft, IQ, AvantGo, XcelleNet, QAnywhere, Dejima Natural Language Technology и т.д.), но дальше никаких вложений в рекламу или маркетинг с его стороны не наблюдается, что "благотворно" сказывается на распостранении его продуктов. Такое чувство, что менеджеры Sybase свято чтут аксиому "У конторы может быть или хорошее ПО или продуманный маркетинг, но хорошо все сразу вместе не бывает".
...
Рейтинг: 0 / 0
04.10.2004, 17:04
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32723879
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
2ASCRUS
а можно всетаки через запятую перечислить что может предпринять дба чтоб ускорить запрос select sum(shit) from table group by fuck
а) на ASA
б) IQ

PS. и если не сложно можно линк на аналог oracle concepts для ASE, что-то никак не найду.
...
Рейтинг: 0 / 0
05.10.2004, 13:17
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32723916
Фотография Рыжий Кот
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Рыжий Кот
Участник
Yo!, даже если ASA или IQ или еще какое-нить творение уступает какому-либо другому продукту, это не повод вести себя фамильярно. Постарайтесь уважать собеседников.

...
Рейтинг: 0 / 0
05.10.2004, 13:31
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32723941
Yo!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Yo!
Гость
ОК постараюсь. просто спор о нужности и кол-ве адб как то опять замяли маркетингом и я хотел его подять заново, лень было много писать делал Ctr+C... если получилось фамилярно сори.
...
Рейтинг: 0 / 0
05.10.2004, 13:40
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32724003
_Dog
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
_Dog
Участник
[quot Yo!]2ASCRUS
а можно всетаки через запятую перечислить что может предпринять дба чтоб ускорить запрос select sum(shit) from table group by fuck
б) IQ
[quot]

c 2ms до 1ms? с 1сек до 0.5? нужно ускорить? Агрегат сделать когда count(*)>10000000000 :)
какой вопрос, такой и ответ.
...
Рейтинг: 0 / 0
05.10.2004, 13:59
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32724034
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
ASCRUSНо все равно же там админов > 1 ??? Для меня и это уже целый штат админов, так как для того, на чем я работаю (Sybase ASA) и параллейно изучаю (Sybase IQ) один админ - это уже по самое не хочу :)
Хм. И сколько часов в неделю этот админ отсутствует на работе? Сколько серверов и пользователей он администрит? Каков "запас" (то есть насколько часто, например, серверам не хватает "железа" на требуемый уровень запросов)? Когда есть ответ на эти вопросы - можно сравнивать и штат.

Лично я не вижу ничего странного в наличии аж двух админов на компанию в несколько тысяч человек. Админы, кстати, еще и болеют иногда, а работать кому-то надо ;)
...
Рейтинг: 0 / 0
05.10.2004, 14:07
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32724043
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Мимо пробегал...Видимо Вы не все узнали....наверное потому что о MS SQL "за сегодня" все узнать невозможно :) Попытаюсь вывести вас из шока. В MS SQL есть определяемые пользователем функции, функционал которых без проблем позволяет выполнять такого рода действия ( и не только их).
Если быть точным, именно это я и узнал - что MS SQL не поддерживает нормальные параметризованные запросы, и чтобы выполнить их с клиента, приходится извращаться.
...
Рейтинг: 0 / 0
05.10.2004, 14:09
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32724111
Мимо пробегал....
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимо пробегал....
Гость
2 softwarer

Дык эта...Вам шашечки или ехать?

авторчто MS SQL не поддерживает нормальные параметризованные запросы

Ежели напрягает вместо CREATE VIEW написать CREATE FUNCTION, то, конечно, это большая проблема. Прямо таки неразрешимая.
...
Рейтинг: 0 / 0
05.10.2004, 14:34
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32725020
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
c127
Гость
2 Мимо пробегал....

>Ежели напрягает вместо CREATE VIEW написать CREATE FUNCTION, то, конечно, это большая проблема. Прямо таки неразрешимая.

Таки да, проблема. Функции хуже оптимизируются: использование представления в представлении соптимизируется, а вызов функции из функции или функции из представления - нет.

Может что-то изменилось в последнее время, но врядли.
...
Рейтинг: 0 / 0
06.10.2004, 01:11
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32725082
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
c1272 Мимо пробегал....

>Ежели напрягает вместо CREATE VIEW написать CREATE FUNCTION, то, конечно, это большая проблема. Прямо таки неразрешимая.

Таки да, проблема. Функции хуже оптимизируются: использование представления в представлении соптимизируется, а вызов функции из функции или функции из представления - нет.

Может что-то изменилось в последнее время, но врядли.
Давайте не применять знания одной СУБД на другую СУБД. В MSSQL inline функции будут аналогом запросов, спокойно войдут в план запроса и прекрасно будут оптимизироваться. Фактически они там тоже, что и использование в запросах ХП у ASA (правда у нее оптимизатор похитрее и сам решает, когда процедуру можно включить как представление в план запросов, а когда лучше результат процедуры оформить как времянку и уже работать в запросе с ним). В MSSQL же это указывается явной конструкцией в самом диалекте описания функций.
...
Рейтинг: 0 / 0
06.10.2004, 07:34
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32725942
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
Мимо пробегал....Дык эта...Вам шашечки или ехать?
Мне ехать. Если я беру такси - для меня будет неприятным сюрпризом, что это такси ходит только по рельсам и вообще на самом деле перекрашенный трамвай. Да, можно проложить рельсы к моему дому, можно научить этот трамвай класть рельсы перед собой, убирать после и таким образом достичь функциональности такси. Как можно и написать свой сервер СУБД. Вопрос - оно мне надо, так ехать? Из принципа - поеду на трамвае?
...
Рейтинг: 0 / 0
06.10.2004, 14:01
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32729004
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
c127
Гость
ASCRUS

>В MSSQL inline функции будут аналогом запросов, спокойно войдут в план запроса и прекрасно будут оптимизироваться.

Наверное формально (по документации) так оно и есть, но я не верю, что вложенные функции можно оптмимировать так же эффективно, как и вложенные представления. Это все ИМХО. Даже с запросами у оптимизаторов проблемы, а тут вообще - функция.
...
Рейтинг: 0 / 0
08.10.2004, 02:47
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32729076
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
В MSSQL UDF, у которых в качестве результата выставлено TABLE и в теле функции стоит RETURN SELECT - это те же самые представления, только параметризированные. И они так же будут участвовать раскладываться в плане запросов вне зависимости от уровня вложенности. В ASA в принципе тоже самое - для любой ХП, у которой параметры только IN и в теле стоит только SELECT можно поставить равенство с представлениями.
...
Рейтинг: 0 / 0
08.10.2004, 07:58
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32730728
Фотография Maxx
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maxx
Участник
c127ASCRUS

>В MSSQL inline функции будут аналогом запросов, спокойно войдут в план запроса и прекрасно будут оптимизироваться.

Наверное формально (по документации) так оно и есть, но я не верю, что вложенные функции можно оптмимировать так же эффективно, как и вложенные представления. Это все ИМХО. Даже с запросами у оптимизаторов проблемы, а тут вообще - функция.

Позвольте с Вами не согласиться... прекрастно работает , нормально оптимизируется, и ничто Вам не мешает довесьти ф-цию, и сам запрос по отдельности, и потом ещещ и всемте поиграться......в конце концов программировать тоже надо
...
Рейтинг: 0 / 0
08.10.2004, 18:39
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32731008
c127
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
c127
Гость
2 ASCRUS, Maxx

А вы проверяли?

>ничто Вам не мешает довесьти ф-цию, и сам запрос по отдельности

По отдельности каждый дурак сможет, только это далеко не всегда будет оптимальный запрос. Весь фокус чтоб вместе.

Ладно я вам верю, просто это идет вразрез со всем моим опытом.
...
Рейтинг: 0 / 0
09.10.2004, 12:10
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32731265
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
c1272 ASCRUS, Maxx

А вы проверяли?

>ничто Вам не мешает довесьти ф-цию, и сам запрос по отдельности

По отдельности каждый дурак сможет, только это далеко не всегда будет оптимальный запрос. Весь фокус чтоб вместе.

Ладно я вам верю, просто это идет вразрез со всем моим опытом.
Да не функции это, те у которых тип возвращаемых данных TABLE. Ну назвали их маздайщики так, это не повод думать, что они как функции работают :)
...
Рейтинг: 0 / 0
10.10.2004, 12:56
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32738984
Pi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pi
Участник
ASCRUS c1272 Мимо пробегал....

>Ежели напрягает вместо CREATE VIEW написать CREATE FUNCTION, то, конечно, это большая проблема. Прямо таки неразрешимая.

Таки да, проблема. Функции хуже оптимизируются: использование представления в представлении соптимизируется, а вызов функции из функции или функции из представления - нет.

Может что-то изменилось в последнее время, но врядли.
Давайте не применять знания одной СУБД на другую СУБД. В MSSQL inline функции будут аналогом запросов, спокойно войдут в план запроса и прекрасно будут оптимизироваться. Фактически они там тоже, что и использование в запросах ХП у ASA (правда у нее оптимизатор похитрее и сам решает, когда процедуру можно включить как представление в план запросов, а когда лучше результат процедуры оформить как времянку и уже работать в запросе с ним). В MSSQL же это указывается явной конструкцией в самом диалекте описания функций.

Когда деревья были большими, а версии SQL Server еще маленькими - где то 6 с половиной, - довелось мне пересесть с Oracle на этого подростка. И в первые недели я обнаружил удивительную картину - один и тот же, простой по сути, запрос быстрее выполнялся из функции, чем из представления. Да, еще не все Service Puck были поставлены, еще впереди была версия 7.0 - но факт такой был.

Да, чуть не забыл. Уже тогда документация подробно объясняла, на каком этапе происходила компиляция функций и на каком составлся план запроса. А так же рассказывалось, до каких пор план запроса был верен и что надо было сделать, чтобы сервер пересмотрел этот план.
...
Рейтинг: 0 / 0
14.10.2004, 17:08
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32739023
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
funikovyuri
Участник
Уважаемый, что вы такое рассказываете - в MS SQL функции появились только в SQL 2000!
...
Рейтинг: 0 / 0
14.10.2004, 17:17
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32739093
Фотография Лох Позорный
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Лох Позорный
Участник
Это для лохов они начиная с 2000-го
А для риальных пацаноф они с версии 6.5, не, даже еще раньше, с тех времен, когда деревья были большие, майкрософт был маленьким, и еще дружил с сайбейзом.
...
Рейтинг: 0 / 0
14.10.2004, 17:40
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32739250
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
Наверное он имел ввиду все таки не функции, а хранимые процедуры, которые как известно компиляться вместе с планами запросов.
...
Рейтинг: 0 / 0
14.10.2004, 18:26
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32739268
Pi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pi
Участник
ASCRUSНаверное он имел ввиду все таки не функции, а хранимые процедуры, которые как известно компиляться вместе с планами запросов.

Всем - извините за апечатку. Это были процедуры.

(Уж и забыл, что не было там функций).
...
Рейтинг: 0 / 0
14.10.2004, 18:36
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32739732
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
автор
Наверное он имел ввиду все таки не функции, а хранимые процедуры, которые как известно компиляться вместе с планами запросов.

А разве термин хранимые процедуры происходит не от того что, они хранятся в БД и выполняются на сервере? А все остальное детали реализации. И разве это не общее название для процедур (ничего не возвращает, хотя может менять параметры) и функций (обязательно что-нибудь да возвращает)?
...
Рейтинг: 0 / 0
15.10.2004, 09:50
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32739773
Фотография ASCRUS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ASCRUS
Участник
В каждой СУБД по своему сделана реализация. Например, в MSSQL между Stored Procedures и User Defined Function существенная разница, особенно если учесть, что в UDF много чего запрещено использовать, а в ASA между ними разницы вообще никакой нет и между ними смело можно ставить равенство.
...
Рейтинг: 0 / 0
15.10.2004, 10:03
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32739778
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
vadiminfo
Участник
Там нельзя было в запросах вызывать функции? Никогда бы не подумал. Хотя в Оракле это две подсистемы PL/SQL и SQL. Тратится время на переключение контекстов. Т.е. злоупотреблять вызовами ф-ий тоже не лучшее из лучшего. Хотя с другой стороны, из-за того, что некоторые запросы могут повторяться многократно в разных запросах их лучше оформить ф-ями. В общем тут бы не плохо им что-нибудь придумать эдакое. Представления тоже не всегда годятся.
...
Рейтинг: 0 / 0
15.10.2004, 10:05
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32739832
funikovyuri
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
funikovyuri
Участник
Там нельзя было в запросах вызывать функции? Никогда бы не подумал.

Наоборот - в ASA все можно использовать в запросах :)
...
Рейтинг: 0 / 0
15.10.2004, 10:30
| Ответить | Цитировать | Написать  
БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
    #32743087
Pi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Pi
Участник
vadiminfoТам нельзя было в запросах вызывать функции? Никогда бы не подумал. Хотя в Оракле это две подсистемы PL/SQL и SQL. Тратится время на переключение контекстов. Т.е. злоупотреблять вызовами ф-ий тоже не лучшее из лучшего. Хотя с другой стороны, из-за того, что некоторые запросы могут повторяться многократно в разных запросах их лучше оформить ф-ями. В общем тут бы не плохо им что-нибудь придумать эдакое. Представления тоже не всегда годятся.

Сам никогда не мерял, но помнится писалось, что функция ТОЛЬКО с входными параметрами работает намного быстрее. Имеется в виду, конечно же, вызов функции.

Имею опыт работы с одной из мировых грандов в ERP. система - объектная, каждому объекту соответсвует оракловский пакет, обычно со множеством функций. Так жее каждому объекту соответствует одно представление (как минимум одно). Так вот, большинство представлений включают в себя вызов пакетных функции. И, представьте себе, система - рекордсмен по производительности. То есть, реализация (в других системах) независимой от СУБД логики обычно только ухудшает производительность (я не касаюсь тут темы усложнения системы)...
...
Рейтинг: 0 / 0
18.10.2004, 16:52
| Ответить | Цитировать | Написать  
324 сообщений из 324, показаны все 13 страниц
  все  
Форумы / Сравнение СУБД [игнор отключен] [закрыт для гостей] / БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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