Здравствуйте, Sinclair, Вы писали:
S>$1000 не получилось найти? Скинулись бы по десятке да засабмиттили...
А зачем?
Когда Oracle с IBM меряются, оно понятно, речь идёт о рынке и баблосах.
А для FreeWare это зачем?
Повторяю, неофициальные тесты опубликованы. Выводы сделаны.
Здравствуйте, Sinclair, Вы писали:
КДВ>>Например, Вам же никто не запрещает в ОДНОЙ программе открыть ДВА коннекта и обмениваться данными КДВ>>между ЭТИМИ транзакциями? Нет? Ну и славно. S>Нет, не запрещает. Но это не является необходимостью. Это — порочная практика, и пока что я не могу понять, почему вы так упорно защищаете ее аналог.
Кто сказал, что это аналог? Вам пытаются объяснить, что есть случаи, когда использование параллельной транзакции наиболее удобный выход.
Например для меня:
— Загрузка данных из справочников по первому требованию.
— Периодическая запись накопившихся данных в информационный лог из другого потока.
Здравствуйте, Sinclair, Вы писали:
AC>>в основном, на энтузиазме разработчиков оного. Средств, дабы осуществить AC>>официальное тестирование, нужно сперва где-то изыскать... S>$1000 не получилось найти? Скинулись бы по десятке да засабмиттили...
да никому это не надо. эту тысячу лучше вложить в разработку, и то полезнее.
тесты на tpc.org, если человек понимает, оценивают сервер+железо.
да, есть задачи, которые требуют офигительного железа и офигительных скоростей
обработки. по tpc.org можно что-то себе подобрать. Но выбор сервера или оценка
сервера по tpc.org — это идиотизм, не побоюсь этого слова.
Даже при выборе только блокировочной (или версионной) архитектуры для задачи это не гарантия,
что один и тот же код будет работать максимально быстро на выбранной группе
серверов.
Поэтому tpc.org не является определяющим критерием при выборе сервера, да и собственно,
важность этого критерия стоит где-то на десятом месте после остальной специфики.
Например, по оригинальному вопросу этого топика — куда бы предложил засунуть
автор вопроса отсылку на tpc.org ?
Здравствуйте, Кузьменко Д.В., Вы писали:
КДВ>Поэтому tpc.org не является определяющим критерием при выборе сервера, да и собственно, КДВ>важность этого критерия стоит где-то на десятом месте после остальной специфики.
КДВ>Например, по оригинальному вопросу этого топика — куда бы предложил засунуть КДВ>автор вопроса отсылку на tpc.org ?
В MSDN
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, kuj, Вы писали:
kuj>Зачем Вы тратите свое время? Спорить с фанатиками firebird бесполезно. Для них FB это единственная правильная СУБД и точка. kuj>Не пытайтесь их переубедить — только реалии жизни с этим справятся.
здесь нет фанатиков FB. Здесь есть люди, которые в основном используют FB, но при этом работали
с MS SQL, Oracle, PostgreSQL, MySQL и другими серверами. Я, например, вовсю попрограммировал
и на MUMPS (и еще знаком с Informix, правда в общих чертах, но ближе к администрированию).
Да, я не испытываю особой любви к блокировочной архитектуре. Но вполне четко могу определить,
какая задача будет легче решена на блокировочном сервере, а какая на версионном.
И нисколько не смущаясь, выбрать именно тот сервер, который лучше подойдет для решения задачи.
Именно поэтому меня (и нас "фанатиков FB"), удивляет ортодоксальность мнений оппонентов.
Основная суть этого спора, что "две транзакции в одном коннекте — плохо и неправильно".
И то же самое начали применять даже к "два коннекта в одном приложении — это плохо".
При том что Д. Коваленко написал, что в последних версиях драйверов от MS УЖЕ
предусматривается возможность старта двух и более транзакций одновременно в одном соединении.
Если подобная функциональность в FB вызывает неприятие, тогда давайте повернем вопрос
в плоскость вашего сервера — зачем MS расширяет собственную функциональность АНАЛОГИЧНЫМ способом?
Я напомню, что похожие баталии были по поводу версионности — типа, все это фигня и никуда
не годится. Оглянитесь вокруг — версионность нынче в Oracle, PostgreSQL, MySQL и даже MS SQL.
Аналогии с текущим спором не просматривается?
Здравствуйте, Sinclair, Вы писали:
A>>Ты наверное не догнал, S>не догнал. Уж очень задача экзотическая.
Просто в данной задаче все решено более изящно чем обычная проверка по таймеру наличия в БД некоторых записей. Я не хочу загружать сервак ненужными запросами и реагирую на появление данных только тогда когда мне это надо. А вот когда событие произошло тогда и делается запрос. Все очень просто.
A>> но записи надо печатать по одной или более, на одном или более принтерах, причем сбойнуть может любой принтер в любой момент, а остальные должны продолжать печатать. Т.е. если я работаю в одной транзакции то должен после каждой делать коммит вместо того чтобы в данном случае просто сделать откат обновляющей транзакции? Я правильно понимаю? S>Конечно. Я не понимаю, каким образом тебе поможет откат обновляющей транзакции.
Отменой удаления и поможет. Это что — непонятно? А на принтере отмену напечатать вообще в 5 секунд.
A>>С таблицей однозначно делаются только операции вставки и удаления. Причем некоторые записи должны быть напечатаны в одном пакете, и если произошла хоть одна ошибка при печати то откатить весь пакет и соответственно пропечатать отмену печати при необходимости. S>То, что печатается пакетом, делается в одной транзакции.
В той же которая читает? Т.е. после каждого пакета мне надо коммитить читающую транзакцию и запускать новую практически? А если посмотреть на мое решение, то там печать тоже делается в одной транзакции.
A>>Первая читающая транзакция, можно сделать так что нагрузка сервера будем минимальна изначально (кстати, про такое Вы наверное не знаете?). S>Может, и не знаю. Пока что я вообще не могу понять, чего хочется получить.
Требуемую распечатку в ЕДИНСТВЕННОМ экземпляре. Все очень просто. Задача специфическая для любых кафе в данном случае.
A>>Вторая чисто под удаления запускается. В чем порочен данный метод? Или мне надо делать два коннекта? S>Удобнее всего делать столько коннектов, сколько принтеров.
Интересно. Я не против завести море коннектов, но если сервер мне позволяет все сделать в одном коннекте и это не противоречит ACID, то на кой мне париться?
Здравствуйте, _d_m_, Вы писали:
R>>Да вот есть уже у меня одно подключение. Зачем мне второе создавать? Я хотел лишь сказать, что во втором подключении нет необходимости — вот и все.
___>здесь
Причем тут это сообщение. Там все тоже самое... омм мане падме хум... зачем параллельная транзакция, когда можно создать подключение? Ну вот, я говорю, есть у меня уже подключение, есть. Я могу в этом подключении создать новую транзакцию, и результат работы будет таким же. Ну вот блин зачем мне новое подключение создавать? Зачем? Можно на этот вопрос внятно ответить?
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Alex.Che, Вы писали:
S>1) Незафиксированное Чтение (READ UN-COMMITED). S>2) Зафиксированное Чтение (READ COMMITED). S>3) Повторимое Чтение (REPEATABLE READ). S>4) Сериализуемость (SERIALIZABLE).
S>Они определяются с помощью классического определения сериализуемости и трех запрещенных последовательностей операций, названных феноменами: Грязное Чтение, Неповторимое Чтение и Фантом. S>[/q]
и? статья-то о том, что
а) данных уровней изолированности не хватает
б) базовые уровни изолированности ориентированы на блокировочные сервера
в) некоторые уровни изолированности описаны криво
все это не говорит о том, что единственно возможный применимый в реальной жизни уровень
изолированности транзакций — сериализация. Да, я согласен, некоторые задачи
решаются только сериализацией. Например, у меня на курсах примерно в 98 году был
мужик, который заявил:
— зачем вы об уровнях изолированности рассказываете? у нас все четко — вагон
пришел, попал под разгрузку, и ушел. Тут никаких конфликтов быть не может.
Но в реальной жизни сериализация — вовсе не обязательное условие, а даже очень частное.
Два человека могут читать одну книгу одновременно.
несколько человек могут находиться в одном вагоне.
несколько человек могут читать копию одной книги одновременно
и так далее.
Здравствуйте, IB, Вы писали:
КДВ>>не буду. я хочу аргументации, со ссылкой. IB>Ссылкой на что? Аргументы, в виде механизма работы оракла при RC, я описал. FB, очевидно, так не поступает. IB>Есть контраргумнты, о знатоки версионности и FB?
ссылкой на документ, в котором написано про миниоткаты в RC в Оракле.
я поискал на techdocs, ничего похожего не нашел.
КДВ>> или версионность в MS SQL уже 23 года? Или Вы (ты) работаете(шь) с версионным сервером лет 12 ? IB>Причем тут MSSQL?
не знаю. Вы заявили, что Вы знаете версионность лучше меня. Я не нахожу причин
для такого утверждения. IB/FB Вы не знаете, а следовательно никак не можете
составить ПОЛНУЮ картину по реализации версионности в СУБД. Я напомню,
что в различных вариантах версионность есть в Oracle, InterBase/Firebird, MS SQL,
PostgreSQL и MS SQL 2005.
КДВ>>В ЧЕМ ОНА ОТЛИЧАЕТСЯ. Прошу сообщить. IB>Я. уже. сообщил. Я даже не поленился алгоритм описать, правда без бодробностей. Может потрудишься прочитать?
"Оракл совершает миниоткат при обраружении измененных данных, читаемых в RC" — это "алгоритм"?
Это муть голубая.
КДВ>>Я Вам уже кучу ссылок дал, а Вы все как-то по нулям. IB>Ссылки только что-то не конкретненькие, я тоже в MSDN послать могу, у меня не застрянет...
я про миниоткаты в Оракле спросил, MSDN мне без надобности.
Здравствуйте, SmlMouse, Вы писали:
КД>>Мда. Я вот решил перечитать. Начальное сообщение. КД>>Короче парень, выпей йайду и убей себя об стену. КД>>Тебе никто не поможет. КД>>Но если религия не мешает, можно ... SM>Ни пойдёть.
Слушай я понял. Нам неправильно все объясняли. А мы не поняли где мы и с кем мы общались.
— Две транзакции в одном подключении нельзя, потому что с каждого подключения можно срубить бабло.
— Мы с тобой в магазине.
— Объясняли нам менеджеры по продажам. Ну ты же их знаешь. Они же никогда не скажут — возьмите один ящик с двумя тюнерами. Скажут — возьми два(три, четыре) ящика. Вы же запутаесь, а тут все конкретно — вот он ящик, вот конкретная передача.
Такие вот дела.
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
AC>А зачем? AC>Когда Oracle с IBM меряются, оно понятно, речь идёт о рынке и баблосах. AC>А для FreeWare это зачем? AC>Повторяю, неофициальные тесты опубликованы. Выводы сделаны.
дык, кто ж FB пустит на tpc ? он без лога транзакций банально не пройдет тест на crash/recovery ... да и без поддержки smp ему там делать нечего. класик у которого даже кеша общего нет это не архитектура, а недорзумение.
по Isolation levels — оракл на read commited обеспечивает консистентный набор (если не считать баг/фичу с минирестартами), IB и его клоны на IL read commited обеспечивают кашу в наборе, точно такую же какую обеспечивают блокировочники (имхо от того что каша соответствует стандарту мало чего меняется), поэтому считается что read commited оракла несколько выше.
к стате в новом OLTP тесте TPC-E mssql уже приходится в версионном режиме гонять.
ЗЫ. на счет параллельных транзакций, постоянно юзаются в оракле: основная транзакция прежде чем выполнить действия регистрирует попытку действия в автономной транзакции (в том же конекте естественно) передая туда имя пользователя, код транзакции и прочую инфу из основной, после чего основная транзакция нарывается на какое-то исключение и благополучно откатывается, при этом попытка фиксируется автономной транзакцией. все происходит на сервере, естественно не нарушая никаких IL ... но доказать очевидное некоторым личностям вам не удастся
IB>Сколько раз тебе надо сказать, что я ни слова не говорил про гарантии сервера? С сервером все в порядке. Вы нарушаете требования изолированности транзакции на клиенте.
Хм, а кто мне запретит абсолютно аналогичным способом "нарушать изолированность" использую 2 разных соединения?
Имея схему "один коннект — много транзакций" всегда можно применять ее как "один коннект — одна транзакция". Очевидно, что схему "один-коннект-много транзакций" применить как "один коннект — много транзакций" невозможно. Т.е. FB попросту более гибок. Когда подобная гибкость могла бы пригодиться... Навскидку, при ограничении числа одновременных коннектов(например купленных по лицензии) к БД.
Здравствуйте, Gt_, Вы писали:
Gt_>дык, кто ж FB пустит на tpc ? он без лога транзакций банально не пройдет тест на crash/recovery ... Gt_>да и без поддержки smp ему там делать нечего. класик у которого даже кеша общего нет это не архитектура, Gt_>а недорзумение.
Ну вот, уже и до создания одноразовых клонов дошли.
Верной дорогой идёте, товарищи!
Gt_>по Isolation levels — оракл на read commited обеспечивает консистентный набор (если не считать баг/фичу с минирестартами), Gt_>IB и его клоны на IL read commited обеспечивают кашу в наборе, точно такую же какую обеспечивают блокировочники Gt_>(имхо от того что каша соответствует стандарту мало чего меняется), поэтому считается что read commited оракла несколько выше.
Иван, так что там не так, с RC у FB, и почему у Oracle "выше"?
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>Слушай я понял. Нам неправильно все объясняли. А мы не поняли где мы и с кем мы общались. КД>- Две транзакции в одном подключении нельзя, потому что с каждого подключения можно срубить бабло. КД>- Мы с тобой в магазине. КД>- Объясняли нам менеджеры по продажам. Ну ты же их знаешь. Они же никогда не скажут — возьмите один ящик с двумя тюнерами. Скажут — возьми два(три, четыре) ящика. Вы же запутаесь, а тут все конкретно — вот он ящик, вот конкретная передача.
КД>Такие вот дела.
Нее. Всё гораздо хуже. Если представить менеджера по продажам как транзакцию, то в данной системе
мы смогли словить дедлок на единственной транзакции, которая сама себе наступила на хвост, а потом судорожными танцами вокруг да около, прихватывая всё что видит, попыталась из этого дедлока выскочить
Эх, жалко я теорию автоматов закинул... Там вроде дедлок можно было разрешить только внешним воздействием?
А мы видимо уже стали частью системы...
--
WBR и ничего личного
... << RSDN@Home 1.2.0 alpha rev. 743>>
Здравствуйте, Gt_, Вы писали:
AC>>Повторяю, неофициальные тесты опубликованы. Выводы сделаны.
Gt_>дык, кто ж FB пустит на tpc ? он без лога транзакций банально не пройдет тест на crash/recovery ...
опять цирк. как раз по crash/recovery IB/FB тест пройдет. Потому что не надо "накатывать" или "откатывать"
логи. почитайте наконец, что-нибудь о версионных движках.
Gt_>да и без поддержки smp ему там делать нечего. класик у которого даже кеша общего нет это не архитектура, а недорзумение.
оставим и это.
Gt_>по Isolation levels — оракл на read commited обеспечивает консистентный набор (если не считать баг/фичу с минирестартами), IB и его клоны на IL read commited обеспечивают кашу в наборе, точно такую же какую обеспечивают блокировочники (имхо от того что каша соответствует стандарту мало чего меняется), поэтому считается что read commited оракла несколько выше.
поясните пожалуйста, про "кашу в наборе". Вы не это имеете в виду? http://www.sql.ru/forum/actualthread.aspx?tid=173455&pg=2
Gt_>к стате в новом OLTP тесте TPC-E mssql уже приходится в версионном режиме гонять.
Gt_>ЗЫ. на счет параллельных транзакций, постоянно юзаются в оракле: основная транзакция прежде чем выполнить действия регистрирует попытку действия в автономной транзакции (в том же конекте естественно) передая туда имя пользователя, код транзакции и прочую инфу из основной, после чего основная транзакция нарывается на какое-то исключение и благополучно откатывается, при этом попытка фиксируется автономной транзакцией. все происходит на сервере, естественно не нарушая никаких IL ... но доказать очевидное некоторым личностям вам не удастся
ахинея какая-то. "и эти люди запрещают нам ковыряться в носу"... Более дебильной реализации я не встречал.
и ниже по ветке
R>Причем тут это сообщение. Там все тоже самое... омм мане падме хум... зачем параллельная транзакция, когда можно создать подключение? Ну вот, я говорю, есть у меня уже подключение, есть. Я могу в этом подключении создать новую транзакцию, и результат работы будет таким же. Ну вот блин зачем мне новое подключение создавать? Зачем? Можно на этот вопрос внятно ответить?
точно такой же вопрос в ответ — если мне надо стартануть еще одну транзакцию — зачем мне
еще одно подключение создавать? зачем???
Вы понимаете, что подключение, обобщая и детализируя — это создание сокета, поиск в dns,
авторизация... Зачем делать это еще раз если соединение с сервером УЖЕ есть?
и ниже по ветке
R>>Причем тут это сообщение. Там все тоже самое... омм мане падме хум... зачем параллельная транзакция, когда можно создать подключение? Ну вот, я говорю, есть у меня уже подключение, есть. Я могу в этом подключении создать новую транзакцию, и результат работы будет таким же. Ну вот блин зачем мне новое подключение создавать? Зачем? Можно на этот вопрос внятно ответить?
КДВ>точно такой же вопрос в ответ — если мне надо стартануть еще одну транзакцию — зачем мне КДВ>еще одно подключение создавать? зачем??? КДВ>Вы понимаете, что подключение, обобщая и детализируя — это создание сокета, поиск в dns, КДВ>авторизация... Зачем делать это еще раз если соединение с сервером УЖЕ есть?
Gt_>>дык, кто ж FB пустит на tpc ? он без лога транзакций банально не пройдет тест на crash/recovery ...
КДВ>опять цирк. как раз по crash/recovery IB/FB тест пройдет. Потому что не надо "накатывать" или "откатывать" КДВ>логи. почитайте наконец, что-нибудь о версионных движках.
поверьте о версионности я вполне просвещен, а вот вы немного не вьезжаете о чем речь. попробуйте выдохнуть и неуподоблятся Мерле несущему ахинею. что такое лог транзакций вы думаю можете почитать в доке к последнему IB, там наконец его реализовали. применительно к tpc речь идет о простеньком тесте, вот например, что должен был пройти оракл в последнем tpc-c тесте:
Loss of Data
To demonstrate recovery from a permanent failure of durable medium containing TPC-C tables, the following steps were
executed:
1. A backup of the database was made.
2. The total number of New Orders was determined by the sum of D_NEXT_O_ID
of all rows in the DISTRICT table giving the beginning count. Consistency
check 3 was verified before run.
3. The RTE was started with 40500 users
4. The test was allowed to run for a minimum of 5 minutes.
5. Removed a disk from an array containing database data.
6. Oracle10g recorded errors about corrupt data on the partition. The database and
the RTE were then shut down.
7. The removed disk was replaced from the spares and the logical drives on that
array were restored from backup.
8. The database was then started. The database was recovered using the recover
command from SQLPLUS. The database was opened and Oracle 10g performed
instance recovery.
9. Consistency conditions were executed and verified.
10. Step 2 was repeated and the difference between the first and second counts was
noted.
11. An RTE report was generated for the entire run time giving the number of NEWORDERS
successfully returned to the RTE.
12. The counts in step 10 and 11 were compared and the results verified that all
committed transactions had been successfully recovered.
13. Samples were taken from the RTE files and used to query the database to
demonstrate successful transactions had corresponding rows in the ORDER
table.
да, это. оракл обеспечивает консистентный набор стейтмента на IL RC, т.е. в набор попадут только те записи какие были закомичены на момент старта стейтмента. у FB же RC гораздо слабее:
Теперь представим себе, что select читает данные, и уже начинает читать данные, которые обновлены другой транзакцией. пока вторая транзакция не committed, измененные версии записей игнорируются. Теперь вдруг обновляющая транзакция сделала commit. Читающая транзакция попадает на "вторую половину" обновлений, сделанных этой транзакцией. Но они уже committed, то есть их читать можно. http://www.sql.ru/forum/actualthread.aspx?bid=2&tid=173455&pg=2#1450276
КДВ>ахинея какая-то. "и эти люди запрещают нам ковыряться в носу"... Более дебильной реализации я не встречал.
Здравствуйте, SmlMouse, Вы писали:
SM>Эх, жалко я теорию автоматов закинул... Там вроде дедлок можно было разрешить только внешним воздействием? SM>А мы видимо уже стали частью системы...
Вы уже давно стали частью файрберда, вы лишь его послушные роботы. Вас надо уничтожить.
Здравствуйте, Коваленко Дмитрий, Вы писали:
КД>- Две транзакции в одном подключении нельзя, потому что с каждого подключения можно срубить бабло.
Если речь о лицензировании SQL Server, то одна лицензия на на пользователя подразумевает неограниченное кол-во подключений этого пользователя. Так шта опять мимо.
