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

Откуда: Северная Калифорния
Сообщений: 686
Когда на наш блокировщик повышается нагрузка, мы добавляем ему памяти, или ставим железяку "поблатнее". Это - тот редкий случай когда база может масштабироваться путем установки более мощного "железа". В Оракле хорошо натюненная база доолжна иметь процент кэширования данных где-то 95-99%. Для движков веб-сайтов авторитеты рекомендуют стремиться к 99.9%. Соответственно подход "философский": если данные не влазят в кэш - значит надо добавить кэша. Я не беру случай идиотски спроектированных приложений - там никакая СУБД не поможет, ни версионник ни блокировщик. Так что я не согласен насчет того что "поиск нужной версии - процесс не быстрый". Исходя из собственного опыта системного программирования возьмусь утверждать что поиск в памяти - наименьшее из зол. А вот чтобы "поспать" на блокировке нам еще потребуется провести ряд недешевых операций со структурами данных ядра СУБД. Учитывая необходимость синхронизации запросов на структуры ядра, это -дорогое удовольствие.

Я не спорю с тем фактом, что можно масштабировать и СУБД - блокировщики. Только делается это обычно путем сериализации транзакций ПО внешним по отношению к СУБД, и хранением данных вне СУБД. Ибо если СУБД не позволяет нам организвать нам согласованное чтение активно изменяемых данных, то мы эти данные будем держать вне такой СУБД. Или будем балансировать запросы к СУБД с помощью очередей запросов и мониторов транзакций. Не люблю я такие эклектичные системы гда сам черт ногу сломит. Что-то где-то переглючило, и лови его потом по всем местам. ИМХО данныэ должны лежать в БД, и транзакциями должна "рулить" СУБД.
1 июн 04, 22:11    [715041]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
bbg
Guest
автор
В Оракле хорошо натюненная база доолжна иметь процент кэширования данных где-то 95-99%. Для движков веб-сайтов авторитеты рекомендуют стремиться к 99.9%.

То же верно и для любого блокировочника, и что?

автор
Так что я не согласен насчет того что "поиск нужной версии - процесс не быстрый"

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

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

;)))))))) Как раз вот эти операции, чудо как дешевы, благо ядро ровно под эти операции и заточено.

автор
Только делается это обычно путем сериализации транзакций ПО внешним по отношению к СУБД

Да откуда Вы это взяли? Ну нравится Вам так думать - пожалуйста, но мой опыть, почему-то говорит об обратном. Блокировочник ни чуть не менее самодостаточен чем версионник, ну не знакомы Вы с ними толком и никогда в серьез не работали, и не надо строить догадки.
2 июн 04, 00:11    [715146]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Зл0й
Member

Откуда: Северная Калифорния
Сообщений: 686
Если данные в кэше лежат, то их оттуда достать - дешево. Ибо по кэшу лазить - дурацкое дело нехитрое. Если же нужно сначала получить spinlock на структуру ядра где блокировки лежат, потом туда запрос на блокировку поставить, потом spinlock убрать, потом поспать пока не разбудят и не дадут блокировку, то это - дорого. Тут на одних только переключениях контекста можно хорошо "нагореть". Ну да ладно, это - "подкапотная" механика.

Предположим что нам нужно посчитать сумму значений некоторого стобца по здоровенной таблице в которой все время происходят изменения суммируемых записей. "Грязное чтение" не допускается, по условию задачи. Сервер СУБД - блокировщик (любой - на ваше усмотрение). С удовольствием выслушаю предложения по решению этой проблемы средствами СУБД, то есть без кэширования данных вне СУБД и управления транзакциями вне СУБД. Может хоть научусь чему-то на старости лет ;)
2 июн 04, 01:16    [715180]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
Рискну выложить свою версию решения проблемы для Sybase ASA 9 :)

Если считать сумму для всей таблицы, то наилучшим будет следующее решение:
// Ставим на всю таблицу запрет новым писателям, 
// читатели продолжают работать,
// ждем пока уберутся все текущие работающие писатели
LOCK TABLE Table1 IN SHARE MODE;

// Считаем сумму
SELECT Sum(Field1)
FROM Table1;

// Снимаем блокировку
COMMIT;

Для расчета суммы по некоему фильтру:
// Ставим уровень изоляции в 1 (READ COMMITED)
SET TEMPORARY OPTION ISOLATION_LEVEL = 1;

SELECT Sum(Field1)
FROM Table1
WHERE Field2 = 1;
Естественно для такого случая у нас есть индекс на Field2 на поле или составной (сразу уточню, что в ASA отсутствуют проблемы с блокировками по индексам, например, Identity Primary Key Clustered). В ASA все операции считаются ROW-LOCKING (экскалация на уровень страниц или таблицы неявная автоматическая средствами СУБД, но всегда точная - блокируется только то, что должно быть блокированно), поэтому для нас блокированны записи только теми, кто действительно изменяет или удаляет записи с "Field2 = 1". Далее ждем, пока все писатели освободят наши записи и параллейно смотрим в BOL, насколько мы будем мешаться новым писателям во время выполнения своего запроса (сорри что по английски):
ASA BOL

