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

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

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

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

Откуда:
Сообщений: 104751
Вот так. Автор заявил "а кто-то другой вынужден долго ждать ответа на свой элементарный запрос (подчеркну- не в блокировках дело , а в загрузке сервера). "
Если нет блокировок, значит нет доступа к совместным данным. Если нет доступа к совместным данным то почему надо заботится о согласовании ?

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

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


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

Glory

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


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

Откуда: Харьков, Украина
Сообщений: 62034
2Glory
>И что теперь решать вопрос производительности работы отчета путем изменения приоритета запроса ? Не анализом плана выполнения ? Не анализом индексов, схемы данных ?
Если можно, приведите Ваши рекомендации для запроса, который я привел выше.
>Не анализом узких мест обрудования ?
За анализом узких мест обычно должно следовать их устранение. А это - трата денег, иногда - значительная. Замена дисковой подсистемы на более навороченную может повлечь за собой замену всего сервера.
2Yo!
>если один запрос ты бьешь на несколько транзакций, то теряется согласованость.
а если я считаю отчет за закрытый период, в котором данные не изменяются, то не теряю :-) Более того, там даже транзакции и не нужны.
27 июл 04, 16:38    [839383]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Glory
Member

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


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

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

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

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

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

это так... ни к кому конкретно не обращаясь.
27 июл 04, 16:46    [839443]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Glory
Member

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

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

select .. table1
union
select .. table2

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

в момент T0 данные в table2 меняются ...
27 июл 04, 16:56    [839501]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Glory
Member

Откуда:
Сообщений: 104751
может я просто чего то не догоняю ...запрос
Если этот запрос содержится где-то на 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 вычисляет какие-то агрегаты, что позволит нам для промежуточной таблицы создать ПК или уникальный индекс

А для блокировок как я уже сказл существуют транзакции и уровни изоляции.
27 июл 04, 17:05    [839547]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Yo!
Guest
представте я что select * from table(1/2) это тоже тяжелые вложеные запросы, это я для обстракции ...
select * into
from(
select .. table1
union
select .. table2
) AS a

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

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

непонимаю ... или вы на dirty read намекаете ?
27 июл 04, 17:16    [839587]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
2Glory
да вот же запрос, на.. хмм. уже предыдущей страничке
select Date,Sum(Summ),Sum(Vol),Max(Amount)
from DocDebet
where Date >= @df and Date < @dt
group by Date
>Анализ и создание индексов тоже требуют денег ? Пересмотр схемы данных тоже?
Дык, Glory, вы то (и я тоже) писали о анализе узких мест оборудования!!!
А вынос tempdb на отдельный диск может привести к тому, что штатный БП уже не будет тянуть нагрузку, к примеру... или корзинка/корпус не предусматривает установку дополнительных дисков (а тогда надо внешнее, типа Fujitsu Sx30)...
Отказ от Raid5 - это вполне вариант, конечно. Иногда, правда, трудно убедить заказчика, но это технические детали и о них не стоит (говорю без иронии, не как повод обсудить еще и такой аспект).
27 июл 04, 17:23    [839640]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Glory
Member

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

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

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

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

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

Откуда: Харьков, Украина
Сообщений: 62034
2ыыыы
Да, блин, мы такие!
Потому что у меня система - он-лайн, мне важно, чтобы очереди в приемный пункт были как можно меньше, чтобы инженера работали быстро.
И то что я по ходу дела считаю аналитические отчеты на том же сервере - так это от бедности :-( Ну нет у меня еще одной железки, нету!
И мне практически всё равно, что аналитик получит отчет не через 5 минут, а через 20 - система в первую очередь не для аналитического учета, а для оперативного.
27 июл 04, 17:28    [839669]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Glory
Member

Откуда:
Сообщений: 104751
Дык, Glory, вы то (и я тоже) писали о анализе узких мест оборудования!!!
Я поставил анализ оборудования на 3ее место. После плана выполнеия, индексов и схемы данных. Потому что понятно что начинать нужно с более дешевых способов оптимизации.
27 июл 04, 17:29    [839679]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
заметил интересные особенности:
Yo! в основном интересует согласованность данных (видать натерпелся и/или специфика систем такова).
Glory по большей части интересуется правильным проектированием и оптимизацией. Видать намучился, обучая молодежжж..
причем первый отвергает практически все попытки утверждать, что согласованность - не всегда самое главное, а второй утверждает, что всегда можно перепроектировать по правильному.
Что интересно, оба они правы и неправы одновременно.
По поводу согласованности ничего говорить не буду, у меня таких проблем не возникает, а вот по поводу перепроектирования.... Дык это денег стоит. Да, я вижу, что в моей системе есть "некрасивые" места. Я уже знаю, что их можно было бы сделать по другому. Но делать этого нельзя. потому что изменение части может повлечь за собой полную перепроверку всей системы в целом. это долго и дорого.
К тому же я не упускаю из виду сопровождение чужой системы, в которой мы не имеем права/возможности что-либо менять. мы только можем изменять настройки сервера. И в некоторых случаях настройки приоритета были бы очень кстати.
27 июл 04, 17:36    [839703]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Yo!
Guest
2Glory

я посмотрел Table/Index Spool нет, следуя вашим рекомендациям получил 5% ускорение. теперь запрос идет не 30 минут, а 25.
ну и что это меняет ? принципиально ? надеюсь вы не станете уверять что любой запрос можно оттюнить до 3х минут.
27 июл 04, 17:40    [839715]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
>Я поставил анализ оборудования на 3ее место. После плана выполнеия, индексов и схемы данных. Потому что понятно что начинать нужно с более дешевых способов оптимизации.
Аболютно согласен. Причем схема данных значительно дороже плана/индексов.
Именно по этому я попросил соптимизировать мой запрос-пример.
Кстати, почему ни у кого не вызывает вопросов option(maxdop N) или with (index=...)?или SET DEADLOCK_PRIORITY? это ведь тоже способы оптимизации. Причем под оптимизацией давайте понимать оптмизации работы системы в целом, а не отдельных ее частей. никого не будет интересовать, насколько быстро считаются отчеты, если в процессе расчета тормозит остальная работа.
Давайте рассматривать опцию вида set priority low|high как полезную фичу, которая помогает в некоторых жизненных ситуациях.
P.S. Хотя, как бы мы к приоритету не относились, пока его нет - наши слова так, облачка в небе...
27 июл 04, 17:44    [839737]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Yo!
Guest
2locky

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

Откуда: Харьков, Украина
Сообщений: 62034
>я посмотрел Table/Index Spool нет, следуя вашим рекомендациям получил 5% ускорение. теперь запрос идет не 30 минут, а 25.
ну, предполжим, не 5%, а около 16%... вот так вот, на ровном месте, без смены железяк и изменения схемы данных получить 15% запас по производительности - очень даже ничего, верно ведь? причем, не прилагая особенных усилий/времени...
27 июл 04, 17:50    [839772]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
>если у вас нет проблем с блокировками почему бы не далать как ibm в db2 - писать внешнюю сторед процедуру (которая работает как отдельный процесс) и на этот процесс средствами уже ос ставить приоритет ?
дык, эта... я ведь там суммирую чего-то как-то... цифры надо из базы получить? надо. как получить? одним единственным способом - сделать select... а вот на выполнение этого select'а и хочеться назначить приоритет.
27 июл 04, 17:52    [839776]     Ответить | Цитировать Сообщить модератору
 Re: БОЛЬШОЙ ПЛЮС ORACLE (ПО СРАВНЕНИЮ С MSSQL)  [new]
Glory
Member

Откуда:
Сообщений: 104751
запрос идет не 30 минут, а 25.
ну и что это меняет ? принципиально ?

1. Ну для начала 5 минут вашем случае не 5% а 16%.

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


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


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

Откуда:
Сообщений: 104751
Именно по этому я попросил соптимизировать мой запрос-пример.
Да где он ваш пример то этот ?

Кстати, почему ни у кого не вызывает вопросов option(maxdop N) или with (index=...)?или SET DEADLOCK_PRIORITY? это ведь тоже способы оптимизации. Причем под оптимизацией давайте понимать оптмизации работы системы в целом, а не отдельных ее частей. никого не будет интересовать, насколько быстро считаются отчеты, если в процессе расчета тормозит остальная работа.
Давайте рассматривать опцию вида set priority low|high как полезную фичу, которая помогает в некоторых жизненных ситуациях.

Согласен.
27 июл 04, 17:56    [839792]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9 10 .. 13   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить