С чувством времени ЧАТ'у еще нужно учиться. Человек с яблоками наврядли сделает ляп и если они только цветут, то не могут их уже собрать... раве что размышление заняло вечность
Я понимаю зачем автор статьи использует этот хинт, но в Enterprise версии сервера он не нужен. Во всех остальных да, его необходимо указывать, что бы Сиквел использовал вьюшку, зря что ли мы ее создавали? :)
На самом деле димамический SQL сильно помогает бороться с пунктом 6 (Оператоты OR and IN) и резко сокращает сложность запроса и время его выполнения. Да писать его сложно, сопровождать еще сложнее, но порой без него (особенно в различных веб приложениях с множественными фильтрами) жизнь немыслима :)
Ну это ведь неправда... Настолько неправда, что пришлось быстро тест подготовить.
Имеем не самую большую таблицу(примерно 400 млн записей):
SELECT count(*) FROM [dbo].[SourceProviders] WITH (NOLOCK)
--393222888
ну и сам тест:
CREATE TABLE tempdb.dbo.SourceProviders1 ([StagingProviderID] [bigint] CONSTRAINT [PK_SourceProviders1] PRIMARY KEY CLUSTERED ([StagingProviderID] ASC))
GO
SET STATISTICS TIME ON
PRINT '--1 pre-created table --'
INSERT INTO tempdb.dbo.SourceProviders1
SELECT [StagingProviderID]
FROM [dbo].[SourceProviders]
GO
PRINT '-- END 1 --'
PRINT '--2 Select Into table --'
SELECT [StagingProviderID]
INTO tempdb.dbo.SourceProviders2
FROM [dbo].[SourceProviders] WITH (TABLOCK)
GO
CREATE CLUSTERED INDEX IX_SourceProviders2_SourceProviders ON tempdb.dbo.SourceProviders2 ([StagingProviderID] ASC)
WITH (
MAXDOP = 8
,sort_in_tempdb = ON
)
GO
PRINT '-- END 2 --'
Результат:
--1 pre-created table --
SQL Server Execution Times: CPU time = 0 ms, elapsed time = 0 ms.
SQL Server Execution Times: CPU time = 367485 ms, elapsed time = 496638 ms.
(393222888 rows affected) SQL Server parse and compile time: CPU time = 0 ms, elapsed time = 1 ms. -- END 1 --
SQL Server Execution Times: CPU time = 0 ms, elapsed time = 0 ms. --2 Select Into table --
SQL Server Execution Times: CPU time = 0 ms, elapsed time = 0 ms.
SQL Server Execution Times: CPU time = 200172 ms, elapsed time = 89096 ms.
(393222888 rows affected) SQL Server parse and compile time: CPU time = 0 ms, elapsed time = 0 ms.
SQL Server Execution Times: CPU time = 406719 ms, elapsed time = 82332 ms. SQL Server parse and compile time: CPU time = 0 ms, elapsed time = 0 ms. -- END 2 --
SQL Server Execution Times: CPU time = 0 ms, elapsed time = 0 ms.
Если в этой таблице создавать еще кластерный индекс, то выигрыш через SELECT INTO будет еще на один порядок больше чем через таблицу с кластерным индексом
В любом случае, у нас есть кейс, в котором испльзование SELECT INTO предпочтительней исходя из времени. Т.е у нас появляются варианты когда мы хотим использовать один или другой подход. И это то место, где универсализм неуместен
Как по мне очень глупый поинт. Если индекс не монотонно возрастающий, то добро пожаловать в сплит страниц. (Никому не пожелаю в высоконагруженных приложениях)
6. Стараться в условиях не использовать оператор OR, а заменить его на IN или разбить на разные команды с помощью ветвления кода. Это вы никогда не попадали на эти ошибки видно в операторе IN
Error 8623:
The query processor ran out of internal resources and could not produce a query plan. This is a rare event and only expected for extremely complex queries or queries that reference a very large number of tables or partitions. Please simplify the query. If you believe you have received this message in error, contact Customer Support Services for more information.
Error 8632:
Internal error: An expression services limit has been reached. Please look for potentially complex expressions in your query, and try to simplify them.
Содержание витаминов в фруктах\ягодах справедливо только для свежих, только сорванных фруктов\ягод. Реальное же содержание особенно не в сезонных фруктах\ягодах может быть на 2 порядка ниже, того что вы привели
И в той картинке что в заголовке этой статьи еще полно минералов. О них вы вообще умолчали. Эти минералы могут содержаться в фруктах\овощах только если они растут на почве содержащей эти минералы. Т,е если селена нет в почве в той эрии где вы живете. То кроме как через бады вы его впринципе получить не можете.
When instant file initialization is disabled, both the data files and the transaction log files will be zeroed out when a database is created, restored, or file space is added. However, if instant file initialization is enabled then, only the transaction log is zeroed out during these operations.
Как я понял это работает только для файлов баз данных, но для логов все будет по прежнему?
Что особо удивительно мне удалось создать Distribution AO group поверх Container AO group. Обычно ее невозможно создать если в AO уже есть базы данных.
Жаль, что автор удалил эти сообщения. Мне кажется он очень эмоционально реагирует на ту непростую ситуацию в которую мы все сейчас разворачивается вокруг нас. Тем не мение мне кажется не правильно переносить политику в программирование, и подобные статьи должны жить дальше, тем более, что рукописи не горят... https://web.archive.org/web/20201004042530/https://habr.com/ru/post/315142/
С чувством времени ЧАТ'у еще нужно учиться.
Человек с яблоками наврядли сделает ляп и если они только цветут, то не могут их уже собрать... раве что размышление заняло вечность
Отличная ссылка. Спасибо!
Я понимаю зачем автор статьи использует этот хинт, но в Enterprise версии сервера он не нужен. Во всех остальных да, его необходимо указывать, что бы Сиквел использовал вьюшку, зря что ли мы ее создавали? :)
На самом деле димамический SQL сильно помогает бороться с пунктом 6 (Оператоты OR and IN) и резко сокращает сложность запроса и время его выполнения.
Да писать его сложно, сопровождать еще сложнее, но порой без него (особенно в различных веб приложениях с множественными фильтрами) жизнь немыслима :)
Ну это ведь неправда...
Настолько неправда, что пришлось быстро тест подготовить.
Имеем не самую большую таблицу(примерно 400 млн записей):
ну и сам тест:
Результат:
Итого 500000 ms против примерно 200000 ms
Если в этой таблице создавать еще кластерный индекс, то выигрыш через SELECT INTO будет еще на один порядок больше чем через таблицу с кластерным индексом
В любом случае, у нас есть кейс, в котором испльзование SELECT INTO предпочтительней исходя из времени.
Т.е у нас появляются варианты когда мы хотим использовать один или другой подход. И это то место, где универсализм неуместен
В скорости вставки.
SELECT INTO гораздо быстрей если вы накладываете эксклюзивную блокировкиу на читающую таблицу
Как по мне очень глупый поинт. Если индекс не монотонно возрастающий, то добро пожаловать в сплит страниц. (Никому не пожелаю в высоконагруженных приложениях)
Извините, я о пункте 6 хотел написать... Ошибочный copy\past
6. Стараться в условиях не использовать оператор OR, а заменить его на IN или разбить на разные команды с помощью ветвления кода.
Это вы никогда не попадали на эти ошибки видно в операторе IN
Жуткий OFF-top но добрые люди восстановили посты с sql.ru
можно все читать здесь:
https://resql.ru/forum/forums.php
знаю у вас та много всего было
я так подозреваю, что создание матерелизованной вьюхи с (WITH SCHEMABINDING) привело бы к похожим результатам
Содержание витаминов в фруктах\ягодах справедливо только для свежих, только сорванных фруктов\ягод. Реальное же содержание особенно не в сезонных фруктах\ягодах может быть на 2 порядка ниже, того что вы привели
И в той картинке что в заголовке этой статьи еще полно минералов. О них вы вообще умолчали. Эти минералы могут содержаться в фруктах\овощах только если они растут на почве содержащей эти минералы. Т,е если селена нет в почве в той эрии где вы живете. То кроме как через бады вы его впринципе получить не можете.
Противоречие с этой статьей: https://www.red-gate.com/simple-talk/databases/sql-server/database-administration-sql-server/instant-file-initialization/
Здесь они говорят что:
When instant file initialization is disabled, both the data files and the transaction log files will be zeroed out when a database is created, restored, or file space is added. However, if instant file initialization is enabled then, only the transaction log is zeroed out during these operations.
Как я понял это работает только для файлов баз данных, но для логов все будет по прежнему?
Что особо удивительно мне удалось создать Distribution AO group поверх Container AO group. Обычно ее невозможно создать если в AO уже есть базы данных.
Нет, они не используют tSQL для этого вообще.
Из того, что я нашел - вначале делался снепшот с Azure командой
Get-AzSnapshot
И потом этот снепшот восстанавливался с помощью
New-AzDiskConfig
New-AzDisk
Add-AzVMDataDisk
Получается. что если ты не используешь Облака или VMware
то это решение бесполезно.
А весь этот функционал это возможность использовать решение, которое использовалось в Azure для восстановления snapshot
https://github.com/microsoft/sql-server-samples/blob/master/samples/features/t-sql-snapshot-backup/snapshot-backup-restore-azurevm-single-db.ps1
Ты не знаешь, как они делают снепшоты с диска?
т.е на видео (5:24) в статье они запускают команду:
getshapshot.cmd
что бы сделать снепшоп
а потом на этом же видео (7:00) они запускают команду:
restoresnapshot.cmd
что бы этот снепшоп использовать
Т.е для меня самое интересное пропущено, каким образом эти снепшоты делаются и как потом восстанавливаются
>>Резервное копирование и восстановление
Я правильно понимаю, что раньше нужно было создать Snapshot и потом можно было восстановится из этого снепшота.
А теперь это оформлено в другой проекции и можно создать православный бекап, который по сути этот же Snapshot?
Мне кажется, если вы создаете кластерный индекс по
[oper_date], то никаких других Constraint создавать уже не нужноА как назвать изменение текста статьи, путем удаления всего что было написано?
Оригинальный пост, который был удален автором
Жаль, что автор удалил эти сообщения. Мне кажется он очень эмоционально реагирует на ту непростую ситуацию в которую мы все сейчас разворачивается вокруг нас. Тем не мение мне кажется не правильно переносить политику в программирование, и подобные статьи должны жить дальше, тем более, что рукописи не горят...
https://web.archive.org/web/20201004042530/https://habr.com/ru/post/315142/