SELECT statements at isolation level 1
You may be surprised to learn that Adaptive Server Anywhere uses almost no more locks when running a transaction at isolation level 1 (READ COMMITED) than it does at isolation level 0 (READ UNCOMMITED). Indeed, the database server modifies its operation in only two ways.

The first difference in operation has nothing to do with acquiring locks, but rather with respecting them. At isolation level 0, a transaction is free to read any row, whether or not another transaction has acquired a write lock on it. By contrast, before reading each row an isolation level 1 transaction must check whether a write lock is in place. It cannot read past any write-locked rows because doing so might entail reading dirty data.

The second difference in operation creates cursor stability. Cursor stability is achieved by acquiring a read lock on the current row of a cursor. This read lock is released when the cursor is moved. More than one row may be affected if the contents of the cursor is the result of a join. In this case, the database server acquires read locks on all rows which have contributed information to the cursor's current row and removes all these locks as soon as another row of the cursor is selected as current.

Из вышенаписанного можно сказать что мешаться будем, но почти не заметно :)

Гм, тут на примере мало чего видно, к сожалению ASA "самонаводящаяся" СУБД, поэтому по принципам механизма работы уровней изоляций и блокировок нужно смотреть довольно обширные темы BOL (Two-phase locking, Early release of read locks, Special optimizations, anti-insert lock, anti-phantom lock, и т.д.). Ну и плюс не стоит забывать, что в целях повышения производительности можно всегда поиграться опциями BACKGROUND_PRIORITY, DEDICATED_TASK, COOPERATIVE_COMMITS, DELAYED_COMMITS, OPTIMIZATION_GOAL (FirsrRow / AllRow), OPTIMIZATION_WORKLOAD (Mixed / OLAP), READ_PAST_DELETED, SUBSUME_ROW_LOCKS. Например, если у нас поля группировки входят в Clustered Primary Key, то установка OPTIMIZATION_WORKLOAD в значение "OLAP" ко всему прочему включит в оптимизаторе запросов использование алгоритма "Clustered Hash Group By", который показывает отличные результаты не только для аггрегатных запросов, но и тяжелых навороченных OLAP запросов (по рангам, окнам, нарастающими и т.д.).

P.S. Естественно мои примеры ничего не могут поделать, если в БД будет активная сессия, которая будет непрерывно модифицировать данные в пределах одной транзакции. С точки зрения проектировщика БД думаю таких "писателей" надо бы банить, чтоб не повадно было курсорчиками на изменение большого кол-ва данных баловаться :) Ну а по хорошему для скоростной выгрузки/загрузки данных предусмотренны команды UNLOAD и LOAD, плюс чтобы сессии не наглели можно выставить опцию MAX_STATEMENT_COUNT. Думаю такие "писатели" не только бы блокировочникам насоздавали проблем, но и версионникам тоже, хотя последние как я понимаю все равно бы пусть и со скрипом, но продолжали работать :) Ну а писатели, которые просто непрерывно добавляют информацию никому мешаться не будут, в плане добавления информации и механизма блокировок для него, считаю в ASA все сделано идеально, быстро и красиво (думаю это наследие от системы реального времени QNX - у ASA в прошлых версиях была поддержка этой платформы).
2 июн 04, 03:21    [715210]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 32173
2Зл0й
Могу предложить решение.

Если по условию задачи "Грязное чтение" не допускается, значит, это не статистика, а отчёт, "жёсткий" отчёт, который должен "сойтись".

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

Т.е. нельзя хитро (и с удовольствием :-) ) спрашивать, прищурив глаз - "а как это я в блокировочнике получу версию данных"??? Разумеется, никак. Нельзя задавать вопрос по технологии - они несравнимы, разные.

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

А решение этой бизнес-задачи делается на оракле и сиквеле по-разному, не только программирование, но и модель данных, и общие подходы к архитектуре.
2 июн 04, 10:53    [715783]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
bbg
Guest
автор
Если же нужно сначала получить spinlock на структуру ядра где блокировки лежат, потом туда запрос на блокировку поставить, потом spinlock убрать, потом поспать пока не разбудят и не дадут блокировку, то это - дорого

Ага, а при работе с версиями никаких спинлоков накладывать не надо? Та же конструкция, только в профиль.

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

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

автор
Ставим уровень изоляции в 1 (READ COMMITED)

Read Committed не подойдет, может вылезти не согласованность, поэтому нужен как минимум repeatable read.
Если конечно Sybase не удерживает Shared блокировки при RC до конца запроса.
2 июн 04, 11:30    [715974]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Gt.
Guest
автор

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


именно поэтому оракл и дороже, т.е. главное отличие в моделях в том что Том Кайт (представитель оракла) говорит что комит нужно выставлять тогда когда требует бизнес логика, а IBM :

http://www.redbooks.ibm.com/redbooks/pdfs/sg244725.pdf

