|
SQL 2019 виртуальные колонки
|
|||
---|---|---|---|
#18+
Господа, у кого под рукой есть SQL Server 2019 отличный от Express версии, можете проверить есть в нем поддержка виртуальных колонок %%lockres%%, %%physloc%%? сейчас столкнулся с тем что на моем тестовом SQL Server 2019 Express он нивкакую не хочет их видеть, ругается на некорректный синтаксис, вот хочу понять это проблема экспресса или проблема 2019 сиквела? з.ы. а еще сегодня был неприятно удивлен поведением грязного чтения на строках подверженных инструкции delete когда не используется версионирование. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2021, 17:45 |
|
SQL 2019 виртуальные колонки
|
|||
---|---|---|---|
#18+
felix_ff, На Developer Edition работает. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2021, 17:50 |
|
SQL 2019 виртуальные колонки
|
|||
---|---|---|---|
#18+
msLex, понял, спасибо. походу это express порезали( ... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2021, 17:51 |
|
SQL 2019 виртуальные колонки
|
|||
---|---|---|---|
#18+
felix_ff сегодня был неприятно удивлен поведением грязного чтения на строках подверженных инструкции delete когда не используется версионирование. Выпил - выключи компуктер. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2021, 18:33 |
|
SQL 2019 виртуальные колонки
|
|||
---|---|---|---|
#18+
у меня тоже самое дает результат Incorrect systax near % в обоих инструкциях, О_о Microsoft SQL Server 2019 (RTM) - 15.0.2000.5 (X64) Sep 24 2019 13:48:23 Copyright (C) 2019 Microsoft Corporation Express Edition (64-bit) on Windows 10 Pro 10.0 <X64> (Build 19041: ) (Hypervisor) aleks222, Выпил - выключи компуктер. ну мб мб, но я чесно сказать был расстроен тем фактом что dirtyreads при TIL read uncommitted при условии что не включено версионирование считает удаленные строки удаленными при этом в справке черным по белому When this option is set, it is possible to read uncommitted modifications, which are called dirty reads ... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2021, 19:17 |
|
SQL 2019 виртуальные колонки
|
|||
---|---|---|---|
#18+
felix_ff, Видимо это глюк голого RTM ... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2021, 19:26 |
|
SQL 2019 виртуальные колонки
|
|||
---|---|---|---|
#18+
add: если кому интересно, предистория: сегодня наблюдал долгоиграющую транзакцию которая по сути откатывала некое начисление ну и созданные под ним проводки. решил посмотреть какие проводки уже откатились на текущий момент: Код: sql 1.
и такой запрос ничего не дал, хотя 65 сессия удерживала монопольные блокировки на ключи искомого индекса и в целом если бы данная сессия откатилась строки были бы восстановленны. я знал что инструкция удаляет строки по колонке parent_id = 555 то есть выполняя Код: sql 1.
я мог получить строки которые она еще не успела затронуть и даже получить %%lockres%% нужной строки в обратку я мог получить нужную строку инструкцией Код: sql 1.
но только до момента пока первая удаляющая транзакция не затронула данную строку, как только она получала монопольную блокировку строка уже под TIL: RUC переставала существовать первое на что обратил внимание что инструкции Код: sql 1. 2.
давали одинаковые результаты, хотя если бы такой запрос выполнялся для транзакции исполняющий insert, update результаты были бы разные, а вот с операцией delete чтение из таблицы производится как на TIL: RC при этом исполнение инструкций не блокируется. и такое поведение меняется только если включено RCSI, SI :( а главное я чет прямо явного указания в справке не нашел. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2021, 19:37 |
|
SQL 2019 виртуальные колонки
|
|||
---|---|---|---|
#18+
felix_ff, В общем случае невозможно гарантировать, что на RUC будут прочитаны удаленные данные. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2021, 20:15 |
|
SQL 2019 виртуальные колонки
|
|||
---|---|---|---|
#18+
invm, ну вот этот как раз меня в ступор немного и поставило, по сути строка подвержена изменению конкретной транзакции. при "грязном чтении" правильно ли судить что она должна быть прочитана? до текущего момента я считал что да. а так получается что "недоконца удаленную строку" можно получить только в том случае если используется RCSI/SI и это осознано должен не использоваться RUC в таком варианте. в этом поведении вижу явный риск в виде: есть к примеру некий условный счет, есть расходная операция по счету, приводящая остаток по счету в ноль. к примеру в какой то момент становится понятно что расходная операция по счету была немного некорректной и сумма ее должна быть меньше. открывается транзакция и начинается удаление этой расходной операции, но представим себе момент что удаление долгоиграющее (надо много всего проверить и.т.д.) в этот момент есть некий другой функционал который считает остаток по счету в режиме RUC (чур в меня не кидаться какашками это некое legacy решение которое работает как есть и сделано в "угоду" производительности. ) что же он увидит, что расходной операции нет и выдаст остаток на счете доступный для списания за минусом этой расходной операции. в тот же самый момент ушлый клиент насилует свой клиент банк в запросе остатка по счету, и в какой то момент получает доступный баланс равный сумме откатываемой операции списания, тут же делает расходный документ и отправляет его. представим что откат расходной операции мего-тормозной и проходит ну примерно час, за это время операционные сотрудники успевают увидеть новый документ от клиента и оформить расходную операцию, поскольку опять же тот же функционал запроса остатка показывает что "да, доступный остаток позволяет списать средства" что же будет тогда когда первая расходная операция откатится и нужно будет ее переоформить? на счете уже будет реальный ноль и новую расходную операцию оформить не удастся. я понимаю что пример притянут за уши, но есть реально некоторые системы работающие полностью на RUC ... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2021, 20:49 |
|
SQL 2019 виртуальные колонки
|
|||
---|---|---|---|
#18+
felix_ff при "грязном чтении" правильно ли судить что она должна быть прочитана? Specifies that statements can read rows that have been modified by other transactions but not yet committed.В теории раз вставленные строки относятся к "rows that have been modified", то удаленные должны. На практике же, возможность "грязного" чтения удаленных строк означает невозможность в той же транзакции повторно использовать освободившееся место для кучи и невозможность добавлять в индекс новые строки с такими же значениями ключей. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.06.2021, 21:28 |
|
|
start [/forum/topic.php?fid=46&fpage=21&tid=1684560]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
43ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
45ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 149ms |
0 / 0 |