У меня версия 5.1.178. А какая у Вас стоит? Может билд от "30 декабря", то и причина всех проблем :)
Как вариант, можно и на саппорт им написать… народ за все время адекватно мои реквесты обрабатывал.
Просмотрел Ваши запросы. Не знаю уместно ли, но много лишнего кода. Например:
DECLARE @consumers_report_columns TABLE (column_id INT)
INSERT INTO @consumers_report_columns (column_id)
SELECT rc.column_id
FROM consumers_report_columns rc
WHERE rc.consumer_id = @ConsumerId
DECLARE consumers_report_columns_cursor CURSOR
FOR
SELECT rc.column_id
FROM @consumers_report_columns rc
можно упростить до:
DECLARE consumers_report_columns_cursor CURSOR LOCAL READ_ONLY
FOR
SELECT column_id
FROM dbo.consumers_report_columns
WHERE consumer_id = @ConsumerId
Также немного смутили комментарии:
--освобождаем оперативную память
DELETE @consumers_report_columns
Что временные таблицы, что табличные переменные — все хранится в tempdb. А то что будет оно в BufferPool или нет… это как повезет. Единственная гарантия (из известных мне), что данные в табличной переменной будут в памяти — использовать InMemory:
USE test
GO
ALTER DATABASE test
ADD FILEGROUP test_mem CONTAINS MEMORY_OPTIMIZED_DATA
ALTER DATABASE test
ADD FILE (name='test_mem', filename='D:\test_mem') TO FILEGROUP test_mem
GO
CREATE TYPE dbo.ListInt AS TABLE (
ID INT NOT NULL,
INDEX Type_IX_ID HASH (ID) WITH (BUCKET_COUNT = 1000)
)
WITH (MEMORY_OPTIMIZED = ON)
GO
DECLARE @a dbo.ListInt
INSERT INTO @a VALUES (1)
SELECT * FROM @a
Код я писал в dbForge Studio, у этого IDE самый лучший форматировщик исходников (это единственный плюс этого IDE), но у меня он не настроен, поэтому форматирование выполнено в ручную
Функционал форматирования у них действительно классный, но то что не он настроен – это поправимо. Недавно разработчикам я уже выслал свои настройки, которые как они мне сказали «включат как дефолтные в следующем релизе». Позавчера они их на сайте выложили… Поэтому для нетерпеливых публикую ссылки: мой стиль форматирования, стиль форматирования «под SQL Prompt».
Относительно «единственного плюса» не согласен. У них хороший функционал есть для анализа плана выполнения (которым я пользуюсь попеременно с Plan Explorer), дата и схема компараторы. Но самое главное – IntelliSense, который взят от SQL Complete, которым я пользуюсь не один год. И возвращаться обратно на промпт банально нет желания...
Новость безусловно очень хорошая, но более чем уверен, что реализация будет не ахти. В последнее время Microsoft вообще научилась хорошо обламывать пользователей. Например, на днях анонсировали SQL Server 2016 RC0, которого я ждал. Но вот незадача… поставить его можно только на новые версии ОС: 8.1 и 10-ку. При этом сделали это намеренно, чтобы народ мигрировал с 7-ки.
Перед тем как выкладывать пост у авторов PVS Studio попросил разрешение. К слову будет сказано, что данная картинка у них была одной из первых подобного рода :)
Надеялся увидеть логически законченное решение… Видимо не судьба.
Из личного опыта скажу, что такие вот динамические движки в преоблажающем большинстве случаев ушербны с точки зрения перфоманса.
Просто дополню Ваш комментарий. Лицензии на ядра добавили начиная с 2012 версии. StackOverflow долгое время крутился на SQL Server 2008. Сейчас они используютSQL Server 2014 (мигрировали на него еще в 2013 когда был доступен CTP).
И автоматическое усечение не влияет на производительность?
Усечение не влияет на производительность.
Влияет… опять же не всегда и везде! Поэтому может не стоит быть таким категоричным. Вашу статью будут читать в дальнейшем и такие комментарии начинающими могут быть восприняты буквально.
SET NOCOUNT ON;
USE [master]
GO
IF DB_ID('shrink') IS NOT NULL BEGIN
ALTER DATABASE [shrink] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DROP DATABASE [shrink]
END
GO
CREATE DATABASE [shrink]
ON
PRIMARY (NAME = shrink_data, FILENAME = N'D:\shrink_data.mdf', SIZE = 25MB, MAXSIZE = 200MB, FILEGROWTH = 10%)
LOG ON (NAME = shrink_log, FILENAME = N'D:\shrink_log.ldf', SIZE = 3MB, MAXSIZE = 200MB, FILEGROWTH = 10%)
GO
ALTER DATABASE [shrink] SET RECOVERY SIMPLE
USE [shrink]
GO
CREATE TABLE dbo.tbl (
c1 INT IDENTITY CONSTRAINT pk PRIMARY KEY NONCLUSTERED
, c2 CHAR(3000) DEFAULT 'дефолтный бред'
)
GO
DECLARE @i INT = 1
WHILE @i <= 40000 BEGIN
INSERT INTO dbo.tbl DEFAULT VALUES
IF @i % 500 = 0 CHECKPOINT
SET @i += 1
END
GO
DECLARE @i INT = 1
WHILE @i <= 20000 BEGIN
DELETE FROM dbo.tbl WHERE c1 = @i
IF @i % 500 = 0 CHECKPOINT
SET @i += 1
END
GO
CHECKPOINT
GO
SELECT name, size * 8192 / 1048576
FROM sysfiles
GO
DBCC SHRINKFILE(shrink_data, 40) WITH NO_INFOMSGS
GO
SELECT name, size * 8192 / 1048576
FROM sysfiles
name
---------------- -----------
shrink_data 81
shrink_log 10
FULL:
SET NOCOUNT ON;
USE [master]
GO
IF DB_ID('shrink') IS NOT NULL BEGIN
ALTER DATABASE [shrink] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DROP DATABASE [shrink]
END
GO
CREATE DATABASE [shrink]
ON
PRIMARY (NAME = shrink_data, FILENAME = N'D:\shrink_data.mdf', SIZE = 25MB, MAXSIZE = 200MB, FILEGROWTH = 10%)
LOG ON (NAME = shrink_log, FILENAME = N'D:\shrink_log.ldf', SIZE = 3MB, MAXSIZE = 200MB, FILEGROWTH = 10%)
GO
ALTER DATABASE [shrink] SET RECOVERY FULL
BACKUP DATABASE [shrink] TO DISK = 'NUL'
USE [shrink]
GO
CREATE TABLE dbo.tbl (
c1 INT IDENTITY CONSTRAINT pk PRIMARY KEY NONCLUSTERED
, c2 CHAR(3000) DEFAULT 'дефолтный бред'
)
GO
DECLARE @i INT = 1
WHILE @i <= 40000 BEGIN
INSERT INTO dbo.tbl DEFAULT VALUES
IF @i % 500 = 0
BACKUP LOG [shrink] TO DISK = 'NUL'
SET @i += 1
END
GO
DECLARE @i INT = 1
WHILE @i <= 20000 BEGIN
DELETE FROM dbo.tbl WHERE c1 = @i
IF @i % 500 = 0
BACKUP LOG [shrink] TO DISK = 'NUL'
SET @i += 1
END
GO
BACKUP LOG [shrink] TO DISK = 'NUL'
GO
SELECT name, size * 8192 / 1048576
FROM sysfiles
GO
DBCC SHRINKFILE(shrink_data, 40) WITH NO_INFOMSGS
GO
SELECT name, size * 8192 / 1048576
FROM sysfiles
Итого: При FULL модели восстановления видим, что лог используется более интенсивно (10 метров против 146).
Но рекомендация разносить базу и журнал на разные диски все равно актуальна так?
Мало дисков не бывает. Если есть возможность, то разносите и радуйтесь жизни :)
И автоматическое усечение не влияет на производительность?
Очень сильно влияет. Увеличивает фрагментацию файлов базы, увеличивает фрагментацию индексов, много ресурсов тратиться на последующий AutoGrow. Почитайте при случае Auto Shrink Events.
Как вариант, можно и на саппорт им написать… народ за все время адекватно мои реквесты обрабатывал.
можно упростить до:
Также немного смутили комментарии:
Что временные таблицы, что табличные переменные — все хранится в tempdb. А то что будет оно в BufferPool или нет… это как повезет. Единственная гарантия (из известных мне), что данные в табличной переменной будут в памяти — использовать InMemory:
Функционал форматирования у них действительно классный, но то что не он настроен – это поправимо. Недавно разработчикам я уже выслал свои настройки, которые как они мне сказали «включат как дефолтные в следующем релизе». Позавчера они их на сайте выложили… Поэтому для нетерпеливых публикую ссылки: мой стиль форматирования, стиль форматирования «под SQL Prompt».
Относительно «единственного плюса» не согласен. У них хороший функционал есть для анализа плана выполнения (которым я пользуюсь попеременно с Plan Explorer), дата и схема компараторы. Но самое главное – IntelliSense, который взят от SQL Complete, которым я пользуюсь не один год. И возвращаться обратно на промпт банально нет желания...
Во-первых, это бесплатный плагин для SSMS — SQL Code Guard:
Второй это отдельный компонент T-SQL Analyzer, который работает в рамках dbForge Studio:
И последний это SQL Enlight For SSMS
Надеялся увидеть логически законченное решение… Видимо не судьба.
Из личного опыта скажу, что такие вот динамические движки в преоблажающем большинстве случаев ушербны с точки зрения перфоманса.
«Если Вы включаете AUTO_SHRINK на продакшене, то где-то в страшных муках умирает котенок...» об этом тоже нужно помнить :)
Влияет… опять же не всегда и везде! Поэтому может не стоит быть таким категоричным. Вашу статью будут читать в дальнейшем и такие комментарии начинающими могут быть восприняты буквально.
До шринка файла данных:
После шринка:
FULL:
До шринка:
После:
Итого: При FULL модели восстановления видим, что лог используется более интенсивно (10 метров против 146).
Мало дисков не бывает. Если есть возможность, то разносите и радуйтесь жизни :)
Очень сильно влияет. Увеличивает фрагментацию файлов базы, увеличивает фрагментацию индексов, много ресурсов тратиться на последующий AutoGrow. Почитайте при случае Auto Shrink Events.