This scenario illustrates how commit frequency affects the performance of DB2
applications.
In 3.5, “Summary of Recommendations” on page 107, we made some
recommendations related to the need to commit frequently to avoid locking so much
data as to compromise system concurrency. Of course, committing frequently to
release locks has a cost. The commit frequency must be a compromise between
availability and concurrency of data
, and also performance of DB2 applications.

.....

5.1.3 When to Commit?
The question, then, is when to commit. We have seen that frequent commits is
expensive because of increased CPU consumption and elapsed time, and infrequent
commits hurts concurrency. Given a theoretical commit frequency interval of 50
updates, the total interval time for those 50 updates (that is, the total time the pages
are actually locked), depends on the program access path, the physical disposition of
the updates (in case of page or row locking), and the CPU cost of the accesses.
Adding more logic to the program, so that it commits every 0.5 to 5 seconds, appears
to be a useful approach. The exact value can be determined based on the needs of
the environment, the characteristics of the program, and the longest running SQL
statement in the program.
If any SQL call takes more than 5 seconds, any possible commit interval based
control is of no use, as previous locks remain until the SQL finishes. We recommend
modifying the database design (for instance, adding one more index) or the logic of
the program. If this is not possible, then the only solution is to insert a commit
point before the long SQL call so that all previous locks are not held until the long
SQL call finishes.
2 июн 04, 11:54    [716065]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Зл0й

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

Все вышеизложенное - наблюдения из моего личного опыта. Your mileage may vary.


Вы совершенно правы.

Именно это очень серьезно отличает Oracle от MSSQL.
Пусть бросят в меня камень, но 10лет ни разу не встретил "чистый OLTP".

Вот нашел совсем недавно. Я просто плакал, по другому не скажешь.

http://www.microsoft.com/technet/prodtechnol/sql/yukon/maintain/sqlydba.mspx

Two Special Scalability Features
There are two scalability features that are worth mentioning for very large
database scenarios. Snapshot Isolation Level allows users to access the last
committed row using a transitionally consistent view of the database. This
new isolation level provides the following benefits:

1. Increased data availability for read-only applications.

2. Non-blocking read operations are allowed in an OLTP environment.

3. Automatic mandatory conflict detection for write transactions.

4. Simplified migration of applications from Oracle to SQL Server.


For example, locking can cause blocks between applications that are reading
and writing the same data simultaneously
. If a transaction changes a row,
then another transaction cannot read the row until the write commits
. With
SI, the reader can access the previous committed value of the row. The
second special scalability feature is table partitioning.

While the concept of partitioning data across tables, databases and servers
is not new to the world of databases, SQL Server Yukon provides a new
infrastructure capability for partitioning of tables across filegroups in a
database. Horizontal partitioning allows division of a table into smaller
groupings based on a partitioning scheme. Table partitioning is designed for
very large databases; hundreds of Gigabytes into Terabytes and beyond. Very
large database (VLDB) query performance is improved with partitioning. By
partitioning across a range of partitioning column values, subsets of data
can be managed and reassigned to other tables quickly and efficiently. To
learn more about Partitioning see SQL Server Books Online

Мне и в голову не могло прейти (пункт 3), что у ядро MSSQL не обрабатывает сутуации с взаимоблокировками ?
А пункт 2 это как раз признание компанией того факта, что таки да, таки есть проблемы.

Вообщем читайте и наслаждайтесь.
23 июл 04, 16:41    [831609]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Nord
Guest
2 EugeneS

"Мне и в голову не могло прейти (пункт 3), что у ядро MSSQL не обрабатывает сутуации с взаимоблокировками ?"

Вам напрасно пришло это в голову :)

"А пункт 2 это как раз признание компанией того факта, что таки да, таки есть проблемы"

Да тыщу раз это уже обсуждалось, и тут в том числе. У блокировочника в одном месте проблемы, у версионника в других. В идеале хорошо бы иметь комбинацию 2-х подходов. Первой такой комбинацией будет похоже Юкон.
23 июл 04, 18:12    [831940]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Nord
2 EugeneS

"Мне и в голову не могло прейти (пункт 3), что у ядро MSSQL не обрабатывает сутуации с взаимоблокировками ?"

Вам напрасно пришло это в голову :)

"А пункт 2 это как раз признание компанией того факта, что таки да, таки есть проблемы"

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


пункт 3.
Ну раз в таком документе упомянули про это, значит "есть еще над чем работать".

пункт 2.

Ага.
"Будет, если репа не треснет". (Сори за каламбур).

Я уверяю вас, что после выхода Юкона, режим версионика для него будет станет обычным режимом работы и это одна из фитч, чего не хватало MSSQL.
Или не так?

Очень понравилось высказывания сдесь.
[url=http://]http://www.rsdn.ru/article/db/yukonvers.xml#XSLTPART147120120[/url]
Читата из журнала.
автор
Немаловажно также и то, что писать приложения для БД с поддержкой версионности попросту удобнее. Отсутствие необходимости отслеживать возможные конфликты читающих и пишущих запросов здорово облегчает жизнь, особенно не слишком опытным разработчикам, и повышает масштабируемость системы (хотя в этом случае выше вероятность появления некоторых неочевидных эффектов).

Умереть не встать.

Ну да конечно, если вы считаете , что это классно когда писатель блокирует читателя , тогда да. С гурманами трудно спорить, пользователям только не нравится, а так все путем.
Просто я реально замечаю внедрение фитч со строоны MSSQL, которые у Oracle уже давненько в работе.
Конечно радует, что MSSQL постепенно становится серьезным продуктом.

Будете настаивать на обратном?
23 июл 04, 19:27    [832091]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Сергей Васкецов
Member

Откуда:
Сообщений: 20362
alex_k
да я уже устал говорить о таком недостатке как несовместимость сокетов и файловых дескрипторов.

Это о чем говорит? кроме моей работоспособности :-)

О том, что Вы не разбираетесь в поставщиках транспорта (SPI).

Все стандартные базовые поставщики транспорта в Windows NT - IFS-поставщики, описатели сокетов, которые они выдают, всегда являются объектами ядра типа File, и к ним могут применяться файловые операции.

Если у Вас возникнет желание написать не-IFS-поставщик транспорта, то есть, такой, чтобы описатели его сокетов не были файлами, Вы всегда можете это сделать, равно как и написать свой IFS-поставщик транспорта.
24 июл 04, 02:35    [832583]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Nord
Guest
2 Eugene S. Уважаемый, вы же должны понимать, что фраза "читатель не блокирует писателя" не более, чем маркетинговый слоган :) Да, не блокирует, в том смысле, что оба продолжают работать, только писатель должен копии старых данных записывать, а читатель делать микрооткаты для получения старых версий данных. Совсем не факт, что это всегда быстрее блокировочника.
25 июл 04, 10:36    [833407]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Ну-ну,
Ну если это маркетинговый ход, хочу послушать, как в MSSQL 2000 можно получить отчет по таблице, в которую непрерывно сыпятся короткие транзакции, на определенный момент времени ( я про то, что не должны учитываться изменения сделаные в таблице начиная с момента старта отчета), при этом не должна нарушаться работы основного приложения?


Что вы имеете ввиду под микро-откатами?
То что необходимые блоки читаются вместо одного файла из другого, и то если их нет в кэш-буфере?
Предполагаю - это новое изобретение от Microsoft микрооткаты.

Насчет быстродействия блокировочника.
Я допускаю, что блокировочник может быть быстрей мультиверсиионника на чистом OLTP.
Вы видели где-нибудь чистый OLTP?
Я, за 10 лет ни разу.
Это как идеальная женщина , вроде должна быть, а в реальном мире отсутствует. Следовательно преймущества в быстродействии очень сомнительны, по причине невозможности получить отчет на основе данных на определенный момент времени.
Это все равно, что сравнивать БД с журналом транзакций и без него.
Выйгрыш сами знаете у кого будет, только кому от этого хорошо.
Это в стиле сравнения FOX-PRO с Oracle.
26 июл 04, 10:54    [834145]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Nord
Guest
2 EugeneS
Ну что же вы сразу по больному месту :) Тут версионник лучше смотрится.
Однако, если смотреть на производительность как на количество транзакций в единицу времени, то блокировочник обычно их может побольше выполнить. Pассмотрим накладные расходы на обеспечение одновременного доступа.
Если взять суммарное время, нужное на выполнение N-ного числа транзакций при условии, что эти транзакции не конфликтуют, то

1. Для блокировочника надо прибавить только время установки/снятия блокировок чтения. Это очень быстрые in-memory операции. Правда, если почитать Тома Кайта может сложится впечатление, что это не так :) Как он описывает диспетчер блокировок - это просто песня. Складывается впечатление, что человек искренне полагает, что SQL Server или DB/2 имеют ОДИН большой список блокировок, который надо заблокировать, полностью просмотреть, поставить блокировку, потом опять заблокировать и снять :).
Чтобы повысить степень паралеллизма можна:
a) Эскалировать блокировку. Тогда, во первых, меньше времени расходуется на установку/снятие, во-вторых экономится память.
б) Использовать менее строгий уровень изоляции. Если, я, например, менеджер по продажам пива в крупной сети супермаркетов, то для получения информации для анализа типа сколько пива продано с начала месяца, я могу смело читать грязные данные. Ну что с того, что кто-то купил 2 ящика пива, а потом транзакция откатилась, если речь идет о сотнях и тысячах ящиков ? Или, например, я вывожу список 20 последних продаж с уровнем изоляции read commited. Моя транзакция считывает 10, а потом вклиниваются две транзакции, которые меняют одну считанную и одну несчитанную запись. Таким образом тот набор 20 записей, что я получу, никогда не существовал в базе. Однако каждая его запись существуе или существовала 5 секунда назад и результат можно считать вполне корректным. В описанных случаях блокировки чтения вообще не ставятся.
Это, конечно, не прокатит для выписки по банковским счетам, где деньги могут переходить со счета на счет. Если нужны сложные согласованные отчеты, то есть разные методы, начиная от прогонки этих отчетов ночью и заканчивая введением агрегирующих таблиц и OLAPa.

2. Для Oracle надо

1) для каждого изменения писать информацию, кроме собсвенно файла данных и журнала, еще и в rollback segmentы, причем независимо от того, понадобится впоследствии эта информация или нет. Операции ввода/выводы как известно самые дорогие. Так что в читом OLTP с огромным количеством маленьких апдейтов у Oracle шансов мало.

2) каждый раз, когда транзакция читает блок, надо http://www.optimaldba.com/library/UndoInternalsPresentation.pdf
1. Read the Data Block.
2. Read the Row Header.
3. Check the LockByte to determine if there is an ITL entry.
4. Read the ITL to determine the Transaction ID.
5. Read the Transaction Table. If the transaction has been committed and has a System Commit Number less than the
query’s System Change Number, cleanout the block and move on the next data block (if required) and Step 1.
6. Read the last undo block indicated
7. Compare the block transaction id with the transaction table transaction id. If the Transaction ID in the undo block
does not equal the Transaction ID from the Transaction Table, then signal an ORA-1650, Snapshot Too Old.
8. It the txids are identical, clone the data block in memory. Starting with the head undo entry, apply the changes to the
cloned block.
9. If the tail undo entry (the last one read) indicates another data block address, read the indicated undo block into
memory. Repeat 7 & 8 until the first record does not contain a value for the data block address.
10. When there is no previous data block address, the transaction has been undone.
11. If the undo entry contains
a) a pointer to a previous transaction undo block address, read the TxID in the previous transaction undo block
header and read the appropriate Transaction Table entry. Return to step 5.
b) an ITL record, restore the ITL record to the data block. Return to step 4.
Именно это я называл микро-откатом. Как видите изобретение не Микрософтовское. Если вы читали статью про Юкон, то вы знаете, что в Юконе версионность основана не на блоках, а на строках и никаких микро-откатов делать не надо, надо просто взять старое значение строки. ИМХО, конечно, но это эфективнее.

3) В Оracle в общем случае при равных условиях будет работать большее количество процессов/потоков одновременно. Если процесс/поток читающей транзакции в блокировочнике заснет на мьютексе или еще каком-нибудь объекте синхронизации, то в Oracle он будет продолжать работать. Таким образом у нас увеличеваются накладные расходы ОС на переключение контекстов между процессами/потоками и диспечеризацию.

Опять-таки ИМХО, конечно, но первое эфективнее :)
27 июл 04, 13:41    [838255]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
автор

Ну что же вы сразу по больному месту :) Тут версионник лучше смотрится.
Однако, если смотреть на производительность как на количество транзакций в единицу времени, то блокировочник обычно их может побольше выполнить.

Если мы так будем рассматривать, то круче всех будет выглядеть MySQL или FoxPro? Не так ли ?


автор
1. Для блокировочника надо прибавить только время установки/снятия блокировок чтения. Это очень быстрые in-memory операции. Правда, если почитать Тома Кайта может сложится впечатление, что это не так :) Как он описывает диспетчер блокировок - это просто песня. Складывается впечатление, что человек искренне полагает, что SQL Server или DB/2 имеют ОДИН большой список блокировок, который надо заблокировать, полностью просмотреть, поставить блокировку, потом опять заблокировать и снять :).
Чтобы повысить степень паралеллизма можна:
a) Эскалировать блокировку. Тогда, во первых, меньше времени расходуется на установку/снятие, во-вторых экономится память.
б) Использовать менее строгий уровень изоляции. Если, я, например, менеджер по продажам пива в крупной сети супермаркетов, то для получения информации для анализа типа сколько пива продано с начала месяца, я могу смело читать грязные данные. Ну что с того, что кто-то купил 2 ящика пива, а потом транзакция откатилась, если речь идет о сотнях и тысячах ящиков ?

Вот так и появляются "утечки", "утруски" и оптимизации.
То есть реально узнать сколько осталось пива на складе, можно лишь чисто теоретически ?


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

1.Ну то есть серьезные системы лучше на MSSQL не строить, иначе денег не досчитаться ?
Вот вам пример "Процессинговый центр" у него не бывает ситуации когда он простаивает, поэтому ночь его как вы понимаете не спасет.
2.Агрегирующих таблицы не спасут так же, по причине получаются путем snapshot-а реальных таблиц на определенный моментвремени , а поскольку консистентную копию таблицы на определенный момент времени получить в MSSQL мягко говоря затруднительно, то и агрегирующим таблицам тоже грош цена.
3. О да это возможно выход , только это как бы это сказать дополнительные телодвижения и дополнительный overhead на создание и подержание OLAP БД.

То есть в результате мы получаем, что сэкономив и получив высокое быстродействие на вводе или регистрации информации (OLTP cистема) мы получаем overhead на ее обработке ее анализе.
Опять же, я еще не видел чистых систем OLTP.
Вы видели? Если да, приведите пример.

2. Для Oracle надо

