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

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

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> Аномалии вставок, изменений и потерянных данных , это все другой разговор и другая тема.
Это именно тот разговор и именно та тема.