Постійне вилучення бази даних

Якщо база даних постійно відлучається від екземпляра, чи є якісь завдання очищення, які слід виконати?

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

Я пропоную зробити остаточне резервне копіювання бази даних після того, як ви переведете його в режим лише для читання (оскільки це забезпечить відсутність активності під час створення резервної копії), після чого видаліть її з системи за допомогою команди Drop Database .

Повний набір команд буде виглядати приблизно так:

-- Use master db to ensure you don't have an active connection to the db you wish to affect
USE [master]
GO

-- This will kill any active transactions, but will force the database into a Read-Only state
ALTER DATABASE [db_name] SET READ_ONLY WITH ROLLBACK IMMEDIATE
GO

BACKUP DATABASE [db_name] -- Fill in more options here or use the UI to take a backup if you chooose
GO

-- This will kick out all connections from the database allowing you to drop it.
ALTER DATABASE [db_name] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO

-- Drop the database (which automatically removes the files from the OS)
DROP DATABASE [db_name]
GO

Після цього ви захочете шукати будь-які вакансії, які виконували сценарії проти бази даних. Я б запропонував вам просто зачекати, щоб побачити, що не вдалося (після чого ви можете сканувати сценарій / видалити завдання), оскільки існує чимало способів роботи можуть посилатися на базу даних (не всі з них легко визначити).

Нарешті, ви захочете видалити будь-яких користувачів із примірника, який мав доступ лише до цієї бази даних. Цей сценарій повинен визначати, хто такі користувачі, хоча версія Макса набагато чистіша (я не усвідомлював, що він розмістив підхід до того моменту, як я відредагував свою відповідь, щоб включити це):

DECLARE @ExecString NVARCHAR (4000)

-- Create Empty Table in a very lazy manner
SELECT  name, principal_id, CAST('' AS NVARCHAR(128)) as database_name
INTO ##tmp_AllDBUsers
FROM sys.server_principals
WHERE 1 = 2

-- Declare Cursor to iterate through all DBs on the instance
DECLARE dbCursor CURSOR
FOR
        SELECT name
        FROM sys .databases


DECLARE @name NVARCHAR (128)
OPEN dbCursor
FETCH NEXT FROM dbCursor
INTO @name

WHILE @@FETCH_STATUS = 0
BEGIN

    SET @ExecString = 
    'USE [' + @name + '];
    INSERT INTO ##tmp_AllDBUsers
    SELECT sp.name, sp.principal_id, DB_NAME()
    FROM sys.server_principals sp INNER JOIN sys.database_principals dp
        ON sp.sid = dp.sid'

    EXEC(@ExecString)

    FETCH NEXT FROM dbCursor
    INTO @name
END

-- Close and deallocate the cursor because you've finished traversing all it's data
CLOSE dbCursor
DEALLOCATE dbCursor

-- Show all logins that do not belong to a server-level role nor have access to any databases
SELECT sp.*
FROM sys.server_principals sp LEFT JOIN ##tmp_AllDBUsers adu
    ON sp.principal_id = adu.principal_id
WHERE adu.principal_id IS NULL
    AND sp.principal_id NOT IN (SELECT member_principal_id
                            FROM sys.server_role_members)
    AND TYPE IN ('S', 'U', 'G')

-- cleanup
DROP TABLE ##tmp_AllDBUsers

Я підтримав відповідь Джона; Я просто хотів би додати детальну інформацію про інші предмети, які ви хочете почистити.

1. Завдання та сповіщення агента SQL Server можуть посилатися на базу даних. Почищення їх не дозволить повідомити про непотрібні помилки.

2. Видаліть усі логіни, створені спеціально для бази даних. Наступний T-SQL визначає можливі входи-кандидати, які ви можете дослідити, щоб перевірити, чи використовуються вони. Код ідентифікує входи, на які не посилається жодна база даних.

   DECLARE @cmd nvarchar(max);
   SET @cmd = '    SELECT sp.sid
       FROM master.sys.server_principals sp
   ';
   SELECT @cmd = @cmd + '  EXCEPT 
       SELECT dp.sid
       FROM ' + QUOTENAME(d.name) + '.sys.database_principals dp
   '
   FROM sys.databases d
   WHERE d.[state] <> 6; --ignore offline DBs
   
   SET @cmd = 'SELECT spr.*
   FROM (
   ' + @cmd + '
   ) src
       INNER JOIN master.sys.server_principals spr
           ON src.sid = spr.sid
   WHERE spr.type <> ''R''
       AND spr.name NOT LIKE ''%##MS_%''
       AND spr.name NOT LIKE ''NT %''
       AND NOT EXISTS (
           SELECT 1
           FROM sys.server_role_members srm
           WHERE srm.member_principal_id = spr.principal_id
               )
   ORDER BY spr.name;
   ';
   EXEC sys.sp_executesql @cmd;

3. Для цієї бази даних можуть існувати резервні пристрої. Хоча видалення їх не є строго необхідним, якщо вони не використовуються, вони повинні піти на усунення потенційної плутанини в майбутньому.

4. Тригери на рівні сервера можуть посилатися на базу даних.

5. Шукайте плани технічного обслуговування, що посилаються на базу даних - вони вийдуть з ладу, якщо їх не буде оновлено для видалення відсутньої бази даних.

Усі основні моменти вже висвітлені. Нижче мої 2 копійки:

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

Зазвичай бази даних, які навмисно зберігаються в режимі офлайн і продовжують генерувати сповіщення, - це ті, які ми відлучаємо і зберігаємо, поки вони не можуть бути назавжди видалені (видалені).

Попередня задача від'єднання: Запустіть, sp_helpdb dbnameщоб знати місця розташування файлів

Завдання очищення:

1. Видаліть файли mdf, ndf та ldf з бази даних з місць, де вони перебувають.
2. Старі файли резервного копіювання для бази даних потрібно або видалити, або перенести на інший сервер, враховуючи період зберігання.

Окрім Логінів, Агентських робочих місць, Тригерів та вже згаданих моментів Макса, ці 2 можна також переглянути.