автор
) для каждого изменения писать информацию, кроме собсвенно файла данных и журнала, еще и в rollback segmentы, причем независимо от того, понадобится впоследствии эта информация или нет. Операции ввода/выводы как известно самые дорогие. Так что в читом OLTP с огромным количеством маленьких апдейтов у Oracle шансов мало.

Ну вообще-то можно заставить Oracle работать без записи в сегмент отката на OLTP cистемах, но лично я считаю, что это для маньяков.

Oracle8i Designing and Tuning for Performance
Release 2 (8.1.6)

автор
Discrete transaction processing is useful for transactions that:

Modify only a few database blocks.

Never change an individual database block more than once per transaction.

Do not modify data likely to be requested by long-running queries.

Do not need to see the new value of data after modifying the data.

Do not modify tables containing any LONG values.

In deciding to use discrete transactions, you should consider the following factors:

Can the transaction be designed to work within the constraints placed on discrete transactions, as described in "Using Discrete Transactions".

Does using discrete transactions result in a significant performance improvement under normal usage conditions?

Discrete transactions can be used concurrently with standard transactions. Choosing whether to use discrete transactions should be a part of your normal tuning procedure. Discrete transactions can be used only for a subset of all transactions, for sophisticated users with advanced application requirements. However, where speed is the most critical factor, the performance improvements can justify the design constraints.

How Discrete Transactions Work
During a discrete transaction, all changes made to any data are deferred until the transaction commits. Redo information is generated, but it is stored in a separate location in memory.

When the transaction issues a commit request, the redo information is written to the redo log file (along with other group commits), and the changes to the database block are applied directly to the block. The block is written to the database file in the usual manner. Control is returned to the application after the commit completes. Oracle does not need to generate undo information, because the block is not actually modified until the transaction is committed, and the redo information is stored in the redo log buffers.

As with other transactions, the uncommitted changes of a discrete transaction are not visible to concurrent transactions. For regular transactions, undo information is used to re-create old versions of data for queries that require a consistent view of the data. Because no undo information is generated for discrete transactions, a discrete transaction that starts and completes during any query can cause the query to receive the "snapshot too old" error if the query requests data changed by the discrete transaction. For this reason, you might avoid performing queries that access a large subset of a table that is modified by frequent discrete transactions.


автор
2) каждый раз, когда транзакция читает блок, надо http://www.optimaldba.com/library/UndoInternalsPresentation.pdf


Хорошая статья.

автор
Именно это я называл микро-откатом. Как видите изобретение не Микрософтовское. Если вы читали статью про Юкон, то вы знаете, что в Юконе версионность основана не на блоках, а на строках и никаких микро-откатов делать не надо, надо просто взять старое значение строки. ИМХО, конечно, но это эфективнее.

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


3
автор
) В Оracle в общем случае при равных условиях будет работать большее количество процессов/потоков одновременно. Если процесс/поток читающей транзакции в блокировочнике заснет на мьютексе или еще каком-нибудь объекте синхронизации, то в Oracle он будет продолжать работать. Таким образом у нас увеличеваются накладные расходы ОС на переключение контекстов между процессами/потоками и диспечеризацию.


Можно подробней откуда вы это взяли?
Как и в любой другой системе для доступа к ресурсу например (память, блоки и пр. ) используется аналогичный механизм. Если скажем, в блоке нет места чтобы транзация записала свой ITL , например потому что недостаточно свободного места в блоке, то остальные транзакции с претензией на изменение этого блока просто будут ждать, пока одна из транзакций меняющих строку в блоке не выполнит сommit и тем самым не освободит блок,для того чтобы другие транзакции смогли с ним работать.
Вы же не думаете, что если Oracle мультиверсиионник , то он не использует mutex или семафоры ?
Число пользовательских процессов в Oracle равно числу сессий + системные процессы обеспечивабщие работу экземпляра.

автор
Опять-таки ИМХО, конечно, но первое эфективнее :)

Зависит от того какую цену мы за это платим.
Лично мне цена кажется оправданной и обещание сделать такое же в Юконе тому подверждение.
27 июл 04, 16:22    [839259]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
2EugeneS
>1.Ну то есть серьезные системы лучше на MSSQL не строить, иначе денег не досчитаться ?
не хочется снова приводить набивший оскомину пример про СБРФ, который перешел на MS SQL 2000... но всё-таки.....
А за прочими - суксес-сторями - это на www.microsoft.com, там таких полно.
27 июл 04, 16:45    [839432]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
EugeneS

Вот так и появляются "утечки", "утруски" и оптимизации.
То есть реально узнать сколько осталось пива на складе, можно лишь чисто теоретически ?


У Oracle как это будет выглядеть сильно по другому??? Мы получим результат на момент начала отчета. А у нас полсклада смогут выписать за это время.
27 июл 04, 17:03    [839536]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Сергей Васкецов
Member

Откуда:
Сообщений: 20362
Nikolay Kulikov
Мы получим результат на момент начала отчета. А у нас полсклада смогут выписать за это время.

