Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 9 10 11 12 13 [14] 15 16 17 18 .. 26   вперед  Ctrl
 Re: Провал операции Yukon  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
2Alexeyvg
Пазвольте-пазвольте... как это - посекторно, в обход файловой системы? На raw- устройствах - может быть, а вот на NTFS - врядли....
20 май 04, 18:57    [691532]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Gt.
Guest
2SergSuper

у тебя 2 варианта:
1. создаешь временые таблицы заранее и получаешь как минимум 15% выйгрышь в скорости.
2. над головой вешаешь табличку "дурачок" и меняешь mssql выражение insert into на
create global temporary table a on commit preserve rows as select * from ....
20 май 04, 19:15    [691581]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Glory
Member

Откуда:
Сообщений: 104751
2Gt.
создаешь временые таблицы заранее и получаешь как минимум 15% выйгрышь в скорости.
- За счет чего 15% ? И почему 15% ? И если минимум то какой максимум ?
- Заранее - это за сколько конкретно ? А что если структура временной таблицы доджна будут зависеть от контекста запуска (имени пользователя, имени вызывающей процедуры и тд) ?


create global temporary table
global в данном случае означает видимость этой таблицы для всех коннектов ?
20 май 04, 19:23    [691595]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Gt.
Guest
автор
- За счет чего 15% ? И почему 15% ? И если минимум то какой максимум ?


за счет DDL. цифра с потолка. максимум 79% :)
там сылка на Тома была там все расписано, надеюсь английский не проблема ?

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

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


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


нет.

и мне кто-нибудь ответит, действительно ли в mssql можно создавать вью, индексы и тригеры на временные таблицы ?
20 май 04, 20:01    [691657]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Glory
Member

Откуда:
Сообщений: 104751
за счет DDL. цифра с потолка. максимум 79% :)
DDL(!) дает прирост производительности запроса(!) от 15 до 79%

там сылка на Тома была там все расписано, надеюсь английский не проблема ?
Если не трудно уточните про какую ссылку идет речь

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

и мне кто-нибудь ответит, действительно ли в mssql можно создавать вью, индексы и тригеры на временные таблицы ?
Нет, нельзя. Ни первое, ни второе, ни третье.
20 май 04, 20:10    [691666]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Leonid
Member [заблокирован]

Откуда: From nowhere
Сообщений: 743
автор
и мне кто-нибудь ответит, действительно ли в mssql можно создавать вью, индексы и тригеры на временные таблицы ?
Нет, нельзя. Ни первое, ни второе, ни третье.

Индексы можно:
SELECT * INTO #T FROM sysobjects

CREATE INDEX TI ON #T (id)

SELECT * FROM #T
ORDER BY id
20 май 04, 20:23    [691677]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Glory
Member

Откуда:
Сообщений: 104751
Да, конечно. Индексы можно
20 май 04, 20:28    [691681]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Про "Эликсир счастья". Мы делали code review систем на MS SQL и Oracle. Разбирались почему же это мелкософтная система ложиться. Ибо начальство не хотело выкладывать бабки на переделку Оракловой системы, а хотело использовать мелкософтную, где вся нужная бизнес-логика уже была запрограммирована. Выяснилось, что систему удовлетворяющую нашим требованиям на MS SQL без MTS сделать физически невозможно. Возможности СУБД не позволяют. Есть ряд таблиц в которые в "пиковые" часы весьма активно пишет большое число клиентов. К сожалению есть жесткое требование гонять запросы против этих же таблиц. Ибо начальник хочет знать что происходит в настоящий момент, а не что происходило вчера или 2 часа тому назад. А дальше все просто: клиенты пишут в таблицу, а начальник, пытающийся из нее читать те записи обновление которых сейчас происходит, получает "отлуп" из-за блокировок. Можно обойти блокировки, но тогда в отчете будет всякая ерунда. Единственный способ разрешения данной проблемы на мелкософтном скуле - разнести запросы на обновление таблицы и ее чтение по времени. То есть, грубо говоря организовать очередь, как на старом добром мэйнфрейме. А в Оракле все оказалось просто: завели некоторое количество rollback segment'ов побольше, заставили конкретные транзакции эти сегменты использовать. Соптимизировали запросы. По "историческим" данным построили snapshots, и заставили Оракла переписывать запросы так, чтобы они выполнялись против них, а не таблиц, когда это возможно. И вот он - эликсир счастья! Все заработало. Ну, правда и железяка у нас под Оракл поблатнее нашлась, чем интеловый сервер. Фишка еще и в том, что на "настоящих железяках" ОС Windows не встречается, там используют "настоящие" ОС типа юникса или скажем z/OS (OS/390). А на "настоящих" ОС не встречается мелкомягкий скуль который живет только на виндах. И вся любовь-морковь.
20 май 04, 20:40    [691700]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Glory
Member

