• Ваш скрипт, обслуживающий индексы, измеряет не то, что надо
    +1
    Вставлю свои пару копеек. Анализировать значение avg_page_space_used_in_percent правильно, но на практике получать достаточно затратно с точки зрения ресурсов — это приводит к полному (или частичному в некоторых частных случаях) сканированию выбранного индекса. Кроме того, одно дело, когда человек вызывает точечно dm_db_index_physical_stats указывая точно какой индекс, другое дело сканить всю базу (которая может не один терабайт весить).

    Можно немного посмотреть с другой стороны… залесть в sys.allocation_units и если есть большое расхождение между total_pages и used_pages, то это потенциальный кандидат для ребилда.

    За опросник слезу пустил ​:)​ когда увидел кого перечислили в сторонних решениях. Честно рад что моим тулом пользуются.
  • Тёмная сторона SQL Server In-Memory OLTP
    +1
    Спасибо за пост. Реально полезно. Никогда не доводилось In-Memory с FULL моделью восстановления использовать, а то что на SIMPLE было так сильно не приводило к росту In-Memory файловой группы, но ее легко не фринкнуть и это большая проблема.

    И докину еще одну проблему с которой столкнулся давно (сейчас не знаю исправили или нет, но было до 2016 SP2) когда таблица In-Memory обернута в Native Compile хранимку то если нет плана выполенения… план генерируется но сам запрос падает по ошибке. Повторный запрос выполняется корректно потому что план уже в кеше. И когда памяти не хватало было весьма занимательно разбираться почему отваливались транзакции в рамках таких вот конструкций.
  • SQL Index Manager — бесплатный тул для дефрагментации и обслуживания индексов
    0
    Если по правде я потерял нить повествования о том с какой проблемой вы боритесь. Открывается соединение выбирается база в рамках базы высканиваются все индексы требующие обслуживания проставляются чекбоксы напротив тех индексов которые нужно запроцессать и становится доступна кнопка по их обслуживаниваю. Не понимаю сути вашей ситуации и в чем сложность.
  • SQL Index Manager — бесплатный тул для дефрагментации и обслуживания индексов
    0
    Откройте пожалуйста инструкцию там все показано на картинках. Спасибо
  • SQL Index Manager — бесплатный тул для дефрагментации и обслуживания индексов
    0
    Обратите внимание что вам нужно выбрать те индексы которые хотите обслужить (чекбоксы слева) и только потом кнопка будет доступна. Либо я не понял вашего вопроса. Если что есть инструкция.
  • Напильник и щепотка фантазии… или как слепить Enterprise из SQL Server Express Edition
    +2
    Касательно ограничений колумнсторов и In-Memory стало интересно и потестировал:

    Скрипт создания базы
    USE [master]
    GO
    
    SET NOCOUNT ON
    SET STATISTICS IO, TIME OFF
    
    IF DB_ID('express') IS NOT NULL BEGIN
        ALTER DATABASE [express] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
        DROP DATABASE [express]
    END
    GO
    
    CREATE DATABASE [express]
    ON PRIMARY (NAME = N'express', FILENAME = N'D:\express.mdf', SIZE = 200 MB, FILEGROWTH = 100 MB)
        LOG ON (NAME = N'express_log', FILENAME = N'D:\express_log.ldf', SIZE = 200 MB, FILEGROWTH = 100 MB)
    
    ALTER DATABASE [express] SET AUTO_CLOSE OFF
    ALTER DATABASE [express] SET RECOVERY SIMPLE
    ALTER DATABASE [express] SET MULTI_USER
    ALTER DATABASE [express] SET DELAYED_DURABILITY = ALLOWED
    ALTER DATABASE [express] ADD FILEGROUP [MEM] CONTAINS MEMORY_OPTIMIZED_DATA
    ALTER DATABASE [express] ADD FILE (NAME = 'MEM', FILENAME = 'D:\MEM') TO FILEGROUP [MEM]
    ALTER DATABASE [express] SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT = ON
    GO 
    
    USE [express]
    GO
    
    DROP TABLE IF EXISTS [CCL]
    CREATE TABLE [CCL] (
          [INT]      INT NOT NULL
        , [VARCHAR]  VARCHAR(100) NOT NULL
        , [DATETIME] DATETIME NOT NULL
    )
    GO
    CREATE CLUSTERED COLUMNSTORE INDEX IX ON [CCL] WITH (DATA_COMPRESSION = COLUMNSTORE)
    GO
    
    DECLARE @i INT = 0
    
    lbl:
        ;WITH E1(N) AS (SELECT * FROM (VALUES (1),(1),(1),(1),(1),(1),(1),(1),(1),(1)) t(N))
            , E2(N) AS (SELECT '1' FROM E1 a, E1 b)
            , E4(N) AS (SELECT '1' FROM E2 a, E2 b)
            , E8(N) AS (SELECT '1' FROM E4 a, E4 b)
        INSERT INTO [CCL] WITH(TABLOCK) ([INT], [VARCHAR], [DATETIME])
        SELECT TOP(5000000)
              ROW_NUMBER() OVER (ORDER BY 1/0)
            , CAST(ROW_NUMBER() OVER (ORDER BY 1/0) AS VARCHAR(100))
            , DATEADD(DAY, ROW_NUMBER() OVER (ORDER BY 1/0) % 100, '20180101')
        FROM E8
    
        SET @i += 1
    
    IF @i < 20 GOTO lbl
    
    SELECT 'DATA', CAST(SUM(size_in_bytes) / (1024. * 1024) AS DECIMAL(18,2))
    FROM sys.indexes i
    CROSS APPLY sys.fn_column_store_row_groups(i.[object_id]) s
    WHERE i.[type] IN (5, 6)
    
    UNION ALL
    
    SELECT 'DICT', CAST(SUM(on_disk_size) / (1024. * 1024) AS DECIMAL(18,2))
    FROM sys.column_store_dictionaries
    GO
    
    DROP TABLE IF EXISTS [MEM]
    CREATE TABLE [MEM] (A INT PRIMARY KEY NONCLUSTERED, B DATETIME INDEX IX2 NONCLUSTERED, C VARCHAR(4000))
        WITH (MEMORY_OPTIMIZED = ON, DURABILITY = SCHEMA_ONLY)
    GO
    
    DECLARE @i INT
          , @s DATETIME
          , @runs INT = 10
    
    SELECT @i = 1, @s = GETDATE()
    WHILE @i <= @runs BEGIN
    
        ;WITH E1(N) AS (SELECT * FROM (VALUES (1),(1),(1),(1),(1),(1),(1),(1),(1),(1)) t(N))
            , E2(N) AS (SELECT '1' FROM E1 a, E1 b)
            , E4(N) AS (SELECT '1' FROM E2 a, E2 b)
            , E8(N) AS (SELECT '1' FROM E4 a, E4 b)
        INSERT INTO [MEM] ([A], [B], [C])
        SELECT TOP(500000)
              ROW_NUMBER() OVER (ORDER BY 1/0) + (@i * 1000000)
            , GETDATE()
            , NEWID()
        FROM E8
    
        SET @i += 1
    END
    
    SELECT *
    FROM sys.dm_db_xtp_table_memory_stats
    


    Если говорить о колумнсторах, то там размер данных и словарей может превышать 350Мб:

    ---- ----------
    DATA 509.02
    DICT 1072.04
    

    При этом для In-Memory таблиц при превышении размера в 350Мб получаем такую ошибку:

    Msg 41823, Level 16, State 109, Line 85
    Could not perform the operation because the database has reached its quota for in-memory tables. This error may be transient. Please retry the operation. See 'http://go.microsoft.com/fwlink/?LinkID=623028' for more information.
  • Напильник и щепотка фантазии… или как слепить Enterprise из SQL Server Express Edition
    +1
    К слову было бы интересно потестировать In-Memory таблицы с SCHEMA_ONLY в условиях нехватки памяти. Скажем, что будет если превышается предел в 350Мб
  • Напильник и щепотка фантазии… или как слепить Enterprise из SQL Server Express Edition
    +1
    Я немного противник обновлений, но это не говорит что я категорически против их. Просто они должны настояться как хорошее вино, чтобы был видел эффект от их использования сообществом. Очень хорошо помогает этот сайт.
  • Напильник и щепотка фантазии… или как слепить Enterprise из SQL Server Express Edition
    +1
    Могу узнать почему? Скажем с моей стороны, мнение крайне положительное – теперь всю разработку можно вести проще с единой структурой базы данных.
  • Напильник и щепотка фантазии… или как слепить Enterprise из SQL Server Express Edition
    +1
    Ещё бы добавить сценарий как разделяют большую базу данных на маленькие в Express, т к есть ограничения на размеры (много БД и одна с представлениями, в которой объединяются все нужные таблицы из всех малых БД)

    Это в статье есть. Привел пример вертикального шардирования в рамках одного инстанса.

    также как происходит поддержка всего этого

    Увы тут быстрого ответа не выйдет — все зависит от ситуации. Например, всякие там AlwaysOn на Express Edition не сделаешь. С другой стороны, что мешает перевести базу в Full Recovery делать бекапы лога и их через PowerShell разворачивать на другом сервере для копии этой базы в режиме Read-Only. Не скажу что идеально, но дешевый аналог отказоустойчивости под репортную нагрузку себя оправдывает.

    Также рекомендую скрипты и длинные выводы по ним вложить в спойлеры

    Сделаем, но чуть позже. Увы сейчас редактор встроенный сильно тормозит потому правка статьи дело не из легких.
  • Сравнение компараторов для синхронизации схем и данных баз данных MS SQL Server
    +1
    Спасибо за обозр. А касательно скорости работы? Багам? Например ApexSQL я бы сказал что сильно бажливый.
  • Обновление статистики на secondary репликах Availability Group
    +1
    Чтиво супер зашло )) мое уважение за перевод.
  • Обзор бесплатного инструмента SQLIndexManager
    0
    Исправил много косяков в билде 1.0.0.47, поэтому если что не работает попробуйте новую версию. Описание что поменял тут. Скачать можно тут.

    Всем спасибо за отзывы.
  • Обзор бесплатного инструмента SQLIndexManager
    0
    Плюс можно будет попросить у вас скрипты которыми данные вытягиваете о которых в своем комментарии написали. Заранее спасибо.
  • Обзор бесплатного инструмента SQLIndexManager
    0
    Странно что прога работает медленнее чем ваши скрипты. Можете постучаться в личку? Скажем в телеграмм или по скайпу (в профиле линки есть). Хочется разобраться в ситуации и пофиксить если это реально косяк с моей стороны.
  • Обзор бесплатного инструмента SQLIndexManager
    +1
    Если обрывы будут постоянными до 35 сек каждую минуту?

    Тут as design. Если обрывается соединение, то и запрос будет откатываться. Для таких целей есть функционал копирования сгенерированного скрипта и его запуск со стороны сервака.
  • Обзор бесплатного инструмента SQLIndexManager
    +1
    так что цель данной программы не очень понятна

    Цель предоставить функционал, а то как ним пользоваться уже дело пользователя. Зачастую ребилд индексов и вправду смысла не имеет. А вот обновление статистики, сжатие индексов и прочии перки — это да.
  • Обзор бесплатного инструмента SQLIndexManager
    +1
    Из базы с более 1500 индексов с трудом притаскивает около сотни

    Все настройками устанавливается. По дефолту не тянутся индексы тяжелее 8Гб.

    Не говоря уже о том что считать эти индексы уходит аж несколько (5-7) минут

    Скажем за это спасибо Microsoft. Данные о фрагментации индекса не кешируется на постоянной основе, потому происходит частичный скан индекса если его нет в буффер пуле (потому ограничение по размеру и делал).

  • Обзор бесплатного инструмента SQLIndexManager
    +1
    Формально это два разных продукта. Tuning Advisor с помощью гипотетических индексов создает недостающие индексы. Второй эти индексы обслуживает.
  • Обзор бесплатного инструмента SQLIndexManager
    +1
    Ну не совсем так. Реализован механизм частичного дескрайба. То есть все тянется не одним большим запросом, а вначале получаются все мелкие индексы за раз, а потом в цикле добирается точечными запросами большие по размеру индексы (если что настраивается).
  • Обзор бесплатного инструмента SQLIndexManager
    +1
    В коде предусмотрен функционал если разрывается соединение, то команду пробуем заново выполнять. Но это не для всех запросов предусмотрено.
  • SQL Index Manager — бесплатный тул для дефрагментации и обслуживания индексов
    0
    Возможна ли дефрагментация отдельно выбранной секции секционированного индекса?

    Да. Изначально так и работает.

    Опция ONLINE учитывает редакцию SQL или всегда есть в меню, т.к. применима не на всех редакциях?

    Учитывает редакцию сиквела. И если есть возможность только тогда используется (при условии что в настройках включена).

    И на картинке есть выбор режима дефрагментации: отдельно ROW, PAGE и ONLINE, а разве не может быть ONLINE+PAGE например?

    Ограничения контрола. Увы пока исправить не могу. Возможно в будующем, когдна новую логику реализую.

  • SQL Index Manager — бесплатный тул для дефрагментации и обслуживания индексов
    0

    Что в файле *.log? Ситуаций может быть тьма. Как вариант все индексы не требуют обслуживания. Или слишком большие, что не включаются в общий список при анализе. Может быть бажина какая-то в запросе. Если покажете лог в личке, то смогу точно сказать. Ну и как вариант посмотрите на настройки свои.

  • Копание могил, SQL Server, годы аутсорса и свой первый проект
    0
    Идея хорошая, но у меня сейчас все силы на другое брошены: техническая статья о том как прога работает, публикация на английском и прочее. Чем больше народ будет тулом пользоваться тем больший фитбек я получить смогу и сделать все лучше.
  • Копание могил, SQL Server, годы аутсорса и свой первый проект
    0
    Ответ вы и так знаете )))

    Мое мнение, индексы нет особого смысла дефрагментировать – лишняя нагрузка на дисковую подсистему и процессор. А вот тот факт, что статистика обновляется за счет ребилда – это штука полезная, поэтому чаще нужно не на индексы смотреть, а на статистику. Плюс чаще всего обслуживание индексов делать нужно для сокращения занимаемого места на диске, а не для борьбы с логической фрагментацией (кучи не в счет, потому что там forwarded records — это проблема насущная).
  • Копание могил, SQL Server, годы аутсорса и свой первый проект
    0
    На это не буду отвечать. Посыл статьи в мотивации к действию и чтобы нужные люди ее прочитали.
  • Копание могил, SQL Server, годы аутсорса и свой первый проект
    +1
    Спасибо бро. Как говорил мой знакомый «от души душевно в душу». Суть идеи — наклепать полезных тулов, которых в работе мне всегда не хватало… и чтобы народ ними тоже пользовался.
  • План обслуживания «на каждый день» – Часть 1: Автоматическая дефрагментация индексов
    0
    Решил чуток обновить статью, потому что недавно сделал бесплатную тулу по обслуживанию индексов. Надеюсь она будет полезной :)

    Ссылка на исходники программы:
    github.com/sergeysyrovatchenko/SQLIndexManager

    Обсуждение нового функционала:
    www.sql.ru/forum/1312218/sql-index-manager-besplatnaya-utilita-po-obsluzhivaniu-indeksov-dlya-sql-server-i-azure
  • Поиск повреждённого объекта по номеру повреждённой страницы в MS SQL Server 2005
    0
    Все таки люблю ваши статьи читать. Спасибо за полезный материал. Чисто из любопытства не подскажите тулы самописные, которые напрямую будут из mdf / ldf данные читать?
  • Вышла Oracle Database 18c XE
    0
    Что сказать… я доволен. Разработчики Oracle последовали примеру Microsoft. Где начиная с SQL Server 2016 SP1 можно на экспрессе использовать фишки более старших версий (секционирование, колумнсторы и ин-мемори). Авось и в 2019 версии чуть уменьшат ограничения по ресурсам по примеру Oracle.
  • История про msdb размером в 42 Гб
    0
    Так сделайте усечение файла данных. SQL Server за Вас это не будет делать (если конечно одна плохая настройка не включена по дефолту). Почитайте как сделать Shrink Flies.
  • История про msdb размером в 42 Гб
    0
    Можно попробовать в следующий раз написать более медленный вариант скрипта по удалению :) но суть не поменяется. А вообще-то советую свежие обновления на машину поставить и посмотреть что и как можно сконфигурировать, чтобы все быстрее шевелилось. Например, за счет Instant File Initialization.
  • История про msdb размером в 42 Гб
    0
    Я лишь вижу, что команда отработала успешно. К тому же сервер бы не мешало обновить. Уже есть SP4, а вы все на RTM сидите.
  • История про msdb размером в 42 Гб
    0
    А что опасного? Если нет никаких блокировок на изменению схемы, то все нормально сможеть выполниться. Решите для себя нужны ли Вам эти данные. В них хранится история запуска планов обслуживания, насколько я помню. Что такое сжатие в Вашем понимании? Есть на уровне ROW, PAGE и отдельный фетиш — ColumnStore (начиная с 2014го).
  • История про msdb размером в 42 Гб
    0
    Такой вариант не помог?

    USE msdb
    GO
    
    ALTER TABLE dbo.sysmaintplan_log
        DROP CONSTRAINT FK_sysmaintplan_log_subplan_id
    ALTER TABLE dbo.sysmaintplan_logdetail
        DROP CONSTRAINT FK_sysmaintplan_log_detail_task_id
    GO
    
    TRUNCATE TABLE msdb.dbo.sysmaintplan_logdetail
    TRUNCATE TABLE msdb.dbo.sysmaintplan_log
    GO
    
    ALTER TABLE dbo.sysmaintplan_log WITH CHECK
        ADD CONSTRAINT FK_sysmaintplan_log_subplan_id
        FOREIGN KEY(subplan_id)
        REFERENCES dbo.sysmaintplan_subplans (subplan_id)
    GO
    
    ALTER TABLE dbo.sysmaintplan_logdetail WITH CHECK
        ADD CONSTRAINT FK_sysmaintplan_log_detail_task_id
        FOREIGN KEY(task_detail_id)
        REFERENCES dbo.sysmaintplan_log (task_detail_id) ON DELETE CASCADE
    GO
  • VLFs — Забытый враг
    +2
    Замедлить работу в каких сценариях? Почему? Много вещей не покрывает данная статья
  • SQL Server JSON
    +1
    Нет. За основу брал тулы от RedGate, DevArt и других коллег по цеху.
  • SQL Server JSON
    +1
    По правде, глобальная задумка сделать набор бесплатных тулов для обслуживания SQL Server, которыми сам же и буду пользоваться. Но на эту задачу требуется уж очень много времени, потому и решил начать с чего-то относительно простого — сделать тул для анализа и обслуживания индексов с учетом ошибок конкурирующих решений. А потом на основе этого клепать следующие тулы. Если будет желание поучаствовать в бета-тестировании или просто советом помочь, то буду рад.
  • Третья космическая скорость для MS SQL Server
    0
    В случае работы с логом отсутствие понимания что делает MaxParallel ничем не лучше Delayed durability. И там и там меняется поведение при работе с лог буфером. Возможно что-то другое, поэтому вслепую я бы не рискнул такое на продакшен ставить. При DW нагрузке если данные уже в памяти как Ваш продукт может ускорить запросы? А если они на диске, то опять же скорее всего используется некий аналог упреждающего чтения.

    В общем, по моему мнению, чуточку мутно. Тем более, что начиная с 2016-го сиквела добавили аппаратные приблуды, которые дешевле под OLTP нагрузку и менять в коде ничего не нужно. А для DW иногда достаточно сделать кластерный ColumnStore секционированный. Хотя буду объективным истины в чем-то одном нет. Ваш продукт возможно хорош, но нет хорошего прува с технической составляющей. Я бы ее с радостью почитал.

    С наступающими праздниками :)
  • Третья космическая скорость для MS SQL Server
    0
    Сам по себе продукт, конечно, интересный. Но технических подробностей не хватает. Вы приводили пример с множественными INSERT...UPDATE...DELETE. Это можно решить на уровне настроек базы за счёт Delayed durability начиная с 2014 версии. Либо использования ин-мемори. Начиная с 2016 SP1 этот функционал и в экспресс редакции есть, поэтому с ускорением OLTP проблем быть не должно. По правде так и не понял как Ваш продукт использовать и что он с трансляцией IO запросов сиквела делает.