Независимо от сервера/его версионности ВЕСЬ склад выпишут после того, как сформирован результат, и до того, как он поребовался.
27 июл 04, 17:48    [839757]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Nord
Guest
2 EugeneS
"Если мы так будем рассматривать, то круче всех будет выглядеть MySQL или FoxPro? Не так ли ?"

Нет. Уж точно не ФохПро. И скорее всего не MySQL. Если только мы не гоняем очень простые запросы на не-транзакционных таблицах.

"Вот так и появляются "утечки", "утруски" и оптимизации.
То есть реально узнать сколько осталось пива на складе, можно лишь чисто теоретически ?"

Нет. Это можно и практически. Но не всегда нужно. В данном примере не нужно. И в данном примере, накладные расходы на обеспечение неблокированной одновременной работы читателя и писателя реально практически отсутствуют: не надо писать в сегменты отката, не надо откатывать изменения, не надо даже блокировок чтения ставить. Oracle так не может.

"1.Ну то есть серьезные системы лучше на MSSQL не строить, иначе денег не досчитаться ?" и т.д.

Сходите дейсвительно на сайт MS и почитайте success story крупных enterprisов. Я не говорил, что MS SQL обязательно нужно использовать для решения любой задачи от процессингового центра до анализатора логов :) Но то что он в 99% случаев справится с задачей не хуже Oracle - это точно. У меня есть один приятель, который на полном серьезе уверен, что его конторку в 20 человек не потянет ни один блокировочник :) Да кстати, ну ладно МС сакс и все такое, а DB/2 по вашему тоже не годится для любой более-менее серьезной задачи ?

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

Согласен. Юкон только-только стал бетой.

"Можно подробней откуда вы это взяли? "

Ну как откуда. Читатель не блокирует писателя и оба процесса продолжают работать. В блокировочнике один из них заснет. Грубо говоря, если у нас 100 одновременных транзакций из которых 50 читателей конфликтуют за данные с 50 писателей, то в Oracle надо переключатся между 100 процессами/потоками и диспечиризовать 100 процессов/потоков. В блокировочнике - 50.

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

Да не такая уж страшная цена :)
В Юконе не отказываются от чисто блокировочного подхода и по умолчанию версионность не включается, судя по статье.
27 июл 04, 18:44    [839926]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Nikolay Kulikov
EugeneS

Вот так и появляются "утечки", "утруски" и оптимизации.
То есть реально узнать сколько осталось пива на складе, можно лишь чисто теоретически ?


У Oracle как это будет выглядеть сильно по другому??? Мы получим результат на момент начала отчета. А у нас полсклада смогут выписать за это время.


Это не важно, что у нас за это время продадут.
Важно, что ситуацию можно проанализировать на определенный момент.
28 июл 04, 10:47    [841124]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Nord
Guest
2 EugeneS
"Это не важно, что у нас за это время продадут.
Важно, что ситуацию можно проанализировать на определенный момент."

Что вы имеете в виду, говоря на конкретный момент ? Важно чтобы данные были согласованные, а на момент начала транцакции или на момент +2 секунды от начала, какая разница ? В данные продаж пива обязательно надо включать время операции и тогда можно получить остатки на складе на любой момент.
Или вы предлагаете, например, в процессинговом центре ровно в полночь запускать отчет и таким образом получать данные за день работы ? :)
28 июл 04, 11:13    [841263]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Nord
2 EugeneS
"Если мы так будем рассматривать, то круче всех будет выглядеть MySQL или FoxPro? Не так ли ?"

[quot автор]Нет. Уж точно не ФохПро. И скорее всего не MySQL. Если только мы не гоняем очень простые запросы на не-транзакционных таблицах.


Сложные запросы обычно на OLTP не гоняют иначе время отклика упадет.
Так что немного мимо.

"Вот так и появляются "утечки", "утруски" и оптимизации.
То есть реально узнать сколько осталось пива на складе, можно лишь чисто теоретически ?"

автор
Нет. Это можно и практически. Но не всегда нужно. В данном примере не нужно. И в данном примере, накладные расходы на обеспечение неблокированной одновременной работы читателя и писателя реально практически отсутствуют: не надо писать в сегменты отката, не надо откатывать изменения, не надо даже блокировок чтения ставить. Oracle так не может.


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

автор
Сходите дейсвительно на сайт MS и почитайте success story крупных enterprisов. Я не говорил, что MS SQL обязательно нужно использовать для решения любой задачи от процессингового центра до анализатора логов :) Но то что он в 99% случаев справится с задачей не хуже Oracle - это точно. У меня есть один приятель, который на полном серьезе уверен, что его конторку в 20 человек не потянет ни один блокировочник :) Да кстати, ну ладно МС сакс и все такое, а DB/2 по вашему тоже не годится для любой более-менее серьезной задачи ?



Ходил, и даже читал мурню про замену Oracle на MSSQL вместо того чтобы просто смигрировать Oracle cо старой железки(HP) на новую или даже просто на Intel платформу.

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

Суть в том , что я технический специалист и мне "success story", до лампочки, мне необходимо наоборт снять всю эту мишуру и докопаться до истины, найти узкие места . И когда наконец это будет найдено, вот тогда вы реально понимаете почему Oracle cтоит 40к за процессор, а не 20к как MSSQL да и еще много чего.

Насчет success story раскажу историю из жизни не относящуюся к программированию вообще. В свое время был такой приз "Голубая лента Атлантики" вручался океанскому лайнеру, который в кратчайшее время пересечет атлантический океан. Так вот еще на заре одна из компаний выставила на гонку пароход "Сириус" ,который был не совсем хорош для океанских рейсов, а другая построила себе пароход с серьезным подходом ( двойные переборки , громадный и достаточно большой для океанских рейсов "Грей Истерн" ( если мне не изменяет память).
Так вот Сириусу , удалось чудом выйти раньше из порта на несколько дней, и когда он пересек океан при в ходе в порт на нем уже много чего не было ( мачты , и все что могло гореть спалили из-за нехватки угля, а что пережили пассажири из-за качки и прочих удобств одному богу известно ) и всего через несколько часов пришел Грей Истерн ( у него в трюмах еще оставалось более 100 т угля).
Но увы дело было сделано и Сириус вошел в историю стал первым судном перекшим атлантику при помощи пара.
Правда прослужил он всего пару лет после этого , но это как вы понимаете мелочи.
Ну выводы делайте сами .



"Можно подробней откуда вы это взяли? "

автор
Ну как откуда. Читатель не блокирует писателя и оба процесса продолжают работать. В блокировочнике один из них заснет. Грубо говоря, если у нас 100 одновременных транзакций из которых 50 читателей конфликтуют за данные с 50 писателей, то в Oracle надо переключатся между 100 процессами/потоками и диспечиризовать 100 процессов/потоков. В блокировочнике - 50.


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

На мой взгляд MSSQL архитектурно отстает от Oracle
примерно лет так на 3-6 лет, а этот недостаток пытается "залепить" маркетингом, что у нее очень хорошо получается.
28 июл 04, 11:28    [841341]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
Nikolay Kulikov
Member

Откуда: Москва
Сообщений: 607
2EugeneS
Какой смысл в этих данных если они уже не актуальны сейчас. Что ты сможешь проанализировать. Кстати Количество пива на складе не такой уж и сложный запрос, сколько строк у тебя попадет под этот запрос 100 1000 5000???
28 июл 04, 11:28    [841346]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
EugeneS
Member

Откуда:
Сообщений: 1255
Nord
2 EugeneS
"Это не важно, что у нас за это время продадут.
Важно, что ситуацию можно проанализировать на определенный момент."

Что вы имеете в виду, говоря на конкретный момент ? Важно чтобы данные были согласованные, а на момент начала транцакции или на момент +2 секунды от начала, какая разница ? В данные продаж пива обязательно надо включать время операции и тогда можно получить остатки на складе на любой момент.
Или вы предлагаете, например, в процессинговом центре ровно в полночь запускать отчет и таким образом получать данные за день работы ? :)


Я имею ввиду, что отчет строится используя подтвержденные изменения на момент запуска запроса, а не как в случае с MSSQL берется "то что есть".
28 июл 04, 11:35    [841400]     Ответить | Цитировать Сообщить модератору
 Re: Провал операции Yukon  [new]
locky
Member

Откуда: Харьков, Украина
Сообщений: 62034
2EugeneS
>Ходил, и даже читал мурню про замену Oracle на MSSQL вместо того чтобы просто
>смигрировать Oracle cо старой железки(HP) на новую или даже просто на Intel платформу.
Видать перейти на другую платформу и полностью сменить ПО было дешевле, чем заменить железяку без смены платформы и ПО. Тоже, кстати, очень немаловажный показатель. Кстати, при этом, я так полагаю, качество системы было улучшено, иначе никто не затеял такую замену.
P.S. Лирическое, так сказать, отступление - но Вы первый начали!
2004 год. В порт города N приход потомок "Сириуса", пересекший атлантику за 3, скажем, дня. Он быстрый, тихий, удобный, экологически чистый - хороший потомок слегка глючного прототипа. А следом за ним, чадя, качаясь и поскрипывая подгреб всё-таки наш "пароплав"... у него даже еще остался уголь! У него двойные толстые переборки! И фиг с тем, что современный углепластик вдвое легче и прочнее стали! Мы используем решения проверенные веками!
Почитайте на дОсуге Гаррисона, "Специалист по этике" (еще называют "Моралист"). Там было описано замечательно общество, живущее по принципу "Что было хорошо для наших дедов-то хорошо и для нас". Пока не появился дин Альт, так и было. но пришел герой, принёс новые технологии - и все заверте....
P.P.S Може всё-таки не будем сравнивать СУБД - какая лучше , какая хуже? Будем сравнивать применение конкретных инструментов для конкретных задач при конкретных условиях? И способы разрешения тех или иных ограничений?
А то получается вопрос: что лучше - яблоки или гвозди?
28 июл 04, 11:51    [841492]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 13 14 15 16 17 [18] 19 20 21 22 .. 26   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить