Чи добре видалити MSDB?

Я не DBA, я лише гугл, що робить MSDB, це в основному БД агента SQL своєї роботи та історії, тепер у мене на хмарному сервері не вистачає місця, і в мене MSDB рік 1 рік вартій , Чи добре це видалити чи зберігати його для резервного копіювання?

Мій MSDB є 93 Гб на 250 ГБ жорсткому диску.

Ви не можете скинути msdbбазу даних, як зазначено в документах (міна акцентів):

Обмеження

У базі даних msdb такі операції неможливо виконати:

• Зміна порівняння. За замовчуванням порівняння - це порівняння сервера.

• Видалення бази даних.

• Видалення гостя користувача з бази даних.

• Увімкнення зміни даних.

• Участь у дзеркальному відображенні бази даних.

• Видалення первинної групи файлів, основного файлу даних або журналу.

• Перейменування бази даних або первинної групи файлів.

• Встановлення бази даних на OFFLINE.

• Встановлення основної групи файлів READ_ONLY.

Нарушення системних баз даних зазвичай не є хорошою ідеєю. Ви повинні перевірити, де ваша космічна проблема, і розглянути можливість розширення ваших накопичувачів.

Щоб перевірити, де проблема з розміром:

• Перевірте розміри таблиці та індексу всередині msdbбази даних за допомогою цього запиту:

  USE msdb
  GO
  
  SELECT 
      t.NAME AS TableName,
      s.Name AS SchemaName,
      p.rows AS RowCounts,
      SUM(a.total_pages) * 8 AS TotalSpaceKB, 
      CAST(ROUND(((SUM(a.total_pages) * 8) / 1024.00), 2) AS NUMERIC(36, 2)) AS TotalSpaceMB,
      SUM(a.used_pages) * 8 AS UsedSpaceKB, 
      CAST(ROUND(((SUM(a.used_pages) * 8) / 1024.00), 2) AS NUMERIC(36, 2)) AS UsedSpaceMB, 
      (SUM(a.total_pages) - SUM(a.used_pages)) * 8 AS UnusedSpaceKB,
      CAST(ROUND(((SUM(a.total_pages) - SUM(a.used_pages)) * 8) / 1024.00, 2) AS NUMERIC(36, 2)) AS UnusedSpaceMB
  FROM 
      sys.tables t
  INNER JOIN      
      sys.indexes i ON t.OBJECT_ID = i.object_id
  INNER JOIN 
      sys.partitions p ON i.object_id = p.OBJECT_ID AND i.index_id = p.index_id
  INNER JOIN 
      sys.allocation_units a ON p.partition_id = a.container_id
  LEFT OUTER JOIN 
      sys.schemas s ON t.schema_id = s.schema_id
  GROUP BY 
      t.Name, s.Name, p.Rows
  ORDER BY 
      TotalSpaceMB DESC

  Якщо sysjobhistoryз'являється простір, перегляньте поточну політику зберігання історії роботи і переконайтесь, що графіки ваших завдань перевіряються і не спрацьовують частіше, ніж потрібно.

• Перевірте дані бази даних та розміри файлів журналу за допомогою цього запиту:

  ;with fs
  as
  (
      select database_id, type, size * 8.0 / 1024 size
      from sys.master_files
  )
  select
      name,
      (select sum(size) from fs where type = 0 and fs.database_id = db.database_id) DataFileSizeInMB,
      (select sum(size) from fs where type = 1 and fs.database_id = db.database_id) LogFileSizeInMB
  from 
      sys.databases db
  where
      db.name = 'msdb'

  Якщо розмір файлу журналу великий, вам потрібно з’ясувати, яка операція змусила його збільшити розмір і усунути неполадки. Скорочення файлу звільнить простір, але не вирішить основної проблеми.

Як описано в інших відповідях тут, не намагайтеся видалити всю базу даних msdb.

Ви можете скинути певні записи історії, які зберігаються в базі даних msdb, а потім зменшити базу даних, якщо вам потрібно заощадити місце. Будьте в курсі, я не раджу вам це робити, оскільки база даних, безумовно, потребуватиме знову зростати, якщо ви не ретельно керуєте простором, що використовується MSDB на постійній основі.

Ви можете видалити історію з бази даних msdb за допомогою цих збережених процедур:

USE msdb;
EXEC dbo.sp_delete_backuphistory @oldest_date = '2018-01-01T00:00:00';
EXEC dbo.sp_purge_jobhistory @job_name = NULL
    , @job_id = NULL
    , @oldest_date = '2018-01-01T00:00:00';

Щоб зменшити msdb, ви можете скористатися цим:

USE msdb;

DBCC SHRINKFILE (MSDBData, 0);
DBCC SHRINKFILE (MSDBLog, 0);

Вищеописані операції спробують зменшити файли msdb та файли журналів до мінімально можливого розміру. Для файлу журналу "найменший можливий розмір" обмежений останнім виділеним віртуальним файлом журналу.

FYI, ви можете побачити, скільки місця витрачається в базі даних, виконавши наступний код:

USE <database_name>;

DECLARE @Schema sysname;
DECLARE @Table sysname;
DECLARE @DSName sysname;

--if you're interested in a subset of the objects in a database,
--specify that subset by modifying these variables.  @DSName is
--the name of a filegroup, or possibly a partition.
SET @Schema = NULL;
SET @Table = NULL;
SET @DSName = NULL;

SELECT DataSpace = ds.name
    , ObjectName = QUOTENAME(s.name) + '.' + QUOTENAME(o.name)
    , IndexName = i.name
    , IndexType = i.type_desc
    --, total_pages
    --, used_pages
    --, data_pages
    , TotalMB = CONVERT(INT, total_pages * 8192E0 / 1048576)
    , UsedMB = CONVERT(INT, used_pages * 8192E0 / 1048576)
    , DataMB = CONVERT(INT, data_pages * 8192E0 / 1048576)
    , [rows]
    --, i.*
FROM sys.allocation_units au
    INNER JOIN sys.data_spaces ds ON au.data_space_id = ds.data_space_id
    INNER JOIN sys.partitions p ON (au.container_id = p.hobt_id AND (au.type = 1 OR au.type = 3)) OR (au.container_id = p.partition_id AND au.type = 2)
    INNER JOIN sys.indexes i ON p.index_id = i.index_id AND p.object_id = i.object_id
    INNER JOIN sys.objects o ON p.object_id = o.object_id
    INNER JOIN sys.schemas s ON o.schema_id = s.schema_id
WHERE /*o.is_ms_shipped = 0
    AND total_pages > 128
    AND */(ds.name = @DSName OR @DSName IS NULL)
    AND (s.name = @Schema OR @Schema IS NULL)
    AND (o.name = @Table OR @Table IS NULL)
ORDER BY ds.name, o.name, i.name

Відповідно до документації щодо блогу Microsoft, тут MSDB є важливою системною базою даних на сервері Microsoft SQL. База даних msdb в основному використовується агентом SQL Server для зберігання системних дій, таких як завдання сервера sql, пошта, сервіс-брокер, плани обслуговування, історія резервного копіювання баз даних користувачів та систем тощо. Також використовується двигуном бази даних та студією управління.

Існують певні DMLІ DDLоперації, які неможливо виконати в MSDBБазі даних, наприклад:

1. Ми не можемо скинути таблиці з цієї бази даних.
2. We cannot drop this database.
3. Ми не можемо змусити цю системну базу даних працювати off-line.
4. Ми не можемо робити базу даних mirroringна цій базі даних.
5. Ми не можемо назвати renameцю базу даних. тощо ...