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

Откуда: Харьков, Украина
Сообщений: 62034
>Т.е. ищзменение приоритета запроса в ситеме типа "черный ящик" - это не есть "право/возможность что-либо менять" в ней ????
ну почему сразу "Черный ящик"? мне как DBA никто не может запретить анализировать базу, смотреть на неё.. а вот "счупать руками"... типа там, индекс построить... ну, наверное, это не очень страшно. а вот схему данных поменять - тут уж увольте-с, слишком стрёмно.
Да к тому же существую всякого рода инструменты, которые позволяют юзеру строить отчеты... на них то не наздравтсвуешься! они иногда такое генерят - мама моя дорогая! Одна из таких систем выдавала запросы вида
select * from DocDebet where year(date)=2000 and month(date)=4
и сервер честно сканил агроменную таблицу.... все были счастливы :-)
да и запросцы такие тулзы на 10 страниц запросто генерят. оптимизировать их как? да никак! а вот хотя бы придавить, чтобы не так мешали....
кста, вспомним еще про query governor cost limit - есть ведь штука, которая рубит запросы, которые могут долго выполнятся! но нам то надо не зарубить, пусть себе работает... главное чтобы тихонько-тихонько....
27 июл 04, 18:05    [839828]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Yo!
Guest
Glory


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


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

Откуда: Харьков, Украина
Сообщений: 62034
2Glory
>Да где он ваш пример то этот ?
Glory, я щаз сказюся! Да вот же он, 3-й раз постю...
Могу еще токо в мыло кинуть...
select Date,Sum(Summ),Sum(Vol),Max(Amount)
from DocDebet
where Date >= @df and Date < @dt
group by Date
P.S. или вы намекаете на правила со скриптом таблицы и всё такое?
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

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 миллионов.
27 июл 04, 18:14    [839863]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
>> Glory
>>Никакой тюнинг запроса не увеличит пропускную способность дисковой системы или объем оперативной памяти.
>ну наконец то, итак тюнинг ситуацию не изменит
Вай-ме! Да тюнинг-то предназначен не для того, чтобы увеличивать память или пропускную способность ДПС, а для того (в числе всего прочего, хотя иногда верно и обратное), чтобы сократить их(ресурсов) потребление!
Если вы разбиваете запрос вида
select acc,Sum(Summ) from Table group by acc
на два запроса
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 для суммирования будет умещаться в ОЗУ и не будет сбрасывать на диск, а значит будет меньше дисковых операций и тогда пропускная способность ДПС не так важна.
27 июл 04, 18:18    [839872]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Yo!
Guest
2locky

от того что "быстрее" ничего не меняется, даже если это быстрее в 2 раза.
27 июл 04, 18:52    [839938]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
>ну наконец то, итак тюнинг ситуацию не изменит, даже если вам удастся
>ускорить в 2 раза до 15 минут это не приемлимо. не многие позволить залочить
>пол базы на 15 минут. дальше если на этот запрос поставить приоритет то он
>залочит пол базы на гораздо большее время, что смысла вообще не имеет.
Но еще меньше желающих лочить базу (вот ведь привязались-то с согласовнностью) на 30 минут вместо 15.
А ускорение некоторых запрсов в 2 раза - значит увеличение быстродействия всей системы в целом в те-же 2 раза (хотя когда-как, когда больше, когда меньше).
и потом, давайте все-таки не смешивать некоторые весчи, ок?
а то я живенько могу представить ситуацию, когда блокировщик быренько отработает запрос, а версионник или просто ничего не смоежт сделать, или будет долго-долго висеть.

Мы ведь (я, по крайней мере) рассматриваем ситуацию выполнения долгоиграющих запросов без использования транзакций с уровнем изоляции read uncommitted и использование приоритета выполнения запроса как средство снижения влияния такого рода запросов на работоспособность всей системы в целом.
Вы же рассматриваете приоритеты как полностью недопустимый инструмент.
С этой точки зрения...
Кстати, позвольте Вас спросить: каким уровнем изоляции транзакций вы пользуетесь в сових системах? по моим предположениям, тем, что у MS SQL называется serializable - как обеспечивающий наименьшее количество фантомов и обеспечивающий наилучшую согласованность данных.
27 июл 04, 19:06    [839956]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
2 locky: Зачем в DB2 писать хранимую процедуру для и приоритизировать ее не уровне OS. Я честно говоря не понял.
2TORT: Oracle может только устанавливать приоритет запроса или еще какие-то лимиты выставлять???
27 июл 04, 19:21    [839976]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
2Nikolay Kulikov
если я сам правильно понял предложение Yo!, то он предлагал написать ESP, которой в самой ESP принудительно выставлять процесс на уровне ОС.... но смысла в этом мало, т.к. ESP всё равно должну будет обращаться в серверу за данными, а значит генерировать запросы, приоритет которых мы выставить не можем :-)
Тем более что что-то мне подсказывает, что затруднительно будет выставить приоритет для ESP (разве что для треда, который её выполняет, и то не уверен, как на это отреагирует SQL Server). А если сервер использует не треды, а фиберы? как тогда?
27 июл 04, 19:29    [839990]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Yo!
Guest
locky
2Nikolay Kulikov
если я сам правильно понял предложение Yo!, то он предлагал написать ESP, которой в самой ESP принудительно выставлять процесс на уровне ОС.... но смысла в этом мало, т.к. ESP всё равно должну будет обращаться в серверу за данными, а значит генерировать запросы, приоритет которых мы выставить не можем :-)


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

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

ЗЫ. у меня оракл.
27 июл 04, 21:09    [840378]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
None0
Guest
Как я и думал, все местные гуру оказались не более чем пустозвонами. Воды на 50 сообщений.
Так где выкладки, господа?

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

А пока усердно ищете, пойдука и я освежу свои знания по приоритетам и планировщику. -UNIX изнутри- Вахалии рулит. А вы дальше продолжайте теоретизировать. Привет!
27 июл 04, 22:10    [840421]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
Glory

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


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

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

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

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

Кстати приоритезировать нужно не отдельный запрос, а задачи со стороны бизнеса.
28 июл 04, 01:45    [840558]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
Nikolay Kulikov
Oracle может только устанавливать приоритет запроса или еще какие-то лимиты выставлять???





Resource Manager
28 июл 04, 01:47    [840560]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Guest_2
Guest
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; при той мощности таблицы, которую Вы указали. Вопрос в другом, а насколько необходимо выполнять данный запрос?
Для каких целей? Хорошо, допустим, что необходимо для выполнения какого-нибудь отчета. Тогда возникает другой вопрос, почему подготовка этого отчета идет в час-пик? Почему его нельзя готовить ночью, заранее?
Почему допустим в вашем примере нельзя хранить итоги по дням в отдельной таоблице? Лично я ничего по этому поводу сказать не могу, сидя сдесь в форуме, а не у вас на рабочем месте.
28 июл 04, 06:45    [840630]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Gluk (Kazan)
Member

Откуда:
Сообщений: 9365
Дааа понаписали :) Ну объясните мне господа хорошие КАК выделение длинному аналитическому запросу (на OLTP блокировочнике) минимального приоритета ПО ПРОЦЕССОРУ может увеличить пропускную способность системы в целом (по моему это его просто положит). Сырое чтение не предлагать.

2 locky

Хотелось бы услышать пример где Oracle будет долго долго висеть, а MSSQL шустренько и правильно все отработает.
28 июл 04, 08:13    [840701]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Glory
Member

Откуда:
Сообщений: 104751
ну наконец то, итак тюнинг ситуацию не изменит, даже если вам удастся ускорить в 2 раза до 15 минут это не приемлимо. не многие позволить залочить пол базы на 15 минут. дальше если на этот запрос поставить приоритет то он залочит пол базы на гораздо большее время, что смысла вообще не имеет.
Повторяю для вас как и для locky - я указал как минимум 3 направления оптимизации запросов без изменения приоритета. Начиная от самого дешевого до самого дорогостоящего. А вы упорно останавливаетесь на первом(т.е. на анализе плана выполнения).
Да, только один тюнинг плана выполнеия не решит проблему ЛЮБОГО запроса. Но он может решить проблему для КОНКРЕТНОГО запроса. А запрос вытекает из схемы данных. А схема эта с данными размещается на физическом оборудовании. Это все взаимосвязанные вещи.

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

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

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

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

Откуда: Москва
Сообщений: 607
2Killed.
Я так понял он только CPU и время выполнения ограничивает???
Создание MQT или Materialized View это tuning запроса или нет???
28 июл 04, 11:22    [841306]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Некоторые способы обходных путей и решений блокировочников по предложенной проблеме. Рассматривается 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 - все решается учетом архитектуры сервера, правильной проектировкой БД и граммотным составлением запросов и тут уже без разницы, что используется - блокировочник или версионник. Имея немного фантазии и не зная основ работы можно тормознуть любой из них, лишь бы желание было :)
28 июл 04, 11:24    [841315]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
2Glory
>Повторяю для вас как и для locky - я указал как минимум 3 направления оптимизации запросов без изменения приоритета
Пасибо, но я вообще-то рассматривал ситуацию, когда все эти этапы, ессно, пройдены. Честное слово, Glory, мы рассматриваем приоритеты не как панацею от всех болезней, а как последнее средство.
>Такого вида запрос оптимизируется только изменением схемы. Вот несколько вариантов (от простого к сложному)
ну, я так и думал :-)
>- добавление столбцов типа int в которых будут занесены отдельно дата и время как смещение от какой-то базовой даты и времени.
date - поле типа smalldatetime, дата без времени ( а хоть бы и с ним) - разница по скорости не измеряется стандартными средствами.
>- разбиение таблицы на несколько(по месяцам например) и создание секционированного представления
В общем-то так и есть, только деление не по месяцам, а так сказать по периодам активности: относительно свежие данные, с которыми постоянно работают в последнее время и данные за прошлый период. проблема в том что даже запросы по таким секционированным представлениям могут быть весьма и весьма тяжелыми, а большинство отчетов считаются в рамках одного месяца.
>- создание постоянных таблиц с агрегатами, которые могут обновляться периодически или в триггерах базовой таблицы
Для части отчетов это есть,раз в сутки обновляется табличка сводных данных, но как я уже писал, не для всех отчетов я могу предварительно посчитать агрегаты - мало того, что трудно предсказать, что понадобиться, так еще и размер этих агрегатов будет превосходить размер исходной базы.
28 июл 04, 11:29    [841351]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Glory
Member

Откуда:
Сообщений: 104751
2 locky
2Glory
>Повторяю для вас как и для locky - я указал как минимум 3 направления оптимизации запросов без изменения приоритета

Эта цитата была для killed. Извиняюсь что забыл это указать
28 июл 04, 11:36    [841409]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
Glory
2 locky
2Glory
>Повторяю для вас как и для locky - я указал как минимум 3 направления оптимизации запросов без изменения приоритета

Эта цитата была для killed. Извиняюсь что забыл это указать


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

Если не понятно, то спрошу в лоб. Как в MSSQL можно ограничить деятельность пользователя Васи Пупкина 10% CPU?
28 июл 04, 16:12    [842959]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
Nikolay Kulikov
2Killed.
Я так понял он только CPU и время выполнения ограничивает???
Создание MQT или Materialized View это tuning запроса или нет???


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

Создание MV - да, можно в какой-то степени рассматривать как tuning запроса. Но при чем здесь это?
28 июл 04, 16:19    [843018]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
killed
CPU и степень параллелизма разрешенную пользователю. Время - уже косвенно. Если нужно просто обрубить сессию при достижении лимитов, то это решается без RM.


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

MQT - MV
Ты читаешь предагрегированные данные и не надо ставить кучу локов твоим отчетом в транзакционной таблице.
28 июл 04, 16:39    [843142]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
killed
Member

Откуда: Moscow
Сообщений: 3526
Nikolay Kulikov
killed
CPU и степень параллелизма разрешенную пользователю. Время - уже косвенно. Если нужно просто обрубить сессию при достижении лимитов, то это решается без RM.


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

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


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

Про MV не понял. При чем здесь МV? Нет, ну хотите пользоваться MV в Оракл - ради бога. Речь то про приоретизацию, шедулинг и т.д.
28 июл 04, 16:46    [843181]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Glory
Member

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

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


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

killed

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

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

В свою очередь спрошу в который раз - что кто-то использует в промышленных системах заранее запрограммированные запросы с пониженным/повышенным приоритетом ?? Или предоставляет пользователю возможность изменить/задать приоритеты отсылаемых им запросов ?
28 июл 04, 17:43    [843491]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
>В свою очередь спрошу в который раз - что кто-то использует в промышленных системах заранее запрограммированные запросы с пониженным/повышенным приоритетом ??
я так делаю. Бью отчет на небольшие итеративные части, которые считается в целом медленнее, чем одним запросом. но это дает возможность другим процессам в промежутках поработать.
28 июл 04, 18:06    [843606]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4 5 6 7 8 9 10 .. 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить