• Сравнение компараторов для синхронизации схем и данных баз данных 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 2017 JSON
    +1
    Нет. За основу брал тулы от RedGate, DevArt и других коллег по цеху.
  • SQL Server 2017 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 запросов сиквела делает.
  • Windows сервера для задач 24x7 — миф или мои «кривые руки»?
    +1
    SQL Server 2016 on Linux. Мне, как и многим, наверное, пока страшно его запускать в «промышленную эксплуатацию», но если есть у кого-то подобный опыт
    Пока ничего хорошего на Linux для SQL Server не предвидится. Вот один из простых примеров. И таких радостей, по правде, уже накапливается много. Возможно через пару кумулятивных обновлений все станет лучше, но пока что-то серьезное на SQL Server под Linux делать я бы не рискнул.

    В плане статьи, поддержу мнение, что Updater подлые вещи иногда делает. Но что мешает в момент установки все настроить? Отключить обновление, телеметрию на уровне SQL Server и системы в целом. И тогда подобных сюрпризов будет по минимуму. Опять же не берем во внимание Azure — он живет по другим правилам.
  • SQL Server 2017 JSON
    0
    Небольшое репро с использованием кластерного ColumnStore:

    SET NOCOUNT ON
    USE AdventureWorks2014 -- SQL Server 2017
    GO
    
    DROP TABLE IF EXISTS #CCI
    DROP TABLE IF EXISTS #Heap
    GO
    
    CREATE TABLE #CCI (JSON_Data NVARCHAR(4000))
    GO
    
    SELECT JSON_Data =
        (
            SELECT h.SalesOrderID
                 , h.OrderDate
                 , Product = p.[Name]
                 , d.OrderQty
                 , p.ListPrice
            FOR JSON PATH, WITHOUT_ARRAY_WRAPPER
        )
    INTO #Heap
    FROM Sales.SalesOrderHeader h
    JOIN Sales.SalesOrderDetail d ON h.SalesOrderID = d.SalesOrderID
    JOIN Production.Product p ON d.ProductID = p.ProductID
    
    INSERT INTO #CCI
    SELECT * FROM #Heap
    
    CREATE CLUSTERED COLUMNSTORE INDEX CCI ON #CCI

    SELECT o.[name], s.used_page_count / 128.
    FROM sys.indexes i
    JOIN sys.dm_db_partition_stats s ON i.[object_id] = s.[object_id]
        AND i.index_id = s.index_id
    JOIN sys.objects o ON i.[object_id] = o.[object_id]
    WHERE i.[object_id] IN (OBJECT_ID('#CCI'), OBJECT_ID('#Heap'))

    ------- -------------
    #CCI    10.687500
    #Heap   30.859375

    Режим batch для колумнстора при последовательном плане более эффективный. Параллельный план дает одинаковую производительностью с поправкой на размер данных:

    SET STATISTICS IO, TIME ON
    
    SELECT JSON_VALUE(JSON_Data, '$.OrderDate')
         , AVG(CAST(JSON_VALUE(JSON_Data, '$.ListPrice') AS MONEY))
    FROM #CCI
    GROUP BY JSON_VALUE(JSON_Data, '$.OrderDate')
    OPTION(MAXDOP 1)
    --OPTION(RECOMPILE, QUERYTRACEON 8649)
    
    SELECT JSON_VALUE(JSON_Data, '$.OrderDate')
         , AVG(CAST(JSON_VALUE(JSON_Data, '$.ListPrice') AS MONEY))
    FROM #Heap
    GROUP BY JSON_VALUE(JSON_Data, '$.OrderDate')
    OPTION(MAXDOP 1)
    --OPTION(RECOMPILE, QUERYTRACEON 8649)
    
    SET STATISTICS IO, TIME ON
    
    /*
        OPTION(MAXDOP 1)
    
        #CCI:  CPU = 516 ms,  Elapsed = 568 ms
        #Heap: CPU = 1015 ms, Elapsed = 1137 ms
    
        OPTION(RECOMPILE, QUERYTRACEON 8649)
    
        #CCI:  CPU = 531 ms,  Elapsed = 569 ms
        #Heap: CPU = 828 ms,  Elapsed = 511 ms
    */

    При использовании OPENJSON при последовательном плане различий никаких. При параллельном выполнении на моем компе чтение в batch режиме менее эффективное:

    SET STATISTICS IO, TIME ON
    
    SELECT OrderDate, AVG(ListPrice)
    FROM #CCI
    CROSS APPLY OPENJSON(JSON_Data)
        WITH (
              OrderDate DATE
            , ListPrice MONEY
        )
    GROUP BY OrderDate
    OPTION(MAXDOP 1)
    --OPTION(RECOMPILE, QUERYTRACEON 8649)
    
    SELECT OrderDate, AVG(ListPrice)
    FROM #Heap
    CROSS APPLY OPENJSON(JSON_Data)
        WITH (
              OrderDate DATE
            , ListPrice MONEY
        )
    GROUP BY OrderDate
    OPTION(MAXDOP 1)
    --OPTION(RECOMPILE, QUERYTRACEON 8649)
    
    SET STATISTICS IO, TIME OFF
    
    /*
        OPTION(MAXPOD 1)
        #CCI:  CPU = 875 ms, Elapsed = 902 ms
        #Heap: CPU = 812 ms, Elapsed = 927 ms
    
        OPTION(RECOMPILE, QUERYTRACEON 8649)
        #CCI:  CPU = 875 ms, Elapsed = 909 ms
        #Heap: CPU = 859 ms, Elapsed = 366 ms
    */

  • SQL Server 2017 JSON
    +2
    Пока что в SQL Server 2016 / 2017 не предусмотрена возможность создания индексов по аналогии с GIN. Аргументация у разработчиков примерно такая: «все и так быстро, но если не устраивает скорость, то может в следующей версии добавим». Примерно по такому принципу в SQL Server 2012 SP1 добавили селективные XML индексы.

    В тоже время, есть некоторые обходные пути как можно ускорить поиск по произвольной JSON структуре. Можно создать кластерный ColumnStore и хранить в нем JSON. При парсинге значений будет использоваться batch режим вместо построчной обработки — это даст выигрыш при парсинге. Опять же тестировал у себя данный пример и не могу сказать, что batch режим кардинально быстрее. Репро на работе нет, но смогу вечером добавить.
  • SQL Server 2017 JSON
    0
    Латентное хейтерство не приведет к улучшению качества данного поста. Можно попросить, когда минусуете написать по какой причине. Заранее спасибо.
  • Обзор инструментов для сравнения данных в PostgreSQL
    0
    Спасибо за наводку — поддержим отечественного производителя… хотя мне больше другие продукты от Devart по душе
  • Почему большие БД работают не как хочется, или про несбыточные мечты SQL-запросов
    0
    Почему минутные запросы могут работать час

    Я бы еще добавил ссылку на отличный пост от Дмитрия Пилюгина: Медленно в приложении, быстро в SSMS… про parameter sniffing и не только. А так пост годный, прочитал с удовольствием.
  • Анонс митапа Sync.NET #4 в Харькове
    0
    Значит будете на 2016-ом показывать… что ж интересно — постараюсь прийти. Ваш доклад во сколько примерно начинается?
  • Анонс митапа Sync.NET #4 в Харькове
    0
    К примеру, в MS SQL Server существует 5 разновидностей таблиц.

    Heap, Clustered index, Columnstore, InMemory… какая пятая? Internal или что-то новое? Из Вашего описания не совсем понятно, про что пойдет речь.
  • Утки, Таиланд и T-SQL… или что может подстерегать программистов при работе с SQL Server?
    0
    Оглавление добавлено… лучше поздно, чем никогда :)
  • Регламентные работы с базой данных информационной системы 24x7 в MS SQL Server
    +1
    На самом деле скорость везде примерно одинакова и зависит от свободного места в файле (будет ли AutoGrowth), включен ли IFI, скорости дисковой подсистемы (не забываем про WRITELOG) и тд.

    Если все эти факторы учесть, то вот мой тест:

    SET NOCOUNT ON
    
    IF OBJECT_ID('t1', 'U') IS NOT NULL
        DROP TABLE t1
    GO
    
    CREATE TABLE t1 (
          id INT IDENTITY (1, 1) NOT NULL PRIMARY KEY CLUSTERED
        , d CHAR(250) NOT NULL DEFAULT ''
    )
    GO
    
    DECLARE @count INT = 0
          , @dt DATETIME = GETDATE()
    WHILE @count < 500000 BEGIN
        INSERT t1 DEFAULT VALUES
        SET @count += 1
    END
    SELECT DATEDIFF(MILLISECOND, @dt, GETDATE()) -- 23 second
    GO
    
    CHECKPOINT
    
    IF OBJECT_ID('t2', 'U') IS NOT NULL
        DROP TABLE t2
    GO
    
    CREATE TABLE t2 (
          id UNIQUEIDENTIFIER DEFAULT NEWID() NOT NULL PRIMARY KEY CLUSTERED
        , d CHAR(250) NOT NULL DEFAULT ''
    )
    GO
    
    DECLARE @count INT = 0
          , @dt DATETIME = GETDATE()
    WHILE @count < 500000 BEGIN
        INSERT t2 DEFAULT VALUES
        SET @count += 1
    END
    SELECT DATEDIFF(MILLISECOND, @dt, GETDATE()) -- 23 second
    GO
    
    CHECKPOINT
    
    IF OBJECT_ID('t3', 'U') IS NOT NULL
        DROP TABLE t3
    GO
    
    CREATE TABLE t3 (
          id UNIQUEIDENTIFIER DEFAULT NEWSEQUENTIALID() NOT NULL PRIMARY KEY CLUSTERED
        , d CHAR(250) NOT NULL DEFAULT ''
    )
    GO
    
    DECLARE @count INT = 0
          , @dt DATETIME = GETDATE()
    WHILE @count < 500000 BEGIN
        INSERT t3 DEFAULT VALUES
        SET @count += 1
    END
    SELECT DATEDIFF(MILLISECOND, @dt, GETDATE()) -- 23 second
    GO
    
    CHECKPOINT
    GO
    
    SELECT t.[name]
         , size
         , s.avg_fragmentation_in_percent
         , s.avg_page_space_used_in_percent
    FROM sys.objects t
    JOIN (
        SELECT p.[object_id]
             , size = SUM(a.total_pages) * 8. / 1024
        FROM sys.partitions p
        JOIN sys.allocation_units a ON p.[partition_id] = a.container_id
        GROUP BY p.[object_id]
    ) i ON t.[object_id] = i.[object_id]
    CROSS APPLY sys.dm_db_index_physical_stats(DB_ID(), i.[object_id], NULL, NULL, 'DETAILED') s
    WHERE t.is_ms_shipped = 0
        AND i.[object_id] > 255
        AND t.[type] = 'U'
        AND s.index_level = 0
    

    Скорость выполнения в миллисекундах:

    -------- -----------
    t1       24080
    t2       24256
    t3       22280
    

    Ожидания:

    name     wait_type               wait_time   wait_resource    wait_signal
    -------- ----------------------- ----------- ---------------- ------------
    t1       WRITELOG                8.8480      6.7930           2.0550
    t2       WRITELOG                8.9310      6.9120           2.0190
    t3       WRITELOG                8.2180      6.2340           1.9840
    

    И самое интересное (так в чем же различие):

    name     size          avg_fragmentation_in_percent avg_page_space_used_in_percent
    -------- ------------- ---------------------------- ------------------------------
    t1       130.757812    0,365992680146397            97,4529651593773
    t2       197.320312    99,0648999243962             67,572658759575
    t3       135.632812    0,666975988864401            98,5015196441809
    

    А то, что в случае использования NEWID() у нас будут чаще происходить операции разбиения страниц, соответственно и фрагментация будет выше (оттого больше логических чтений при работе с этой таблицей).

    Кроме того, в этот пост еще хорош для ознакомления Первичный ключ – GUID или автоинкремент?

    Если короче, то в общем поддерживаю точку зрения BalinTomsk