|
блокировки при удалении покрывающего индекса
|
|||
---|---|---|---|
#18+
invm, привет выше речь шла о том, что подразумевается работа в RCSI я проверил, если создать синоним на таблицу, затем в одном сеансе вызвать select * from synonym, а в другом попробовать переименовать таблицу EXEC sp_rename 'dbo.tbl', 'dbo.tbl2'; или попробовать удалить синоним, чтобы пересоздать его указывая на новую таблицу то в обоих случаях система ждет пока не завершится select я неправильно понял Вашу идею? а если правильно, то нет смысла играть с синонимами (в моем случае), легче тогда использовать truncate + switch ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2021, 09:18 |
|
блокировки при удалении покрывающего индекса
|
|||
---|---|---|---|
#18+
Sandist удалить синоним, чтобы пересоздать его указывая на новую таблицу Что-то делали не так. Либо что-еще держит синоним. ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2021, 10:10 |
|
блокировки при удалении покрывающего индекса
|
|||
---|---|---|---|
#18+
invm, ну вот что я делаю: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21.
в отдельном окне запускаю (вообще работает read_commited_snapshot, но на всякий проверял и с with(nolock)): Код: sql 1. 2.
и затем в отдельном окне запускаю: Код: sql 1. 2.
и по итогу получаю ожидание удаления синонима что делаю не так? ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2021, 10:29 |
|
блокировки при удалении покрывающего индекса
|
|||
---|---|---|---|
#18+
Sandist, Да, действительно, держит Sch-S на синоним до конца запроса... ... |
|||
:
Нравится:
Не нравится:
|
|||
11.01.2021, 11:35 |
|
блокировки при удалении покрывающего индекса
|
|||
---|---|---|---|
#18+
Для тех кто не хочет заморачиваться и готов накрячить сервер (железяку) во имя красивости: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40.
Должно работать. После каждой поочерёдной перезаливки будут автоматически отображаться последние залитые данные (значение колонки rowtime при заливке очередной таблицы должно быть идентичным). Плюсы: + неограниченное число таблиц + конечной вьюхе, если не ошибаюсь, плевать на блокировки в плане отражения результатов + клиентская часть ни чего не знает о засаде (лишние поля скрываются через указание полей выдачи в селектах на таблицы) + любой скуль-сервер это должен сожрать,- ибо в логике и языке ни чего не нарушено Минусы: - всё остальное ... |
|||
:
Нравится:
Не нравится:
|
|||
13.01.2021, 20:37 |
|
блокировки при удалении покрывающего индекса
|
|||
---|---|---|---|
#18+
SIMPLicity_, спасибо за вариант, но у меня есть стойкое ощущение, что если добавить таблицу с одним полем и одной строкой с временем (или еще лучше с номером) текущих данных, а потому ее джоинить к основной и таким образом отбирать актуальные данные (в совокупности с read_commited_snapshot) - это будет быстрее чем union ... |
|||
:
Нравится:
Не нравится:
|
|||
17.01.2021, 18:30 |
|
блокировки при удалении покрывающего индекса
|
|||
---|---|---|---|
#18+
Sandist SIMPLicity_, спасибо за вариант, но у меня есть стойкое ощущение, что если добавить таблицу с одним полем и одной строкой с временем (или еще лучше с номером) текущих данных, а потому ее джоинить к основной и таким образом отбирать актуальные данные (в совокупности с read_commited_snapshot) - это будет быстрее чем union Ммммм.... Смысл был в чередовании таблиц ради обновления. Кстати, мой вариант тоже,- как бы сказать,- с говнецом. Так как в момент перезаливки таблицы в ней будут отражены неполные данные (с последней датой модификации). По хорошему надо лить с датой null и по окончании апдейтить дату на свежую. Но это всё весьма условно. Я думаю, что многострочные UNION-ы - это зло (как минимум - с точки зрения скорости выполнения запросов). JOIN-ить таблицу?,- тут я не понял идею. Вероятно подразумевался .... outer apply (select top 1 * from ... order by RowDate desc) ,- но это адская просадка по производительности в принципе. ИМБО. PS Я в подобных случаях оцениваю риск "провала в данных" и ищу решение исходя из ситуации. Но схожих ситуаций у меня не было,- у меня данные НЕ столь быстро и кардинально меняются ;) ... |
|||
:
Нравится:
Не нравится:
|
|||
18.01.2021, 12:28 |
|
|
start [/forum/topic.php?fid=46&gotonew=1&tid=1685201]: |
0ms |
get settings: |
8ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
164ms |
get topic data: |
10ms |
get first new msg: |
7ms |
get forum data: |
3ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 279ms |
0 / 0 |