Откуда:
Сообщений: 104751
2Зл0й
По "историческим" данным построили snapshots, и заставили Оракла переписывать запросы так, чтобы они выполнялись против них, а не таблиц, когда это возможно.
Вы и убедили начальство что это выдаваемые результаты именно онлайн, а не "что происходило вчера или 2 часа тому назад" ???
20 май 04, 20:45    [691705]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Markelenkov
Member

Откуда:
Сообщений: 2312
Glory
Почему ?? Все что я хочу чтобы в каждом коннекте в зависимости от контекста запуска создавалась временная таблица с одинаковым именем но разной структурой. Допустим для глав.буха у меня должен видеть один набор столбцов, а для рядового буха - другой


В Oracle есть такая штука - view называется.
Еще в Oracle есть такая штука - FGA control называется.
Еще в Oracle есть такая штука - пакеты называется.
20 май 04, 20:59    [691719]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
2Злой
>А в Оракле все оказалось просто: завели некоторое количество rollback segment'ов
>побольше, заставили конкретные транзакции эти сегменты использовать.
>Соптимизировали запросы. По "историческим" данным построили snapshots, и
>заставили Оракла переписывать запросы так, чтобы они выполнялись против
>них, а не таблиц, когда это возможно.

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

2Markelenkov
>В Oracle есть такая штука - view называется.
Никто не сомневался
>Еще в Oracle есть такая штука - FGA control называется.
>Еще в Oracle есть такая штука - пакеты называется.
Говорят, очень полезная штука.
А теперь - к чему это всё? т.е. как каждая их названных фич помогает решить проблему Glory?
Желательно на пальцах и по русски :-)
20 май 04, 21:22    [691732]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32174
2locky
автор

Пазвольте-пазвольте... как это - посекторно, в обход файловой системы? На raw- устройствах - может быть, а вот на NTFS - врядли....


Ну это-же азы программирования под виндами :-) На raw- устройствах и на NTFS MSSQL работает в целом одинаково.

Крутые программы, которые хотят всё выжать из дисков, типа MSSQL или других БД, обращаются к файловой системе с просьбой разрешить им пользоваться секторами какого-то файла. Файл лочится. После этого они проецируют необходимые им фрагменты на своё адресное пространство.
Т.е. MSSQL резервирует часть своего адресного пространства, который планирует под кэш данных, и мапирует его фрагменты в нужные участки файла данных.
Мапирование - это заполнение таблицы дескрипторов - 8 байт на страницу, операция очень быстрая. При обращении процессора к этому пространству, если данные ещё не подкачаны, воникает прерывание, и обработчик обращается к драйверу за нужными секторами. Всё это аппаратно поддерживается процессором.

Этот механизм называется что-то вроде низкоуровневого управления виртуальной памятью. Я сейчас всё это плохо помню, т.к. давно на MSSQL работаю, а вот раньше, когда для виндов писал...
20 май 04, 21:31    [691733]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Про исторические данные. Написано же "где возможно". А где "жесткое требование" - онлайн, то там все из онлайновых таблиц читается. У Оракла есть такая фича "query rewrite" где он переписывает запрос на эквивалентный который быстрее выполняется. Если запрос на "историю" а не на онлайновые данные, то он оракл его сам переписывает чтобы он вынимал данные оттуда где они уже посчитаны, а не считал в 3125й раз то же самое. Оракл, он умный, сволочь!

В мэ-сэ-скуль мы уперлись в блокировки при конкурентном чтении и записи онлайновых таблиц. Причем уперся не я (ибо я не мелкософтный разработчик) а команда которая занималась энтой системой с самого начала. Ничего лучше чем переписывать систему под MTS не предлагалось. То есть из мэ-сэ эскуэль сервера уже было выжато все что можно, и что нельзя тоже. И выжимал не я, а те кто с ним работал еще с тех времен когда он ставился на OS/2. К необходимости переписывать приложение ребят привела именно неспособность мелкомягкого к масштабированию вверх. Если бы эти ребята с самого начала на Оракле систему делали, то ничего переписывать им бы не пришлось. Потюнили бы запросы, базу да железяку побольше поставили бы - вот и все. Ну, а раз зашла речь о том, что бабки на переписывание системы придется палить полюбому, то начальство решило не наступать на те же грабли под названием MS SQL второй раз. Расклад такой:

Дано:
1. Система на Оракле сделанная до слияния в банке А. Масштабируется, но не имеет требуемой бизнес-логики банка Б. Имеет бизнес-логику банка А.
2. Система на MS SQL, сделанная до слияния в банке Б, имеющая требуемоую бизнес-логику, но не масштабирующаяся на нужное количество юзеров.

Банки А и Б слились, количество юзеров резко выросло, требуется:
Система масштабирующаяся на нужное количество юзеров, и имеющая требуемую бизнес-логику банка Б.

В результате оказалось проще переписать систему А, а систему Б похоронить. Список фич которые в Оракле можно использовать для подъема производительности OLTP систем с большим объемом транзакций - большой. И процентов 60-80 этого списка не имеют равноценной замены в MS. Да и не надо с него это требовать, он - честный workgroup server. А энтерпрайзом там не пахло и пока не пахнет. Вот когда мелкий-мягкий-скуль на железяку аналогичную по мощи Sun E15K будет ставиться (и использовать эту железяку на всю катушку) тогда и посмотрим. А пока - не о чем говорить.
21 май 04, 00:06    [691809]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Gt.

у тебя 2 варианта:
1. создаешь временые таблицы заранее и получаешь как минимум 15% выйгрышь в скорости.
2. над головой вешаешь табличку "дурачок" и меняешь mssql выражение insert into на
create global temporary table a on commit preserve rows as select * from ....


1. А мне неудобно заранее создавать. Это некий отчет и таблица такой структуры нужна только в этой процедуре. Допустим появится еще колонка в таблице - получается мне надо в 2-х местах править(там где я заранее создаю таблицу и в самой процедуре)

2. А хочется без "дурачков" :)

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

Просто когда нет чего-то в MSSQL, то многие сторонники Оракла говорят: "ну о чем тут можно разговаривать когда даже этого нет", когда нет чего-то в Оракле, то: "фигня, это можно легко обойти"
Обидна однако...
21 май 04, 10:09    [692157]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Glory
Member

Откуда:
Сообщений: 104751
2 Зл0й
А пока - не о чем говорить.
Это точно. Особенно в свете "Причем уперся не я (ибо я не мелкософтный разработчик) а команда которая ...".
- Интересно кем собственно "Ничего лучше чем переписывать систему под MTS не предлагалось. " и почему ?
- "То есть из мэ-сэ эскуэль сервера уже было выжато все что можно, и что нельзя тоже." Я так понимаю что команда разработчиков попыталась бороться с блокировками увеличивая мощность оборудования ??
21 май 04, 10:16    [692179]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Drema
Member

Откуда: Москва
Сообщений: 249
автор
и мне кто-нибудь ответит, действительно ли в mssql можно создавать вью, индексы и тригеры на временные таблицы ?


Индексы создавать можно (правда не знаю насколько это эффективно), а вот вью и триггеры... это просто бессмысленно. В Oracle, видимо, идеология временных таблиц другая - там все понавешено, а в MSSQL - это легкий, гибкий и быстрый буфер для сохранения данных и их последующего использования.
21 май 04, 11:18    [692427]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32174
2Зл0й
Понятно - вы про MSSQL слухи пересказываете :-)

ЗЫ. Насколько я знаю, MS работает на не менее сильных машинах, чем Sun E15K. Скажем, 64-х процессорный 64-х разрадный HP (HP Integrity Superdome) мощнее, чем E15K в макс. конфигурации.
21 май 04, 11:27    [692459]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
xz321
Guest
Радуют меня фанаты Oracle которые говорят про крутые железки S/390.
Железки то крутые только на них в основном крутят DB2/390 :)

И вообще в большинстве своем там на (390) все еще файлы используют, а не РСУБД. И UNIX во всяких системах типа резервирования билетов только сейчас появляется. Только рынок 390 он стабилен и особо не развивается. Всем кому нужны они были уже купили 390. Все остальные техникой попроще обойтись могут.

Можно конечно обсирать MS. Но не забывайте друзья что главным проектировщиком Win2000/2003 является Dave Cutler. Который проектировал VMS.
A UNIX то посасывает у VMS по возможностям. Кончено VMS не будет так популярен как раньше. Но тем не менее это основная OS ВС США
21 май 04, 11:28    [692461]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
2AlexeyVG
Лочится, значит... а Вы не пробовали отдетачить базу, сжать ее NTFS компрессией, придетачить и поработать? Работает. Хотя откуда сиквелу знать, что на уровне ФС файл сжат? Хотя допускаю, что в этом случае обращение будет идти не на низком уровне, а на уровне ОС. Т.е. если файл обычный - идем на низкий, "необычный" - идем через ОС.
2Злой
Уперлись... в блокировки... не смогли порешать... железяку круче надо... всё-такое.... Знаю, бывало... Даже! :-) лично со мной. токо я железяку не требовал круче, потому как всё равно не дали бы. Зачастую у разработчика бывает "замыленный" взгляд, и он не видит путей решений тех или иных проблем. в этом случае может быть полезен "взгляд со стороны", оценка человека без... предубеждений, что ли... и готовых решений, человека, который может увидеть "свежее" решение. Кроме того, во многих случаях системы разрабатываются слегка неправильно, без учета возможного увеличения нагрузки. А переделывать/перепроектировать работающую систему... это как серпом по одному месту. Бывает проще написать новую.
Из относительно новых примеров - СБРФ перешел на MS SQL, и вроде бы ничего, работает. То есть могЁм? Наверное. И блокировок нету...
21 май 04, 12:20    [692677]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
dmitrysk
Member

Откуда:
Сообщений: 460
автор
Из относительно новых примеров - СБРФ перешел на MS SQL, и вроде бы ничего, работает. То есть могЁм? Наверное. И блокировок нету...


Свист, ничего и никуда они не перешли. У них систем там выше крыши, и ежели одну из них сделали на MS, это не значит что они ушли с других баз.
21 май 04, 12:26    [692696]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
Может и свист.. MS говорит - что да, перешли, отвергли мэйнфрейм и Db2 и перешли...
Судя по сообщениям в одном из форумов - таки да, переходили, потому как в момент перехода 1-2 часа не работали банкоматы СБ.
Сходите на MS, посмотрите там документ про СБРФ. Насколько я понял - на MS SQL реализовано базовое обеспечение - транзакции, платежи, всё такое...
Точной ссылочки не помню, а файлик зовётся Sberbank.doc.
21 май 04, 12:34    [692742]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Scott Tiger
Member

Откуда: вмваре
Сообщений: 6905
SergSuper
Допустим появится еще колонка в таблице - получается мне надо в 2-х местах править(там где я заранее создаю таблицу и в самой процедуре)


Что значит "появится еще колонка в таблице"? Сама народится? И даже если не сама - каким образом? Нельзя изменять структуру таблиц на работающем приложении, тем более - с данными.
21 май 04, 12:46    [692797]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Glory
Member

Откуда:
Сообщений: 104751
Нельзя изменять структуру таблиц на работающем приложении, тем более - с данными.
Да можно-можно. Вы что с PIVOT таблицами ни разу не работали ?
21 май 04, 13:02    [692867]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
Scott Tiger
Что значит "появится еще колонка в таблице"? Сама народится? И даже если не сама - каким образом? Нельзя изменять структуру таблиц на работающем приложении, тем более - с данными.

Насчет того можно ли менять структуру таблиц - тут можно поспорить, но я имел ввиду не таблицу БД, а табличку в отчете. Бывает, знаете ли, юзеры просят чуть изменить отчет, чего-то убрать, чего-то добавить
21 май 04, 13:57    [693101]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32174
2locky
автор
Лочится, значит... а Вы не пробовали отдетачить базу, сжать ее NTFS компрессией, придетачить и поработать? Работает. Хотя откуда сиквелу знать, что на уровне ФС файл сжат? Хотя допускаю, что в этом случае обращение будет идти не на низком уровне, а на уровне ОС. Т.е. если файл обычный - идем на низкий, "необычный" - идем через ОС.


Наверное, так.

Или другой вариант - т.к. обращения идут на уровне логического диска, а не физического, и NTFS компрессия реализована в драйвере логического диска (тома). Тут вопрос - что считать ФС.

Т.е. ФС используется, но используется при этом только драйвер логического диска. В виндах-же много уровней драйверов.
21 май 04, 14:04    [693122]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 9 10 11 12 13 [14] 15 16 17 18 .. 26   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить