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

Так что прошу просто напишите как это делать:

1. открываю транзакцию (умею)
2. создать временную таблицы с локальной видимостью
3. заполняю данными построчно, после копирую через insert into mytbl select * from temptbl;
4. удалить временную таблицу
5. закрываю транзакцию.

собственно основное это пункты 2 и 4, ну и сам подход, если в нем есть какие-либо корявости, прошу поправить.

Спасибо за содействие.

M>Подозреваю что все элементарно, но уже нет никакого желания наступать на грабли, лопатить тонны доки и прочее.
сколько еще открытий чудных
In general, you use table variables whenever possible except when there is a significant volume of data and there is repeated use of the table.
http://support.microsoft.com/default.aspx?scid=kb;en-us;305977

M>собственно основное это пункты 2 и 4, ну и сам подход, если в нем есть какие-либо корявости, прошу поправить.
тут подход в принципе ОК, только нужно помнить что временные таблицы могут вызывать перекомпиляции процедур
http://support.microsoft.com/default.aspx?scid=kb;en-us;243586
и при создании вызывают блокировки в сис-таблицах, т.е. делать select * into #table from ... нельзя.
http://www.sql-server-performance.com/temp_tables.asp

короче, если есть возможность лучше времменые таблицы не юзать.

Здравствуйте, Аноним, Вы писали:

А>короче, если есть возможность лучше времменые таблицы не юзать.
Ну все правильно, только вывод не верный. Вот так и рождаются дурацкие фобии. Временные таблицы, равно как и переменные, лучше использовать, но только там где это надо. Очень, бывает, помогают.

Здравствуйте, Аноним, Вы писали:

M>>Подозреваю что все элементарно, но уже нет никакого желания наступать на грабли, лопатить тонны доки и прочее.
А>сколько еще открытий чудных
А>In general, you use table variables whenever possible except when there is a significant volume of data and there is repeated use of the table.
А>http://support.microsoft.com/default.aspx?scid=kb;en-us;305977

M>>собственно основное это пункты 2 и 4, ну и сам подход, если в нем есть какие-либо корявости, прошу поправить.
А>тут подход в принципе ОК, только нужно помнить что временные таблицы могут вызывать перекомпиляции процедур
А>http://support.microsoft.com/default.aspx?scid=kb;en-us;243586
А>и при создании вызывают блокировки в сис-таблицах, т.е. делать select * into #table from ... нельзя.
А>http://www.sql-server-performance.com/temp_tables.asp

А>короче, если есть возможность лучше времменые таблицы не юзать.

Я уже запутался, то юзать, то не юзать....
ХП не использую в принципе, незачем они там. задумка использовать временную таблицу только для того, чтобы сократить время блокировки: просто выполнение отдельных инсертов время занимает, да и иногда через можем это делать приходится ( ).

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

MSSQL

Здравствуйте, Mikst, Вы писали:

M>Все так что лучше, создавать временную таблицу, или создать постоянную, добавить в нее ключ транзакции и делать через нее и не париться?
Временную, только создавать явно (CREATE TABLE #tmp...)

M>Или всеже с блокировками тут тоже гемор возникнет?
Смотря как делать...

M> MSSQL
Спокуха на лице.

M>Все так что лучше, создавать временную таблицу, или создать постоянную, добавить в нее ключ транзакции и делать через нее и не париться? Или всеже с блокировками тут тоже гемор возникнет?

ну если сначала создавать tmp-табличку а потом в нее insert into select делать то блокировок не должно быть, тогда просто tempdb может надо будет потюнить т.к. он может стать узским местом.

ЗЫ. может подождешь sql2005 он вроде должен выйти через пару недель, конечно до оракла не дотягивает но хотя бы версионный механизм там уже есть, можно скачать preview и не не воевать с блокировками (все равно проиграете )

Здравствуйте, Аноним, Вы писали:

M>>Все так что лучше, создавать временную таблицу, или создать постоянную, добавить в нее ключ транзакции и делать через нее и не париться? Или всеже с блокировками тут тоже гемор возникнет?

А>ну если сначала создавать tmp-табличку а потом в нее insert into select делать то блокировок не должно быть, тогда просто tempdb может надо будет потюнить т.к. он может стать узским местом.

А>ЗЫ. может подождешь sql2005 он вроде должен выйти через пару недель, конечно до оракла не дотягивает но хотя бы версионный механизм там уже есть, можно скачать preview и не не воевать с блокировками (все равно проиграете )

Пардон. истерика. Нет, сервер никто менять не будет, он стоит и стоит, ибо нефиг. Работает- руками не трожь.

Короче делаю через обычную табличку и все. инече точно придется завтра к психотерапефту идти с признаками маниакальной депрессии на почме продуктов МС

M>Короче делаю через обычную табличку и все. инече точно придется завтра к психотерапефту идти с признаками маниакальной депрессии на почме продуктов МС
боюсь врач вас уже не приймет, испорченость версионностью в наше время не лечится это как девственость, если ее теряешь (ораклом) то востановить можно только внешне ...

Gt_

Здравствуйте, Аноним, Вы писали:


M>>Короче делаю через обычную табличку и все. инече точно придется завтра к психотерапефту идти с признаками маниакальной депрессии на почме продуктов МС
А>боюсь врач вас уже не приймет, испорченость версионностью в наше время не лечится это как девственость, если ее теряешь (ораклом) то востановить можно только внешне ...

А>Gt_

Спасибо, теперь я спокоен.

Резюмируя всё выше/ниже сказанное, делаю для себя вывод: оракл правильно поддерживает только один уровень изоляции: REPEATABLE READ+ (т.е. гарантирует отсутствие фантомов). И этого уровня хватает всегда и везде (лично мне), на нем мне гарантирует 100% правильноть результата отчетов, при отсутствии блокировок. А делать условия по таблицам X+Y<5 и вообще условие по строкам данных (в частности DELETE..WHERE X=2, блокирует INSERT VALUES(2) ) я считаю ошибочным подходим при проектировании СУБД. Особенно реляционной, в которой строки между собой не взаимодействуют. Опять таки не спорю что такие задачи есть, но они встречаются видимо крайне редко (мне не встречались никогда). Моя самая первая программа на оракле (и вообще с использованием БД), написанная 7 лет назад, прекрасно работает до сих пор, не тормозит со всеми вытекающими, а работает с не очень много человек. А вот на МСС пока никак, но это как с девственностью — само не заживает.

Всем спасибо за терпение.

Пойду читать "Microsoft SQL Server 2000 System Administration", посмешнее журнала крокодил будет

Здравствуйте, Mikst, Вы писали:

M>Спасибо, теперь я спокоен.
Это главное...

M>Резюмируя всё выше/ниже сказанное, делаю для себя вывод: оракл правильно поддерживает только один уровень изоляции: REPEATABLE READ+ (т.е. гарантирует отсутствие фантомов).
И это говорит знаток Оракла? Теперь понятно как Вы им занимались...
Во-первых Oracle поддерживает как минимум два уровня изоляции. Во-вторых 100% защиты от фантомов ни один из уровней изоляции Оракла не гарантирует, более того, в некоторых случаях он даже не гарантирует обещаного в документации Statement Level Consistency на Read Committed уровне из-за одной, не очень удачной оптимизации.

M>И этого уровня хватает всегда и везде (лично мне), на нем мне гарантирует 100% правильноть результата отчетов, при отсутствии блокировок.
Ну, судя по тому, что за годы работы с ораклом Вы не узнали о наличии в нем нескольких уровней изоляции, у Вас действительно были очень простые отчеты...
Могу только посоветовать продолжать пользоваться орактом, раз Вас все в нем устраивает...

M>А делать условия по таблицам X+Y<5 и вообще условие по строкам данных (в частности DELETE..WHERE X=2, блокирует INSERT VALUES(2) ) я считаю ошибочным подходим при проектировании СУБД. Особенно реляционной, в которой строки между собой не взаимодействуют.
Жаль, что Вы так и не поняли, что это был всего лишь пример, наглядно демонстрирующий отсутствие защиты от фантомов, очевидно архитектурные вопросы я в этом примере не рассматривал.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Mikst, Вы писали:

M>>Спасибо, теперь я спокоен.
M>Это главное...

M>>Резюмируя всё выше/ниже сказанное, делаю для себя вывод: оракл правильно поддерживает только один уровень изоляции: REPEATABLE READ+ (т.е. гарантирует отсутствие фантомов).
M>И это говорит знаток Оракла? Теперь понятно как Вы им занимались...
M>Во-первых Oracle поддерживает как минимум два уровня изоляции. Во-вторых 100% защиты от фантомов ни один из уровней изоляции Оракла не гарантирует, более того, в некоторых случаях он даже не гарантирует обещаного в документации Statement Level Consistency на Read Committed уровне из-за одной, не очень удачной оптимизации.

Возможно, но пока не встречал. Везение??

M>>И этого уровня хватает всегда и везде (лично мне), на нем мне гарантирует 100% правильноть результата отчетов, при отсутствии блокировок.
M>Ну, судя по тому, что за годы работы с ораклом Вы не узнали о наличии в нем нескольких уровней изоляции, у Вас действительно были очень простые отчеты...
M>Могу только посоветовать продолжать пользоваться орактом, раз Вас все в нем устраивает...

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

M>>А делать условия по таблицам X+Y<5 и вообще условие по строкам данных (в частности DELETE..WHERE X=2, блокирует INSERT VALUES(2) ) я считаю ошибочным подходим при проектировании СУБД. Особенно реляционной, в которой строки между собой не взаимодействуют.
M>Жаль, что Вы так и не поняли, что это был всего лишь пример, наглядно демонстрирующий отсутствие защиты от фантомов, очевидно архитектурные вопросы я в этом примере не рассматривал.

Фантомов я так и не увидел. Может этот пример и показывает отличие правильности работы уровня SERIALIZABLE описанного в ANSI, но лично для меня он работает правильно. Думаю не стоит продолжать эту тему.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Mikst, Вы писали:

M>>Спасибо, теперь я спокоен.
M>Это главное...

M>>Резюмируя всё выше/ниже сказанное, делаю для себя вывод: оракл правильно поддерживает только один уровень изоляции: REPEATABLE READ+ (т.е. гарантирует отсутствие фантомов).

Ну вообще говоря, погорячился конечно READ COMMITTED от SERIALIZABLE естественно отличается.
Я хотел немного другое сказать, что вместо чистого SERIALIZABLE и REPEATABLE READ есть один (хоть и называется SERIALIZABLE).

M>И это говорит знаток Оракла? Теперь понятно как Вы им занимались...
M>Во-первых Oracle поддерживает как минимум два уровня изоляции. Во-вторых 100% защиты от фантомов ни один из уровней изоляции Оракла не гарантирует, более того, в некоторых случаях он даже не гарантирует обещаного в документации Statement Level Consistency на Read Committed уровне из-за одной, не очень удачной оптимизации.

При оптимизации все может быть, и компиляторы С++ частенько мне финты выкидывали добавляя в заголовок невиртуального класса this. Что с того... баг — не более того.

А вот фантомы на SERIALIZABLE — хочу видеть пример.

Оракл — версионик, а стандарт ansi sql писали под блокировочник, поэтому ораклу пришлось обзывать свои IL словами из стандарта. Оракловый serializible соответствует ansi sql92 serializible, т.к. оно не требовало упорядовачиния, а только требовало отсутствие фантомов. требование упорядочивания появилось позже, но оракл традиционно кладет на глупые стандарты ... (о глупостях в стандарте можно почитать тут http://www.osp.ru/dbms/1996/02/45.htm)
на счет RC, у оракла это нормальный IL который используется подавляющим большинством, у mssql это нечто не понятное которое местами может выдать потрясающий результат и поэтому не так уж много задач которые на нем можно решать (на нем нельзя получить согласованый отчет + он может ненароком прочитать заблокированые данные)

Gt_

Здравствуйте, Аноним, Вы писали:

А>Оракл — версионик, а стандарт ansi sql писали под блокировочник, поэтому ораклу пришлось обзывать свои IL словами из стандарта. Оракловый serializible соответствует ansi sql92 serializible, т.к. оно не требовало упорядовачиния, а только требовало отсутствие фантомов. требование упорядочивания появилось позже, но оракл традиционно кладет на глупые стандарты ... (о глупостях в стандарте можно почитать тут http://www.osp.ru/dbms/1996/02/45.htm)
А>на счет RC, у оракла это нормальный IL который используется подавляющим большинством, у mssql это нечто не понятное которое местами может выдать потрясающий результат и поэтому не так уж много задач которые на нем можно решать (на нем нельзя получить согласованый отчет + он может ненароком прочитать заблокированые данные)

А>Gt_

Собственно к чему я и "брызгаю слюной на МС".

Да я привык на оракле спокойно все себе делать на RC IL и не париться ничем! все жужжит по определению, никто никому никак не мешает, чтобы жужжало получше приходит АБД, и делает свою работу по увеличению ресурсов, где надо.

Сейчас я столкнулся в МС с _элементарной вещью_ !! вставка в базу большого кол-ва данных, из которой постоянно читают. Все, я (не спорю что по глупости и незнанию) но я в тупике! Все. АУТ. Тушите свет, кидай гранату.

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

Внимание вопрос!
Что я должен сделать, чтобы избежать блокирования сессий. одновременно могут читать 10-15 клиентов. Раз в минуту данные меняют, время изменения 10-15 секунд. Читатели стоят. Что делать??? Ваши предложения на будущее "правильной архитектуры" и для моего случая есть условие: Код читателей уже не изменить.

Это элементарная вещь, но не решается уже неделю... оттого и унылость в глазах.

Здравствуйте, Mikst, Вы писали:

M>Собственно к чему я и "брызгаю слюной на МС".

M>Внимание вопрос!
M> Что я должен сделать, чтобы избежать блокирования сессий. одновременно могут читать 10-15 клиентов. Раз в минуту данные меняют, время изменения 10-15 секунд. Читатели стоят. Что делать??? Ваши предложения на будущее "правильной архитектуры" и для моего случая есть условие: Код читателей уже не изменить.

У меня была интересная ситуация недавно... У базы (Oracle) в каждый момент времени порядка 200-от активных пользователей. Надо было из таблицы журнала пользовательских действий, содержащей ~19 млн. записей удалить ~2-3 млн. "лишних", причём очень хитрым образом, не укладывающимся в рамки банального delete ... where .... Удаление запустил на боевой базе. Процессы пользовтелей не останавливались, не блокировались (а в журнале как минимум несколько записей с секунду добавляется). Через пару минут удаление зваршилось. commit. Всё живы, ни один суслик не пострадал. Никто из юзеров ничего и не заметил. Только у DBA полявилось 3GB archive logs.

Здравствуйте, IID, Вы писали:

IID>Здравствуйте, Mikst, Вы писали:

M>>Собственно к чему я и "брызгаю слюной на МС".

M>>Внимание вопрос!
M>> Что я должен сделать, чтобы избежать блокирования сессий. одновременно могут читать 10-15 клиентов. Раз в минуту данные меняют, время изменения 10-15 секунд. Читатели стоят. Что делать??? Ваши предложения на будущее "правильной архитектуры" и для моего случая есть условие: Код читателей уже не изменить.

IID>У меня была интересная ситуация недавно... У базы (Oracle) в каждый момент времени порядка 200-от активных пользователей. Надо было из таблицы журнала пользовательских действий, содержащей ~19 млн. записей удалить ~2-3 млн. "лишних", причём очень хитрым образом, не укладывающимся в рамки банального delete ... where .... Удаление запустил на боевой базе. Процессы пользовтелей не останавливались, не блокировались (а в журнале как минимум несколько записей с секунду добавляется). Через пару минут удаление зваршилось. commit. Всё живы, ни один суслик не пострадал. Никто из юзеров ничего и не заметил. Только у DBA полявилось 3GB archive logs.

Ну так ведь это замечательно Что все живы и здоровы. А архивлогов по 20-30Г в сутки это самое то.

Здравствуйте, Mikst, Вы писали:

M>А вот фантомы на SERIALIZABLE — хочу видеть пример.
Я уже дал два. Это все частные случаи фантомов. Почитайте все-таки ссылочки на статьи и книги что я давал...

Здравствуйте, <Аноним>, Вы писали:

А>Оракл — версионик, а стандарт ansi sql писали под блокировочник, поэтому ораклу пришлось обзывать свои IL словами из стандарта.
Странный вывод, почему пришлось? Никто их не заставлял обзывать свои уровни изоляции словами из стандарта это маркетоиды подсуетились и всем большую свинью подложили.

А>Оракловый serializible соответствует ansi sql92 serializible, т.к. оно не требовало упорядовачиния, а только требовало отсутствие фантомов.
ANSI 92 требовал упорядочивания, но была дополнительная формулировка, которая оставляла небольшую лазейку и заключалась она не в требовании отсутствия фантомов, в этом случае Оракл бы не пролезал, а лишь в требовании отсутствия фантомных чтений.

А>требование упорядочивания появилось позже,
Оно было всегда, просто в ANSI SQL 99 оно стало единственным критерием сериализуемости, что вообщем верно.

А> но оракл традиционно кладет на глупые стандарты ...
Оракл пусть кладет на что угодно (только тогда свои уровни изоляции не надо называть как в стандарте, раз уж кладет), но конкретно в этом случае стандарт можно только похвалить, так как двусмысленность была устранена, разночтения невозможны и стандарт приведен в полное соответствие с формальной теорией, реальной практикой и здравым смыслом.

А>(о глупостях в стандарте можно почитать тут http://www.osp.ru/dbms/1996/02/45.htm)
Это очень корявый и не точный перевод, в следствии которого часть смысла утеряна и, что хуже, переврана, ссылку на оригинал я уже давал.

А>на счет RC, у оракла это нормальный IL который используется подавляющим большинством,
Подавляющим большинством чего?

А> у mssql это нечто не понятное которое местами может выдать потрясающий результат и поэтому не так уж много задач которые на нем можно решать
Во-первых это очень понятное и четко сформулированное множеством уважаемых людей, начиная от Дейта и заканчивая Греем, и если для Вас это не очевидно, то это не повод этим бравировать. Во-вторых данная реализация этого уровня изоляции так же удовлетворяет подавляющему большинству задач.

А>(на нем нельзя получить согласованый отчет + он может ненароком прочитать заблокированые данные)
Ага, знатоки MSSQL-я сейчас нам всю правду поведают... Не травите неподтвержденных баек, будет меньше поводов глупо выглядить.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Mikst, Вы писали:

M>>А вот фантомы на SERIALIZABLE — хочу видеть пример.
M>Я уже дал два. Это все частные случаи фантомов. Почитайте все-таки ссылочки на статьи и книги что я давал...

Да какие эе это фантомы, появление двух записей ПОСЛЕ транзакции, и невыполнение условия по строкам таблицы, опять таки ПОСЛЕ транзакции — это не фантомы. это даже соответствует утверждению что "Побочные эффекты (изменения) от других транзакций для такой транзакции невидимы, независимо от того, как долго она выполняется." а парралельно может происходить все что угодно.

Блин, обычный select count(*) from table в MS просто намертво блокирует таблицу... ну и к чему это надо?

Если хотите чтобы при IL SER. все выполнялось правильно, установите Max Session=1 и живите спокойно, только тогда можно и ручкой с блокнотом обойтись.

А вот пример чтобы именно _внтури_одной_транзакции_ оракл при SERIALIZABLE дал разный результат на один запрос, я пока не видел. Аномалии вставок, изменений и потерянных данных , это все другой разговор и другая тема. Относящаяся скорее к правильности кодирования и архитектуры, одинаковая для всех БД без исключения.

Здравствуйте, Mikst, Вы писали:

M>Да какие эе это фантомы,
Самые настоящие. Покурите все-таки теорию...

M>появление двух записей ПОСЛЕ транзакции,
Этих двух записей после быть не должно. Они появляются только если одна транзакция вклинилась между операторами другой транзакции, а такого быть не должно.

M> и невыполнение условия по строкам таблицы, опять таки ПОСЛЕ транзакции — это не фантомы.
Это самые настоящие фантомы, а точнее их разновидность под названием Write Skew (косая запись).
Формальное оперделение гласит: "операторы внутри транзакций могут пересекаться как угодно, лишь бы конечный результат выполнения этих транзакций был таким, как буд-то бы эти транзакции выполнялись одна за другой в любом произвольном порядке".
Ключевое слово "конечный результат". Никого не интересует что там было посередине, все разборки устраиваются в конце, после фиксации всех транзакций и уже там смотрится что получилось, потому как другие транзакции будут иметь дело с этим результатом. А у оракла в некоторых случаях получается полная фигня.

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

M> Аномалии вставок, изменений и потерянных данных , это все другой разговор и другая тема.
Это именно тот разговор и именно та тема.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Mikst, Вы писали:

M>>Да какие эе это фантомы,
M>Самые настоящие. Покурите все-таки теорию...

M>>появление двух записей ПОСЛЕ транзакции,
M>Этих двух записей после быть не должно. Они появляются только если одна транзакция вклинилась между операторами другой транзакции, а такого быть не должно.

M>> и невыполнение условия по строкам таблицы, опять таки ПОСЛЕ транзакции — это не фантомы.
M>Это самые настоящие фантомы, а точнее их разновидность под названием Write Skew (косая запись).
M>Формальное оперделение гласит: "операторы внутри транзакций могут пересекаться как угодно, лишь бы конечный результат выполнения этих транзакций был таким, как буд-то бы эти транзакции выполнялись одна за другой в любом произвольном порядке".
M>Ключевое слово "конечный результат". Никого не интересует что там было посередине, все разборки устраиваются в конце, после фиксации всех транзакций и уже там смотрится что получилось, потому как другие транзакции будут иметь дело с этим результатом. А у оракла в некоторых случаях получается полная фигня.

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

M>> Аномалии вставок, изменений и потерянных данных , это все другой разговор и другая тема.
M>Это именно тот разговор и именно та тема.

Смотря что понимать под "результат выполнения этих транзакций". Можно рассматривать результаты как значения отдельных строк, а можно как состояние всей таблицы целиком. Так вот на уровне строк никаких "фатальных" ошибок не происходит. На уровне таблицы — да, возможно, не спорю.
Если результаты примера с DELETE и INSERT в две строки считать фантомом (1), то опять таки, это не фатальный фантом. Просто для работы с ораклом такой подход не верен (накладывать условия на группы строк, ибо нефиг). А вот реальные фантомы (2) в блокировочниках на дефолтовом RC — это действительно уродство (зато удовлетворяет ANSI ).
Обясню почему так думаю:
1. — такого рода фантомы можно увидеть, только после завершения транзакции, т.е. в _следующей_ транзакции.
2. — такого рода фантомы возникают _внутри_одной_ транзакции (см. пример про sum(v) и результат *004), что недопустимо для реально работающей системы.

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

Здравствуйте, Mikst, Вы писали:

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

M> Можно рассматривать результаты как значения отдельных строк, а можно как состояние всей таблицы целиком.
Бегом теорию читать. Как результат — состояние всей базы данных.

M> Так вот на уровне строк никаких "фатальных" ошибок не происходит.
"уровень строк" никого не волнует, хотя и там в оракле есть косяки, но поскольку такие тривиальные примеры Вам не помогли, то от разбора более сложных случаев я, пожалуй, удержусь...

Здравствуйте, Merle, Вы писали:

M>> Так вот на уровне строк никаких "фатальных" ошибок не происходит.
M>"уровень строк" никого не волнует, хотя и там в оракле есть косяки, но поскольку такие тривиальные примеры Вам не помогли, то от разбора более сложных случаев я, пожалуй, удержусь...

Ну из его слов

вот на уровне строк никаких "фатальных" ошибок не происходит. На уровне таблицы — да, возможно, не спорю.

я сделал вывод, что ему на фантомы вообще наплевать (задач не было), а вы тут о теории, косых и т.д. и т.п. (с чем не сталкивался — того не существует )

Здравствуйте, KGP, Вы писали:

KGP>Здравствуйте, Merle, Вы писали:

M>>> Так вот на уровне строк никаких "фатальных" ошибок не происходит.
M>>"уровень строк" никого не волнует, хотя и там в оракле есть косяки, но поскольку такие тривиальные примеры Вам не помогли, то от разбора более сложных случаев я, пожалуй, удержусь...

KGP>Ну из его слов

KGP>

KGP>вот на уровне строк никаких "фатальных" ошибок не происходит. На уровне таблицы — да, возможно, не спорю.

KGP>я сделал вывод, что ему на фантомы вообще наплевать (задач не было), а вы тут о теории, косых и т.д. и т.п. (с чем не сталкивался — того не существует )

Обзовем их "фантомы after commit" Реализуя программу и делая в ней всякого рода запросы, я не задумываюсь о том сколько строк с таблице и каковы связи между ними. Я привык планировать базу так, чтобы все строки в таблице были независимы между собой. Тогда эффекта "фантомов после комита" просто не возникает. А вот получить в агрегатной функции никогда не существовавшее в базе число, это уже извините меня, даже не фантом... это барабашка Ну а с проблемой "косой записи" тоже к счастью не столкнулся, и если нужно ее избежать, никто не мешает поставить блокировку.

Здравствуйте, Mikst, Вы писали:

M>Ну вообще говоря, погорячился конечно READ COMMITTED от SERIALIZABLE естественно отличается.
M>Я хотел немного другое сказать, что вместо чистого SERIALIZABLE и REPEATABLE READ есть один (хоть и называется SERIALIZABLE).
Для достижения serializable можно предварительно блокировать изменяемые данные.

С уважением, Gleb.

Здравствуйте, <Аноним>, Вы писали:

А>Оракл — версионик, а стандарт ansi sql писали под блокировочник, поэтому ораклу пришлось обзывать свои IL словами из стандарта. Оракловый serializible соответствует ansi sql92 serializible, т.к. оно не требовало упорядовачиния, а только требовало отсутствие фантомов. требование упорядочивания появилось позже, но оракл традиционно кладет на глупые стандарты ... (о глупостях в стандарте можно почитать тут http://www.osp.ru/dbms/1996/02/45.htm)
А>на счет RC, у оракла это нормальный IL который используется подавляющим большинством, у mssql это нечто не понятное которое местами может выдать потрясающий результат и поэтому не так уж много задач которые на нем можно решать (на нем нельзя получить согласованый отчет + он может ненароком прочитать заблокированые данные)


Уважаемый, открою вам по секрету одну маленькую тайну. Стандарт SQL92 (обсуждаемый в статье) писали, прежде всего, ораклоиды. Можете прочитать даже у Тома Кайта(не помню точно, но вроде бы он входил в комитет). Неплохо было-бы прочитать кто написал эту статью, и где они работают. Когда они начали гнать почему в стандарт не внесли блокировки, я плакал от умиления.

Советую вам взять любую вменяюмую книгу по теории Баз Данных. Прочитать. И узнать почему MS SQL работает именно так и никак иначе. Потому как он работает по классической схеме описанной в любой книге по теории.

С уважаением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ> Стандарт SQL92 (обсуждаемый в статье) писали, прежде всего, ораклоиды.
Его писали все подряд, начиная IBM-ерами и заканчивая MS.

GZ>Неплохо было-бы прочитать кто написал эту статью, и где они работают. Когда они начали гнать почему в стандарт не внесли блокировки, я плакал от умиления.
Статью написаль довольно известные и уважаемые в мире БД люди. Часть из них работает в MS... И стандарт версии 92го года действительно довольно бестолково написан в разделе уровней изоляции с сильным креном в сторону блокировочников, за что подвергался неоднократной критике.
Собственно упомянутая статья является выжимкой всей этой критики и считается классическим обзором уровней изоляции...
Только одно но... ее нельзя читать на русском в этом переводе, часть смысла утеряна и, что существенно хуже, искажена.
Вот оригинал: A Critique of ANSI SQL Isolation Levels

Здравствуйте, Mikst, Вы писали:

M>Обзовем их "фантомы after commit"
Ага, сейчас мы новую теорию бд слабаем...
Все, последняя попытка, на пальцах... Есть такое понятие как транзакция — это набор операций переводящий базу из одного согласованного состояния в другое, подчеркну, согласованное состояние. При этом транзакция обладает 4-мя свойствами ACID, на данный момент нас интересует I — изолированность. Для чего она нужна? Дело в том, что даже безупречно написанная транзакция, если ее запустить одновременно с другими, столь же безупречно написанными транзакциями, может выдать совершенно неожиданный результат нарушающий всякую согласованность. Поэтому условились, пусть транзакция выполняется так, как буд-то бы других активных транзакций нет.
Отлично, условится условились, а как определить, что именно так они и выполнялись? И тут на помощь приходит формальный критерий упорядоченности, который гласит, что транзакции не мешали друг-другу только в том случае, когда конечный результат параллельного выполнения нескольких транзакций получился такой, как буд-то бы они выполнялись одна за другой в любом произвольном порядке.
Напомню еще раз, если Вы потеряли нить моих рассуждений, транзакция это перевод всей базы из одного согласованного состояния в другое и именно согласованность всей базы нас интересует, ни записей, ни таблиц — всей базы в целом. И именно согласованность всей базы гарантирует следование эвышеупомянутому критерию, о чем есть соответствующая теоремма со строгим математическим доказательством.
И как легко заметить, приведенные примеры наглядно демонстрируют, что даже на самом высоком уровне изоляции оракл не удовлетворяет в полной мере этому критерию, что может привести к несогласованности в базе, не смотря на то, что сами по себе, выполняясь в отсутствии других транзакций, транзакции из примера совершенно корректны.

M>Реализуя программу и делая в ней всякого рода запросы, я не задумываюсь о том сколько строк с таблице и каковы связи между ними.
Не, ну прелесть.. Все прогрессивное человечество нещадя усилий изобретает целый класс функций для работы с зависимостями между записями, а мы по простому, без затей, мы проектируем правильно!
Реализуйте ка мне табличку товаров в заказе, где для определенного вида клентов общая сумма заказа не может превышать определенную величину.
А потом еще раз расскажите про отсутствие зависимости между записями в одной таблице (вообще подобную зависимость отражает любой агрегат, и только агрегатами это дело не ограничивается), ну это к слову.

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

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Mikst, Вы писали:

M>>Обзовем их "фантомы after commit"
M>Ага, сейчас мы новую теорию бд слабаем...

А в этом что-то есть

M>Все, последняя попытка, на пальцах... Есть такое понятие как транзакция — это набор операций переводящий базу из одного согласованного состояния в другое, подчеркну, согласованное состояние. При этом транзакция обладает 4-мя свойствами ACID, на данный момент нас интересует I — изолированность. Для чего она нужна? Дело в том, что даже безупречно написанная транзакция, если ее запустить одновременно с другими, столь же безупречно написанными транзакциями, может выдать совершенно неожиданный результат нарушающий всякую согласованность. Поэтому условились, пусть транзакция выполняется так, как буд-то бы других активных транзакций нет.
M>Отлично, условится условились, а как определить, что именно так они и выполнялись? И тут на помощь приходит формальный критерий упорядоченности, который гласит, что транзакции не мешали друг-другу только в том случае, когда конечный результат параллельного выполнения нескольких транзакций получился такой, как буд-то бы они выполнялись одна за другой в любом произвольном порядке.
M>Напомню еще раз, если Вы потеряли нить моих рассуждений, транзакция это перевод всей базы из одного согласованного состояния в другое и именно согласованность всей базы нас интересует, ни записей, ни таблиц — всей базы в целом. И именно согласованность всей базы гарантирует следование эвышеупомянутому критерию, о чем есть соответствующая теоремма со строгим математическим доказательством.
M>И как легко заметить, приведенные примеры наглядно демонстрируют, что даже на самом высоком уровне изоляции оракл не удовлетворяет в полной мере этому критерию, что может привести к несогласованности в базе, не смотря на то, что сами по себе, выполняясь в отсутствии других транзакций, транзакции из примера совершенно корректны.

Ok, будем считать что убедили. Но всеже в оракле на мой взгляд требуется гораздо меньше "приседаний" чтобы заставить определенные транзакции выполнятся последовательно, собственно добавлением одной единственной строки. Но это мелочи.

M>>Реализуя программу и делая в ней всякого рода запросы, я не задумываюсь о том сколько строк с таблице и каковы связи между ними.
M>Не, ну прелесть.. Все прогрессивное человечество нещадя усилий изобретает целый класс функций для работы с зависимостями между записями, а мы по простому, без затей, мы проектируем правильно!

Видимо я еще не дорос до отметки, когда приходиться придумывать себе проблемы прогрессивного человечества

M>Реализуйте ка мне табличку товаров в заказе, где для определенного вида клентов общая сумма заказа не может превышать определенную величину.
M>А потом еще раз расскажите про отсутствие зависимости между записями в одной таблице (вообще подобную зависимость отражает любой агрегат, и только агрегатами это дело не ограничивается), ну это к слову.

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

M>Потом сделайте усилие, задумайтесь над тем, что это только примеры и что одна таблица там фигурирует только для наглядности иллюстрации, впрочем об этом я уже говорил.

Ну и опять таки, все это _теория_, точно также спорят теоретики физики с физиками практиками... вечный спор. В теории оно все здорово и замечательно, сферический конь в вакууме, только нужен ли он нам?

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

Здравствуйте, Mikst, Вы писали:

M>Да легко, агрегат хранится в соседней табличке, при апдейте основной таблицы, его просто блокируют и пересчитывают, из триггера, так что все автоматом. и все было шито крыто, это конечно же "приседание", но удобное, простое и без излишних блокировок
Ура. Вы только что придумали способ каким работают с подобного рода задачами блокировочники, только они делают это эффективнее, поскольку у Оракла нет Row Level Read Lock.

M> Опять таки, мой вопрос в силе: в приложении одна таблица, в нее пишут, из нее читают — хочу всегда читать правильные данные, хочу без лишних проблем писать данные, хочу чтобы все было быстро.
Очень просто. Вы же сами только что привели пример с агрегатами, здесь подход точно такой же...
Данные пишутся в основную табличку, а читаются из агрегатов, все получается очень шустро и комфортно.

Здравствуйте, Mikst, Вы писали:

Видишь ли, в чем дело. MS SQL разрабатывался с оглядкой прежде всего на OLTP.
А в этой схеме сам вопрос "как мне прочитать согласованное состояние всех нафиг данных зараз" неуместен. Потому, что он противоречит цели "сделать обработку транзакций максимально эффективной".
И, что характерно, парням все удалось. Долгое время именно сиквел рулил на tpc.org. Ораклу удалось его подвинуть только после выхода десятки, и то благодаря кластерному использованию совершенно нечеловеческих ресурсов. Что характерно, ненадолго — сейчас олимп занят DB2, который представляет собой совершенно чистый блокировочник.

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

С точки зрения сиквела, если программисту хочется оперировать над снапшотом, то он должен этот снапшот вручную получить. Ну не предназначен OLTP storage для выполнения тэйбл сканов.
Есть эн способов это сделать — временные таблицы, индексированные вью, репликация в отдельную базу, наполнение OLAP хранилища.
И, по большому счету, эти способы, хоть и "приседательные", более правильны. Если сначала твой отчет, построенный прямо поверх исходных данных, будет как-то ездить, то при росте объема решение с ежесуточным сбросом изменений в OLAP порвет его как тузик грелку. Потому, что ни один сторидж не обеспечит необходимой скорости подсчета агрегатов.

К сожалению, все эти чудеса сдерживаются трудностью необходимых приседаний. Я думаю, именно это стало причиной введения таки автоматической поддержки снапшотов в MS SQL 2005.

Лично мне нравится MS SQL. Ну, неформально так. Потому, что он дружественный к пользователю — поднять Оракл это не фунт изюму. И потому, что он требовательный к архитектору. Противоестественно — но так.
Там, где ты мог в оракле, грубо говоря, надеяться на "авось" — пусть сервер сам там разруливает где что, сегмент отката там наращивает, пусть и ценой просада в производительности, в сиквеле тебе надо продумывать смысл своих действий и зависимости между ними.

Зато когда ты научился этому, у тебя в голове возникает четкое представление про уровни изоляции и понимание того, что такое "целостность". Это помогает разрабатывать более хорошие приложения, неважно на какой СУБД.

Ну, и после всего этого боевого опыта мы с нетерпением ждем следующей версии, надеясь на то, что в ней наши глубокие знания не потребуются для ежедневной работы

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Mikst, Вы писали:

M>>Да легко, агрегат хранится в соседней табличке, при апдейте основной таблицы, его просто блокируют и пересчитывают, из триггера, так что все автоматом. и все было шито крыто, это конечно же "приседание", но удобное, простое и без излишних блокировок
M>Ура. Вы только что придумали способ каким работают с подобного рода задачами блокировочники, только они делают это эффективнее, поскольку у Оракла нет Row Level Read Lock.

Ну так скажем — далеко не только что А кто спорит что блокировочники не так работают, так, НО! они так ВСЕГДА работают, а оракл — когда попрошу так, когда не попрошу, быстрее. А можно и без агрегата обойтись, а просто блокировать запись в табличке левой (как флаг блокировки) и делать с основной что надо, а клиенты спокойнехонько себе делают select sum(amount) .. красота.

M>> Опять таки, мой вопрос в силе: в приложении одна таблица, в нее пишут, из нее читают — хочу всегда читать правильные данные, хочу без лишних проблем писать данные, хочу чтобы все было быстро.
M>Очень просто. Вы же сами только что привели пример с агрегатами, здесь подход точно такой же...
M>Данные пишутся в основную табличку, а читаются из агрегатов, все получается очень шустро и комфортно.

Из каких агрегатов они читаются??? Мне данные нужны из строк, а не агрегаты строк.
Возвращаясь к нашим баранам: есть у меня 10000 записей, и их селектят as select *, и всего 100 записей раз в минуту обновляются, мало того что при этом один раз дэдлок возник, фиг бы с ним, но ведь селекты и апдейты тормозят друг друга. А еще селекты бывают по разным условиям, select sum(amount) where amount<10 и как тут быть? на каждое значение временную талицу агрегатов делать? Мне не важно (как были крики в одном топике) честное значение селекта на конец транзакции, мне важно избежать чтения фантомов (поэтому IL RR) и иметь результат на начало селекта. Все, болше ничего не требуется, главное чтобы не тормозило.

И вот только не надо про "неправильный подход и архитектуру", я бы рад все переделать, но!
во-первых, пока даже не представляю как, (если недостаточно конкретно объяснил проблему, требуйте дополнений, опишу вплоть до атома )
во-вторых, эту систему можно переделать только со стороны апдейтов, все что делает селект скомпилировано и закрыто.

Спасибо.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Mikst, Вы писали:

S>Видишь ли, в чем дело. MS SQL разрабатывался с оглядкой прежде всего на OLTP.
S>А в этой схеме сам вопрос "как мне прочитать согласованное состояние всех нафиг данных зараз" неуместен. Потому, что он противоречит цели "сделать обработку транзакций максимально эффективной".
S>И, что характерно, парням все удалось. Долгое время именно сиквел рулил на tpc.org. Ораклу удалось его подвинуть только после выхода десятки, и то благодаря кластерному использованию совершенно нечеловеческих ресурсов. Что характерно, ненадолго — сейчас олимп занят DB2, который представляет собой совершенно чистый блокировочник.

Так кто же про это спорит.

S>Конечно же, прикладным программистам, которые разрабатывают конечные решения, до лампочки эта сферическая правильность. Кому тут надо выполнять миллион транзакций в минуту?

S>С точки зрения сиквела, если программисту хочется оперировать над снапшотом, то он должен этот снапшот вручную получить. Ну не предназначен OLTP storage для выполнения тэйбл сканов.
S>Есть эн способов это сделать — временные таблицы, индексированные вью, репликация в отдельную базу, наполнение OLAP хранилища.
S>И, по большому счету, эти способы, хоть и "приседательные", более правильны. Если сначала твой отчет, построенный прямо поверх исходных данных, будет как-то ездить, то при росте объема решение с ежесуточным сбросом изменений в OLAP порвет его как тузик грелку. Потому, что ни один сторидж не обеспечит необходимой скорости подсчета агрегатов.

S>К сожалению, все эти чудеса сдерживаются трудностью необходимых приседаний. Я думаю, именно это стало причиной введения таки автоматической поддержки снапшотов в MS SQL 2005.

S>Лично мне нравится MS SQL. Ну, неформально так.
Потому, что он дружественный к пользователю — поднять Оракл это не фунт изюму. И потому, что он требовательный к архитектору. Противоестественно — но так.

А вот с этим категорически не согласен. Оракл ставил мульен раз и никогда никаких траблов не было (все это происки империалистов). А вот с дружественностью MSSQL (да как и всего MS) она есть, не спорю, но до поры до времени, пока не потребуется хоть что-то чуть менее стандартное чем позволяет интерфейс EM. (Как в нем указать логин на юзера в базе,я так до сих пор и не понял, так же не понял куда и почему этот логин переодически пропадает. Как и где посмотреть размеры, параметры хранения индексов и таблиц) Ну короче "дружественностью" МС меня не балует.

S>Там, где ты мог в оракле, грубо говоря, надеяться на "авось" — пусть сервер сам там разруливает где что, сегмент отката там наращивает, пусть и ценой просада в производительности, в сиквеле тебе надо продумывать смысл своих действий и зависимости между ними.

Это программисты могу надеятся на авось, и оно будет работать если надо. Но приходит ДБА, и делает так, чтобы все работало как надо, безо всякого "авося". А дело программистов не вдаваясь в подробности работы СУБД (в глубокие подробности конечно же) писать код, хорошо работающий для конкретной бизнесс логики. Т.е. БД для людей, а не люди для БД.


S>Зато когда ты научился этому, у тебя в голове возникает четкое представление про уровни изоляции и понимание того, что такое "целостность". Это помогает разрабатывать более хорошие приложения, неважно на какой СУБД.

Этому всему можно (и нужно) учится действительно на любой СУБД, только вот МС не предоставляет свободы выбора.

S>Ну, и после всего этого боевого опыта мы с нетерпением ждем следующей версии, надеясь на то, что в ней наши глубокие знания не потребуются для ежедневной работы



PS: Не хочу показаться грубым и невежественный, но для прикладных задач, которые в большинстве своем делаются в наше время, МС ну никак не подходит. Дорого больно на нем что-то делать. IMHO.

Здравствуйте, Mikst, Вы писали:

M> они так ВСЕГДА работают, а оракл — когда попрошу так, когда не попрошу, быстрее.
Быстрее — нет, быстрее не получится..

M> А можно и без агрегата обойтись, а просто блокировать запись в табличке левой (как флаг блокировки) и делать с основной что надо, а клиенты спокойнехонько себе делают select sum(amount) .. красота.
Самое время ознакомиться с пользовательскими блокировками, это, как правило, полезнее чем галочки в таблице..

M>Возвращаясь к нашим баранам: есть у меня 10000 записей, и их селектят as select *, и всего 100 записей раз в минуту обновляются,
Отлично. Эти 10000 связаны между собой? Если да, то скорее всего это какой-то агрегат, тогда возвращаемся к тому что выше.
Если нет, то и проблем с чтением этих записей в Read Committed быть не должно.

M> мало того что при этом один раз дэдлок возник, фиг бы с ним, но ведь селекты и апдейты тормозят друг друга.
Да не должы они тормозить. 100 записей обновляются совершенно незаметно, что в блокировочном режиме, что нет.

M> А еще селекты бывают по разным условиям, select sum(amount) where amount<10 и как тут быть?
Например, RR и индекс по amount.

Здравствуйте, Mikst, Вы писали:

M>А вот с этим категорически не согласен. Оракл ставил мульен раз и никогда никаких траблов не было (все это происки империалистов).
Я сам не пробовал, потому обсуждать это не буду. Может, оно все и легко.
M>А вот с дружественностью MSSQL (да как и всего MS) она есть, не спорю, но до поры до времени, пока не потребуется хоть что-то чуть менее стандартное чем позволяет интерфейс EM. (Как в нем указать логин на юзера в базе,я так до сих пор и не понял,
Ну так спрашивай!
Что тебе непонятно? Там все просто, как угол дома.
RTFBOL:
sp_grantdbaccess
sp_adduser
sp_change_users_login

M> так же не понял куда и почему этот логин переодически пропадает.
Скорее всего, ты ресторишь бэкап/аттачишь базу не на том сервере, где бэкапил/детачил.
Понятно, что ссылки из локальной базы в master.syslogins
M> Как и где посмотреть размеры, параметры хранения индексов и таблиц
Гм. Прямо в EM пойти на соответствующую закладку в таскпаде? Там все размеры в красивом виде приведены.
M>) Ну короче "дружественностью" МС меня не балует.
Это, наверное, оттого, что ты ее в нем не ищешь.
M>Это программисты могу надеятся на авось, и оно будет работать если надо. Но приходит ДБА, и делает так, чтобы все работало как надо, безо всякого "авося".
Э-э нет, ДБА никак тебе не поправит запросы, которые вшиты в клиентское приложение. И если ты выбрал неудачный набор хранимок для общения с сервером, то ДБА уже ничем не поможет.
M> А дело программистов не вдаваясь в подробности работы СУБД (в глубокие подробности конечно же) писать код, хорошо работающий для конкретной бизнесс логики.
У меня есть глубокие сомнения, что не вдаваясь в подробности работы СУБД можно написать код, хорошо работающий для конкретной бизнес логики.

M>Этому всему можно (и нужно) учится действительно на любой СУБД, только вот МС не предоставляет свободы выбора.
Угу. Этакое насильственное благо. За это мы его и любим

M>PS: Не хочу показаться грубым и невежественный, но для прикладных задач, которые в большинстве своем делаются в наше время, МС ну никак не подходит. Дорого больно на нем что-то делать. IMHO.

Да ну. Ты вот сколько времени учился с Ораклом работать? Я тебя уверяю — сиквел ты освоишь значительно быстрее
Если, конечно, не станешь этому сопротивляться.

Здравствуйте, Mikst, Вы писали:

M>Из каких агрегатов они читаются??? Мне данные нужны из строк, а не агрегаты строк.
M>Возвращаясь к нашим баранам: есть у меня 10000 записей, и их селектят as select *, и всего 100 записей раз в минуту обновляются
[оффтоп]
Вот это — попытка скрестить OLTP и OLAP. В OLTP нельзя делать select *, в OLAP нельзя апдейтить по сто записей в минуту.
[/оффтоп]
M>, мало того что при этом один раз дэдлок возник, фиг бы с ним, но ведь селекты и апдейты тормозят друг друга. А еще селекты бывают по разным условиям, select sum(amount) where amount<10 и как тут быть? на каждое значение временную талицу агрегатов делать? Мне не важно (как были крики в одном топике) честное значение селекта на конец транзакции, мне важно избежать чтения фантомов (поэтому IL RR) и иметь результат на начало селекта.
Насчет важности на начало селекта — это ты, конечно, погорячился. Никто никогда в жизни не отличит результата на начало селекта от результата на конец селекта.
M>Все, болше ничего не требуется, главное чтобы не тормозило.

M>во-вторых, эту систему можно переделать только со стороны апдейтов, все что делает селект скомпилировано и закрыто.
Значит, можно подсунуть селекту вью, а апдейтить в другое место

Примеры, которые ты приводишь, конечно же далеки от истины. Апдейт ста строк — мгновенная операция на современном железе. Селект 10000 — тоже тьфу. Никто там и не заметит никаких тормозов.
Самый простой способ побороть блокировки и дедлоки — улучшить планы запросов настолько, чтобы никто ничего не замечал. Тебе уже несколько раз намекали на важность правильной раздачи индексов. Незачем заставлять сервер сканировать лишние данные.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Mikst, Вы писали:

M>>Из каких агрегатов они читаются??? Мне данные нужны из строк, а не агрегаты строк.
M>>Возвращаясь к нашим баранам: есть у меня 10000 записей, и их селектят as select *, и всего 100 записей раз в минуту обновляются
S>[оффтоп]
S>Вот это — попытка скрестить OLTP и OLAP. В OLTP нельзя делать select *, в OLAP нельзя апдейтить по сто записей в минуту.
S>[/оффтоп]

Всеже данная задача больше к OLAP относится... селекты чаще.

S>Значит, можно подсунуть селекту вью, а апдейтить в другое место

эх...

S>Примеры, которые ты приводишь, конечно же далеки от истины. Апдейт ста строк — мгновенная операция на современном железе. Селект 10000 — тоже тьфу. Никто там и не заметит никаких тормозов.

Ну там больше строк, естественно. Просто к чему все это, боюсь заставят меня писать под МС прогу, ужас как неохота, а придется.

S>Самый простой способ побороть блокировки и дедлоки — улучшить планы запросов настолько, чтобы никто ничего не замечал. Тебе уже несколько раз намекали на важность правильной раздачи индексов. Незачем заставлять сервер сканировать лишние данные.

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

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Mikst, Вы писали:

M>> они так ВСЕГДА работают, а оракл — когда попрошу так, когда не попрошу, быстрее.
M>Быстрее — нет, быстрее не получится..

M>> А можно и без агрегата обойтись, а просто блокировать запись в табличке левой (как флаг блокировки) и делать с основной что надо, а клиенты спокойнехонько себе делают select sum(amount) .. красота.
M>Самое время ознакомиться с пользовательскими блокировками, это, как правило, полезнее чем галочки в таблице..

M>>Возвращаясь к нашим баранам: есть у меня 10000 записей, и их селектят as select *, и всего 100 записей раз в минуту обновляются,
M>Отлично. Эти 10000 связаны между собой? Если да, то скорее всего это какой-то агрегат, тогда возвращаемся к тому что выше.
M>Если нет, то и проблем с чтением этих записей в Read Committed быть не должно.

Ну как это?? если во время селекта, некто умудрится успеть изменить и закоммиттить стори которые он еще не прочитал — что тогда увидит пользователь?? Фигню он увидит.

M>> мало того что при этом один раз дэдлок возник, фиг бы с ним, но ведь селекты и апдейты тормозят друг друга.
M>Да не должы они тормозить. 100 записей обновляются совершенно незаметно, что в блокировочном режиме, что нет.

Значит это в тестовой базе у меня 10000 и 100 обновляются, на рабочей их думаю на порядок больше, а во вторых обновление происходит через инет, и реально длится до 10 секунд (я думаю всетаки на блокировки каждого отдельного апдейта различными селектами).

M>> А еще селекты бывают по разным условиям, select sum(amount) where amount<10 и как тут быть?
M>Например, RR и индекс по amount.

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

Здравствуйте, Mikst, Вы писали:

M>Давать индексы в оракле чтобы работало быстро — я умею, но вот пока не вкурил как индексы помогают с блокировками.
Здесь тоже, главное чтобы работало быстро, правда с "чтобы работало быстро" есть свои особенности. Например, кластерный индекс должен присутствовать практически в каждой таблице, в отличии от оракла, где его аналог практически бесполезен.
Плюс к этому, блокировки во многом используют индексы для совей работы, могу рассказать подробнее но это тема отдельного разговора..

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Mikst, Вы писали:

M>>А вот с этим категорически не согласен. Оракл ставил мульен раз и никогда никаких траблов не было (все это происки империалистов).
S>Я сам не пробовал, потому обсуждать это не буду. Может, оно все и легко.
M>>А вот с дружественностью MSSQL (да как и всего MS) она есть, не спорю, но до поры до времени, пока не потребуется хоть что-то чуть менее стандартное чем позволяет интерфейс EM. (Как в нем указать логин на юзера в базе,я так до сих пор и не понял,
S>Ну так спрашивай!
S>Что тебе непонятно? Там все просто, как угол дома.
S>RTFBOL:
S>sp_grantdbaccess
S>sp_adduser
S>sp_change_users_login

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

M>> так же не понял куда и почему этот логин переодически пропадает.
S>Скорее всего, ты ресторишь бэкап/аттачишь базу не на том сервере, где бэкапил/детачил.
S>Понятно, что ссылки из локальной базы в master.syslogins

Так и есть. Согласен, но как установить того что я хочу прямо из ЕМ... не дает зараза этого делать.

M>> Как и где посмотреть размеры, параметры хранения индексов и таблиц
S>Гм. Прямо в EM пойти на соответствующую закладку в таскпаде? Там все размеры в красивом виде приведены.

"соответствующую закладку " я уже искал, можно ее название пожалуйста.

M>>) Ну короче "дружественностью" МС меня не балует.
S>Это, наверное, оттого, что ты ее в нем не ищешь.
M>>Это программисты могу надеятся на авось, и оно будет работать если надо. Но приходит ДБА, и делает так, чтобы все работало как надо, безо всякого "авося".
S>Э-э нет, ДБА никак тебе не поправит запросы, которые вшиты в клиентское приложение. И если ты выбрал неудачный набор хранимок для общения с сервером, то ДБА уже ничем не поможет.

"набор хранимок для общения с сервером" .. как я посмотрю в МС без хранимок никуда.... не используем мы их без особой на то надобности.


M>> А дело программистов не вдаваясь в подробности работы СУБД (в глубокие подробности конечно же) писать код, хорошо работающий для конкретной бизнесс логики.
S>У меня есть глубокие сомнения, что не вдаваясь в подробности работы СУБД можно написать код, хорошо работающий для конкретной бизнес логики.

можно можно, при соответствующем сотрудничестве с ДБА.

M>>Этому всему можно (и нужно) учится действительно на любой СУБД, только вот МС не предоставляет свободы выбора.
S>Угу. Этакое насильственное благо. За это мы его и любим

Мазохисты прям

M>>PS: Не хочу показаться грубым и невежественный, но для прикладных задач, которые в большинстве своем делаются в наше время, МС ну никак не подходит. Дорого больно на нем что-то делать. IMHO.

S>Да ну. Ты вот сколько времени учился с Ораклом работать? Я тебя уверяю — сиквел ты освоишь значительно быстрее
S>Если, конечно, не станешь этому сопротивляться.

Убивает меня эта фраза "сколько времени учился с Ораклом работать" — нисколько! Сел и сделал программу, и она работает, естественно потом я переделал структуру базы, индексы создал, кое что поменял. НО! все это время она _РАБОТАЛА_, и никто из пользователей ни разу не пришел и не сказал, "блин, я не могу клиенту фамилию поправить", а я бы ответил, ну видишь, босс мегаотчет запустил, все свободны, идите домой...

Понятно что мега отчеты по началу шевелились медленно, но шевелились. А в МСе все стоит колом, или данные неправильные показывает. И это при том, что я уже прекрасно понимаю что и зачем делаю.

Здравствуйте, Mikst, Вы писали:

M>Ну как это?? если во время селекта, некто умудрится успеть изменить и закоммиттить стори которые он еще не прочитал — что тогда увидит пользователь?? Фигню он увидит.
Он увидит фигню только в том случае если строки в таблице зависят друг от друга, а если нет, то эта фигня никого не волнует.

M>Значит это в тестовой базе у меня 10000 и 100 обновляются, на рабочей их думаю на порядок больше, а во вторых обновление происходит через инет, и реально длится до 10 секунд (я думаю всетаки на блокировки каждого отдельного апдейта различными селектами).
Значит надо заливать из инета в отдельную таблицу и потом апдейтить основную...

M>А апдейт не будет блокировать при изменении amount кроме таблицы и этот самый индекс?
Он будет блокировать в первую очередь индекс.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Mikst, Вы писали:

M>>Ну как это?? если во время селекта, некто умудрится успеть изменить и закоммиттить стори которые он еще не прочитал — что тогда увидит пользователь?? Фигню он увидит.
M>Он увидит фигню только в том случае если строки в таблице зависят друг от друга, а если нет, то эта фигня никого не волнует.

Подкололи Уважаю.. но тем не менее результат — фигня.

M>>Значит это в тестовой базе у меня 10000 и 100 обновляются, на рабочей их думаю на порядок больше, а во вторых обновление происходит через инет, и реально длится до 10 секунд (я думаю всетаки на блокировки каждого отдельного апдейта различными селектами).
M>Значит надо заливать из инета в отдельную таблицу и потом апдейтить основную...

что я и делаю собственно.

M>>А апдейт не будет блокировать при изменении amount кроме таблицы и этот самый индекс?
M>Он будет блокировать в первую очередь индекс.

а если кроме amount изменяется остальные поля?? все равно блокировка чтения?

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, GlebZ, Вы писали:

GZ>> Стандарт SQL92 (обсуждаемый в статье) писали, прежде всего, ораклоиды.
M>Его писали все подряд, начиная IBM-ерами и заканчивая MS.
Нее. У MS в 92 году своей базы не было. Даже FoxPro они купили позже. Об SQL Server был еще полностью семантековский
Что касается Кайта, то хоть убей не найду где я это читал. На вопрос насколько Oracle поддерживает SQL92 он очень оригинально ответил. Смысл был такой, ребяты, вы что. Мы сами стандарт и писали. И принимали непосредственное участие в этом. Ну и далее стандартно объяснял об уровнях в SQL92 и как поддерживается. Но вот откуда я читал это, не найду.

GZ>>Неплохо было-бы прочитать кто написал эту статью, и где они работают. Когда они начали гнать почему в стандарт не внесли блокировки, я плакал от умиления.
M>Статью написаль довольно известные и уважаемые в мире БД люди. Часть из них работает в MS...
Да, я заметил.
M>И стандарт версии 92го года действительно довольно бестолково написан в разделе уровней изоляции с сильным креном в сторону блокировочников, за что подвергался неоднократной критике.
M>Собственно упомянутая статья является выжимкой всей этой критики и считается классическим обзором уровней изоляции...
M>Только одно но... ее нельзя читать на русском в этом переводе, часть смысла утеряна и, что существенно хуже, искажена.
M>Вот оригинал: A Critique of ANSI SQL Isolation Levels
Честно говоря статью не читал, только быстро. С одной стороны это уже история, но похоже достаточно интересная история. Обязательно прочитаю.

С уважением, Gleb.

GZ> Неплохо было-бы прочитать кто написал эту статью, и где они работают. Когда они начали гнать почему в стандарт не внесли блокировки, я плакал от умиления.

GZ>Честно говоря статью не читал, только быстро. С одной стороны это уже история, но похоже достаточно интересная история. Обязательно прочитаю.

я балдею

Здравствуйте, Mikst, Вы писали:

M>Подкололи Уважаю.. но тем не менее результат — фигня.
Я не подколол. Если строки в наборе не зависят друг от друга то совершенно не важно, что в выборку попали строки из разных версий. Вы же только что доказывали, что умеете так ловко проектировать, что строки у Вас совершенно независимы.

M>а если кроме amount изменяется остальные поля?? все равно блокировка чтения?
Тогда заблокируюется запись и другие индексы, если они есть...

Здравствуйте, GlebZ, Вы писали:

GZ>Что касается Кайта, то хоть убей не найду где я это читал. На вопрос насколько Oracle поддерживает SQL92 он очень оригинально ответил. Смысл был такой, ребяты, вы что. Мы сами стандарт и писали. И принимали непосредственное участие в этом. Ну и далее стандартно объяснял об уровнях в SQL92 и как поддерживается. Но вот откуда я читал это, не найду.
Кайт действительно входил в комитет по стандарту, но вот работал ли он в то время в Оракл — не уверен. У этого дядьки похоже вообще большой комплекс, по поводу того, что Оракл написали без него...

GZ>Честно говоря статью не читал, только быстро. С одной стороны это уже история, но похоже достаточно интересная история. Обязательно прочитаю.
В том-то и прелесть, что это не история, это то с чем мы сталкиваемся регулярно. С той давней поры в подходах к разруливанию consistency problem мало что изменилось — ну придумали несколько незначительных оптимизаций, не больше. Принципиальных сдвигов не произошло и все выкладки этих ребят до сих пор более чем актуальны.

Здравствуйте, Mikst, Вы писали:

M>Что-то как-то я не нашел таких команд в ЕМ Ну Почему sp_change_users_login нельзя сделать прямо из ЕМ??

M>Так и есть. Согласен, но как установить того что я хочу прямо из ЕМ... не дает зараза этого делать.
Ну, просто такой режим работы не предусматривался разработчиками. Не учли, что базу кто-то будет переносить между инстансами сервера.

M>"соответствующую закладку " я уже искал, можно ее название пожалуйста.
Извини, я наизусть не помню, а EM у меня не стоит в связи с переходом на новую версию сиквела. Там в таскпаде третья закладка как раз про размеры.

M>"набор хранимок для общения с сервером" .. как я посмотрю в МС без хранимок никуда.... не используем мы их без особой на то надобности.
Отлично. То есть запросы у вас прямо в код зашиты. Тогда расскажи мне, как твой ДБА исправит эти запросы?

M>можно можно, при соответствующем сотрудничестве с ДБА.
Гм. Лично я предпочитаю основные вещи писать не рассчитывая на наличие под рукой ДБА для проверки моих действий.

M>Мазохисты прям

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Mikst, Вы писали:

M>>Что-то как-то я не нашел таких команд в ЕМ Ну Почему sp_change_users_login нельзя сделать прямо из ЕМ??

M>>Так и есть. Согласен, но как установить того что я хочу прямо из ЕМ... не дает зараза этого делать.
S>Ну, просто такой режим работы не предусматривался разработчиками. Не учли, что базу кто-то будет переносить между инстансами сервера.

M>>"соответствующую закладку " я уже искал, можно ее название пожалуйста.
S>Извини, я наизусть не помню, а EM у меня не стоит в связи с переходом на новую версию сиквела. Там в таскпаде третья закладка как раз про размеры.


нету... ничего... абсолютно. ну да ладно.

M>>"набор хранимок для общения с сервером" .. как я посмотрю в МС без хранимок никуда.... не используем мы их без особой на то надобности.
S>Отлично. То есть запросы у вас прямо в код зашиты. Тогда расскажи мне, как твой ДБА исправит эти запросы?

Большинтво запросов простые, и нет надобности их исправлять. Сложные — да... тут надо выбирать, можно и ХП (я опять таки подчеркиваю, что не использую их _без особой на то надобности_, это не значит "никогда")


M>>можно можно, при соответствующем сотрудничестве с ДБА.
S>Гм. Лично я предпочитаю основные вещи писать не рассчитывая на наличие под рукой ДБА для проверки моих действий.

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

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Mikst, Вы писали:

M>>Подкололи Уважаю.. но тем не менее результат — фигня.
M>Я не подколол. Если строки в наборе не зависят друг от друга то совершенно не важно, что в выборку попали строки из разных версий. Вы же только что доказывали, что умеете так ловко проектировать, что строки у Вас совершенно независимы.

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

M>>а если кроме amount изменяется остальные поля?? все равно блокировка чтения?
M>Тогда заблокируюется запись и другие индексы, если они есть...

ну а смысл тогда в таком индексе.. эх. проще все под оракл переписать

Здравствуйте, Mikst, Вы писали:

M> нету... ничего... абсолютно. ну да ладно.
Есть. На базе жмем правую кнопку. View -> TaskPad и наслаждаемся просмотром деталей.

Здравствуйте, Horror_Infinity, Вы писали:

H_I>Здравствуйте, Mikst, Вы писали:

M>> нету... ничего... абсолютно. ну да ладно.
H_I>Есть. На базе жмем правую кнопку. View -> TaskPad и наслаждаемся просмотром деталей.

алелуя!! Вот что называется "дружественный интерфейс" )))))) для начала надо было встать на уровень БД потом выбрать в несовсем привычном меню, совершенно непонятную команду... и потом не сразу заметить закладку Table Info

PS: Спасибо.

Здравствуйте, Mikst, Вы писали:

M>алелуя!! Вот что называется "дружественный интерфейс" )))))) для начала надо было встать на уровень БД потом выбрать в несовсем привычном меню, совершенно непонятную команду... и потом не сразу заметить закладку Table Info
Собственно, у Oracle он не менее дружественный... Потому как оракловый EM для человека, впервые видящего Oracle, такой же темный лес. А уж про EM for Oracle 10g — так это вообще нечто! Не так?

M>PS: Спасибо.
Да не за что! Всегда рад помочь...

Здравствуйте, Horror_Infinity, Вы писали:

H_I>Здравствуйте, Mikst, Вы писали:

M>>алелуя!! Вот что называется "дружественный интерфейс" )))))) для начала надо было встать на уровень БД потом выбрать в несовсем привычном меню, совершенно непонятную команду... и потом не сразу заметить закладку Table Info
H_I>Собственно, у Oracle он не менее дружественный... Потому как оракловый EM для человека, впервые видящего Oracle, такой же темный лес. А уж про EM for Oracle 10g — так это вообще нечто! Не так?

Дааа, в 10ке они конечно наворотили. А вот 8-9 у меня никогда не вызывал чувство дискомфорта, как-то все само находится где ожидаешь. Но даже при этом я не утверждаю что он дружественный Хотя дальше всех в этом ушла IBM с ее DB2 Там просто песня.

Здравствуйте, Mikst, Вы писали:

M>Дааа, в 10ке они конечно наворотили. А вот 8-9 у меня никогда не вызывал чувство дискомфорта, как-то все само находится где ожидаешь. Но даже при этом я не утверждаю что он дружественный Хотя дальше всех в этом ушла IBM с ее DB2 Там просто песня.

Да нет... На самом деле все просто. Надо только доки почитать. Но вот что ошибочно, это то, что задача, написанная для одной СУБД, будет непременно точно так же работать и под другой СУБД. Но ведь это же не так! Любая задача учитывает особенности той СУБД, под которую и писалась. Значит, чтобы получить одинаковые результаты, надо еще постараться!

Я как-то занимался обратной задачей — переносом БД с MS SQL на Oracle. Столько всего огреб — страшно вспоминать.

Здравствуйте, Horror_Infinity, Вы писали:

H_I>Здравствуйте, Mikst, Вы писали:

M>>Дааа, в 10ке они конечно наворотили. А вот 8-9 у меня никогда не вызывал чувство дискомфорта, как-то все само находится где ожидаешь. Но даже при этом я не утверждаю что он дружественный Хотя дальше всех в этом ушла IBM с ее DB2 Там просто песня.

H_I>Да нет... На самом деле все просто. Надо только доки почитать. Но вот что ошибочно, это то, что задача, написанная для одной СУБД, будет непременно точно так же работать и под другой СУБД. Но ведь это же не так! Любая задача учитывает особенности той СУБД, под которую и писалась. Значит, чтобы получить одинаковые результаты, надо еще постараться!

H_I>Я как-то занимался обратной задачей — переносом БД с MS SQL на Oracle. Столько всего огреб — страшно вспоминать.

А если не сильно страшно вспомнить, (для расширения кругозора), какие наибольшие (доставившие более всего хлопот) проблемы были?

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

Здравствуйте, Mikst, Вы писали:

M>Они не зависят в данном случае друг от друга, но они долны быть одной версии,
Так не бывает. Либо они независимы и тогда не важно какой они версии.
Либо зависимы и тогда надо смотреть на эту зависимость.

M>ну а смысл тогда в таком индексе..
В том, что при чтении будет блокироваться только этот индекс и само чтение будет быстрым и никому не помешает.

Здравствуйте, Mikst, Вы писали:

M>Здравствуйте, Horror_Infinity, Вы писали:

H_I>>Здравствуйте, Mikst, Вы писали:

M>>>Дааа, в 10ке они конечно наворотили. А вот 8-9 у меня никогда не вызывал чувство дискомфорта, как-то все само находится где ожидаешь. Но даже при этом я не утверждаю что он дружественный Хотя дальше всех в этом ушла IBM с ее DB2 Там просто песня.

H_I>>Да нет... На самом деле все просто. Надо только доки почитать. Но вот что ошибочно, это то, что задача, написанная для одной СУБД, будет непременно точно так же работать и под другой СУБД. Но ведь это же не так! Любая задача учитывает особенности той СУБД, под которую и писалась. Значит, чтобы получить одинаковые результаты, надо еще постараться!

H_I>>Я как-то занимался обратной задачей — переносом БД с MS SQL на Oracle. Столько всего огреб — страшно вспоминать.

M>А если не сильно страшно вспомнить, (для расширения кругозора), какие наибольшие (доставившие более всего хлопот) проблемы были?
Да почему же? Основной геморрой будет как раз с теми самыми временными таблицами, которых в оракле просто нет. Как результат — либо переписывание заново логики хранимок, либо написание табличных функций, что не добавит производительности. Несовпадение типов данных. VARCHAR2(Oracle) != VARCHAR(MS). Как следствие — изменение метаданных таблиц. Что тоже не есть гуд. И таких мелочей и немелочей довольно много.

M>Просто сейчас зашла речь про перенос этой програмки на оракл, так как читателю всеравно откуда читать, а писателей можем переписать как нужно.
А нужно ли переносить? Работа нудная, кропотливая и довольно длительная.

Здравствуйте, Horror_Infinity, Вы писали:

H_I>Здравствуйте, Mikst, Вы писали:

M>>Здравствуйте, Horror_Infinity, Вы писали:

H_I>>>Здравствуйте, Mikst, Вы писали:

M>>>>Дааа, в 10ке они конечно наворотили. А вот 8-9 у меня никогда не вызывал чувство дискомфорта, как-то все само находится где ожидаешь. Но даже при этом я не утверждаю что он дружественный Хотя дальше всех в этом ушла IBM с ее DB2 Там просто песня.

H_I>>>Да нет... На самом деле все просто. Надо только доки почитать. Но вот что ошибочно, это то, что задача, написанная для одной СУБД, будет непременно точно так же работать и под другой СУБД. Но ведь это же не так! Любая задача учитывает особенности той СУБД, под которую и писалась. Значит, чтобы получить одинаковые результаты, надо еще постараться!

H_I>>>Я как-то занимался обратной задачей — переносом БД с MS SQL на Oracle. Столько всего огреб — страшно вспоминать.

M>>А если не сильно страшно вспомнить, (для расширения кругозора), какие наибольшие (доставившие более всего хлопот) проблемы были?
H_I>Да почему же? Основной геморрой будет как раз с теми самыми временными таблицами, которых в оракле просто нет. Как результат — либо переписывание заново логики хранимок, либо написание табличных функций, что не добавит производительности. Несовпадение типов данных. VARCHAR2(Oracle) != VARCHAR(MS). Как следствие — изменение метаданных таблиц. Что тоже не есть гуд. И таких мелочей и немелочей довольно много.

хранимок и временных таблиц нет. Приложение по сути наипростейшее. стандартный DDL и все.
метаданные все в PowerDisigner, пересоздать схему раз плюнуть. Репликацию думаю тоже сделать не архисложно.

M>>Просто сейчас зашла речь про перенос этой програмки на оракл, так как читателю всеравно откуда читать, а писателей можем переписать как нужно.
H_I>А нужно ли переносить? Работа нудная, кропотливая и довольно длительная.

Зато результат как говорится будет "на лице" (довольном что все работает)

Здравствуйте, Mikst, Вы писали:

M>хранимок и временных таблиц нет. Приложение по сути наипростейшее. стандартный DDL и все.
M>метаданные все в PowerDisigner, пересоздать схему раз плюнуть. Репликацию думаю тоже сделать не архисложно.
Тогда — да. Просто. Остается только проблема совместимости типов данных и иж размерностей. Но это — как повезет. Если нигде нет строковых данных, превышающих оракловые 4000 байт, то и слава Богу. А если есть?

M>Зато результат как говорится будет "на лице" (довольном что все работает)
Ну, заранее этого сказать все ж таки нельзя.

Здравствуйте, Merle, Вы писали:

GZ>>Что касается Кайта, то хоть убей не найду где я это читал. На вопрос насколько Oracle поддерживает SQL92 он очень оригинально ответил. Смысл был такой, ребяты, вы что. Мы сами стандарт и писали. И принимали непосредственное участие в этом. Ну и далее стандартно объяснял об уровнях в SQL92 и как поддерживается. Но вот откуда я читал это, не найду.
M>Кайт действительно входил в комитет по стандарту, но вот работал ли он в то время в Оракл — не уверен. У этого дядьки похоже вообще большой комплекс, по поводу того, что Оракл написали без него...
Кайт писал что работал с Oracle версии 5, следовательно на момент выхода стандарта — уже был ораклистом. С другой стороны, я не видел каких-то теоретических работ мистера Кайта — следовательно как независимый он вряд ли мог появиться в комитете. Отсюда вывод — был в комитете как представитель Oracle.

GZ>>Честно говоря статью не читал, только быстро. С одной стороны это уже история, но похоже достаточно интересная история. Обязательно прочитаю.
M>В том-то и прелесть, что это не история, это то с чем мы сталкиваемся регулярно. С той давней поры в подходах к разруливанию consistency problem мало что изменилось — ну придумали несколько незначительных оптимизаций, не больше. Принципиальных сдвигов не произошло и все выкладки этих ребят до сих пор более чем актуальны.
Прочитал. Да, занятная статья. Попробовал по русски сначало прочесть. Понял что это слишком непросто. За перевод убил бы. Пришлось читать буржуйский вариант.
Просто не понял почему в SQL92 крен в сторону блокировочников. Феномены не ограничиваются тремя наиболее известными случаями. И это ясно показывается и доказывается(некоторые феномены еще Дейт раньше описывал). Вроде термин сериализации кардинально поправили в новых стандартах.

С уважением, Gleb.

Здравствуйте, Mikst, Вы писали:

M>хранимок и временных таблиц нет. Приложение по сути наипростейшее. стандартный DDL и все.
M>метаданные все в PowerDisigner, пересоздать схему раз плюнуть. Репликацию думаю тоже сделать не архисложно.
Не забываем про сиквенсы?

С уважением, Gleb.

Здравствуйте, GlebZ, Вы писали:

GZ>Просто не понял почему в SQL92 крен в сторону блокировочников. Феномены не ограничиваются тремя наиболее известными случаями. И это ясно показывается и доказывается(некоторые феномены еще Дейт раньше описывал).
В том-то и дело, что феномены этими тремя случаями далеко не исчерпываются, но в стандарте уровни изоляции вводятся посредством именно этих трех феноменов, других критериев там не предусмотрено.
И эти три феномена идеально вписываются в блокировочную модель, а вот в версионнике, или шедулере какого-нибудь другого типа, так точно попасть в эту классификацию будет уже затруднительно.
Вообще говоря, с точки зрения стандарта было-бы логично требовать наличия только одного уровня изоляции — Serializable, А все остальное оставлять на откуп реализациям.

GZ>Вроде термин сериализации кардинально поправили в новых стандартах.
Там отдельная история, кардинально там ничего не правилось, поправили буквально одно предложение....
В SQL 92 Serializable вводился как 1. как защита от феномена фантомного чтения, 2. парой абзацев ниже, как критерий упорядоченности. Поскольку это очевидно не тождественные понятия, то из-за этого возникала некая двусмысленость, которая позволяла версионные снапшоты считать, с точки зрения стандарта, Serializable.
В SQL 99 добавили фразу, о том, что защита от фантомных чтений это конечно хорошо, но по настоящему Serializable, уровень изоляции является только тогда, когда гарантирует поведение транзакций соответствующее критерию упорядоченности, все остальные — в сад. Тем самым стандарт был приведен в соответствие с формальной теорией и здравым смыслом.

Здравствуйте, GlebZ, Вы писали:

GZ>Здравствуйте, Mikst, Вы писали:

M>>хранимок и временных таблиц нет. Приложение по сути наипростейшее. стандартный DDL и все.
M>>метаданные все в PowerDisigner, пересоздать схему раз плюнуть. Репликацию думаю тоже сделать не архисложно.
GZ>Не забываем про сиквенсы?

Кстати, да! Сенкс тебе, что напомнил. Что-то я упустил это из виду. С ними, правда, не так много возни, но все же. Забыл хоть про один, и приходи, кума, любоваться. Как-то было такое. Я два дня убил на поиски...

Здравствуйте, Horror_Infinity, Вы писали:

GZ>>Не забываем про сиквенсы?
H_I>Кстати, да! Сенкс тебе, что напомнил. Что-то я упустил это из виду. С ними, правда, не так много возни, но все же. Забыл хоть про один, и приходи, кума, любоваться. Как-то было такое. Я два дня убил на поиски...
Нет. Основная проблема в том, что их просто в MSSQL нет. А обычно sequence делаются уникальными для все базы а не одной таблицы. И это провязывается во внешнем коде. А у сиквела их нет, и в результате приходится либо делать подпорку(типа автоинкремента в таблице) или переписывать алгоритмы в коде, либо переводить в guid(что также отражается на всем коде).

С уважением, Gleb.