Pull to refresh
98
0
Send message
У меня версия 5.1.178. А какая у Вас стоит? Может билд от "30 декабря", то и причина всех проблем :)
Как вариант, можно и на саппорт им написать… народ за все время адекватно мои реквесты обрабатывал.
Сложно так сразу ответить. Можно результаты запроса на почту (смотреть в профиле)?

SELECT
      s.[file_id]
    , file_group = d.name
    , s.name
    , size = CAST(s.size * 8. / 1024 AS DECIMAL(18,2))
    , space_used = CAST(t.space_used * 8. / 1024 AS DECIMAL(18,2))
    , free_space = CAST((s.size - t.space_used) * 8. / 1024 AS DECIMAL(18,2))
    , used_percent = CAST(t.space_used * 100. / s.size AS DECIMAL(18,2))
    , s.max_size
    , s.growth
    , s.is_percent_growth
FROM sys.database_files s
LEFT JOIN sys.data_spaces d on d.data_space_id = s.data_space_id
CROSS APPLY (
    SELECT space_used = FILEPROPERTY(s.name, 'SpaceUsed')
) t
ORDER BY d.name
Вы имеете ввиду картинку? Если да, то я ее взял у разработчиков PVS Studio.
В Report Builder когда то искал возможность добавить параметры в отчет. Не знаете такой функционал там есть вообще?
Просмотрел Ваши запросы. Не знаю уместно ли, но много лишнего кода. Например:

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, которым я пользуюсь не один год. И возвращаться обратно на промпт банально нет желания...
Увы нет… Сам давно жду. Но в данном направлении наметились изменения. Например тот же Stretch Database для SQL Server 2016.
Проверил. К сожалению нет… ни STRING_AGG, ни GROUP_CONCAT.
Новость безусловно очень хорошая, но более чем уверен, что реализация будет не ахти. В последнее время Microsoft вообще научилась хорошо обламывать пользователей. Например, на днях анонсировали SQL Server 2016 RC0, которого я ждал. Но вот незадача… поставить его можно только на новые версии ОС: 8.1 и 10-ку. При этом сделали это намеренно, чтобы народ мигрировал с 7-ки.
Знаю как минимум 3 тула, которые работаю по принципу PVS Studio, но для реалий T-SQL. Оставлю ссылки вдруг кому будет полезным:

Во-первых, это бесплатный плагин для SSMSSQL Code Guard:


Второй это отдельный компонент T-SQL Analyzer, который работает в рамках dbForge Studio:


И последний это SQL Enlight For SSMS
Перед тем как выкладывать пост у авторов PVS Studio попросил разрешение. К слову будет сказано, что данная картинка у них была одной из первых подобного рода :)
Знаю об их продукте, люблю их статьи читать… показалось что картинка будет "в тему" :)
Осталось только разработать хранимую процедуру

Надеялся увидеть логически законченное решение… Видимо не судьба.
Из личного опыта скажу, что такие вот динамические движки в преоблажающем большинстве случаев ушербны с точки зрения перфоманса.
Было бы неплохо написать какими технологиями пользовались… В каком виде реализован движок по распознаванию...
Просто дополню Ваш комментарий. Лицензии на ядра добавили начиная с 2012 версии. StackOverflow долгое время крутился на SQL Server 2008. Сейчас они используют SQL Server 2014 (мигрировали на него еще в 2013 когда был доступен CTP).
Спасибо за статью. К слову хотел скинуть ссылку на бекап базы StackOverflow. Данные там не все, но для тестирование 65Гб информации очень пригодилось.
Еще раз повторюсь. Необоснованный SHRINK на производительность влияет всегда… При любой модели восстановления.

«Если Вы включаете AUTO_SHRINK на продакшене, то где-то в страшных муках умирает котенок...» об этом тоже нужно помнить :)
И автоматическое усечение не влияет на производительность?

Усечение не влияет на производительность.

Влияет… опять же не всегда и везде! Поэтому может не стоит быть таким категоричным. Вашу статью будут читать в дальнейшем и такие комментарии начинающими могут быть восприняты буквально.
SIMPLE:

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

До шринка файла данных:

---------------- -----------
shrink_data      169
shrink_log       3

После шринка:

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

До шринка:

-------------- -----------
shrink_data    169
shrink_log     3

После:

-------------- -----------
shrink_data    81
shrink_log     146

Итого: При FULL модели восстановления видим, что лог используется более интенсивно (10 метров против 146).

Но рекомендация разносить базу и журнал на разные диски все равно актуальна так?

Мало дисков не бывает. Если есть возможность, то разносите и радуйтесь жизни :)

И автоматическое усечение не влияет на производительность?

Очень сильно влияет. Увеличивает фрагментацию файлов базы, увеличивает фрагментацию индексов, много ресурсов тратиться на последующий AutoGrow. Почитайте при случае Auto Shrink Events.
FULL модель восстановления в некоторых случаях более интенсивно использует лог файл. Полноценный пример приведу в комментарии ниже минут через 15.

Information

Rating
Does not participate
Registered
Activity