Come si eliminano gli utenti da un database di SQL Server 2008?


22

Dobbiamo eseguire un ripristino e non è possibile perché altri utenti sono connessi. Pensavamo di aver disconnesso ogni processo, ma apparentemente no.

Come possiamo, da Management Studio, dare il via a tutti gli altri in modo da poter fare questo backup?

Risposte:


25

Esistono due modi per farlo:

  1. Fare clic con il tasto destro sul database in Esplora oggetti andare su Attività> Stacca. Seleziona la casella di controllo Rilascia connessioni.

  2. Impostare il database in modalità utente singolo come indicato qui :

    -- hit Ctrl+Shift+M in SSMS to fill in the template parameter
    USE master;
    GO
    
    ALTER DATABASE N'<Database Name, sysname,>'
    SET SINGLE_USER
    WITH ROLLBACK IMMEDIATE;
    GO
    
    ALTER DATABASE N'<Database Name, sysname,>'
    SET READ_ONLY;
    GO
    
    ALTER DATABASE N'<Database Name, sysname,>'
    SET MULTI_USER;
    GO

Non avevo capito che avevo così tanti commenti lol. Marian ha ragione, non è necessario eseguire il distacco effettivo, basta ottenere lo script per uccidere gli utenti. @NickChammas Sì, farlo leggere impedisce solo agli utenti di riconnettersi. Quando lo si imposta multiutente è possibile eseguire il ripristino. Anche i nomi db provengono da un modello e come tali i tag come "<Nome database, sysname>" devono essere sostituiti mediante l'uso di Ctrl + Shift + M. In uno script non basato su modelli, i dbnames non contengono virgolette.
Wil,

43

Uso sempre quanto segue:

USE master; -- get out of dbname myself
GO
-- kick all other users out:
ALTER DATABASE [dbname] SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
-- prevent sessions from re-establishing connection:
ALTER DATABASE [dbname] SET OFFLINE;

A volte questo può richiedere del tempo, a volte è bloccato perché sei tu quello che lo esegue e hai una connessione attiva al database . Controlla altre finestre di query che potrebbero avere lo stesso contesto di database: questo può includere finestre di dialogo aperte, Esplora oggetti, IntelliSense, lavori di lunga durata, ecc.

Quando ho finito di fare le mie modifiche alla configurazione di quel database, semplicemente:

ALTER DATABASE [dbname] SET ONLINE;
ALTER DATABASE [dbname] SET MULTI_USER;

Sebbene, a volte, la cosa che devo fare per quel database richieda che il database sia online, quindi a volte devo lasciarlo in modalità utente singolo e fare questo:

ALTER DATABASE [dbname] SET ONLINE;
GO
USE [dbname];

Ora posso apportare le mie modifiche e, quando sono pronto per la connessione di altri utenti, semplicemente:

ALTER DATABASE [dbname] SET MULTI_USER;

2

Normalmente imposto il database in single_user e quindi aspetto il ritardo, quindi ripristino il database in multiutente come di seguito:

-- to kill all connections for particular db ... otherwise the restore will fail as exclusive lock cannot be obtained for the db being restored.

    alter database db_name
    set single_user with rollback immediate
    waitfor delay '00:00:05'  -- wait for 5 secs
    alter database db_name
    set multi_user
    restore database db_name from disk = 'D:\restore\db_name.bak'
    with replace, stats = 10, recovery -- if you want to recover your database online
    -- optional if you dont have the same directory/file structure
    move 'datafile logical name' to 'E:\data\physical_name.mdf',
    move 'logfile logical name' to 'F:\log\physical_name_log.ldf'

In realtà, non è necessario "impostare multi_utente", poiché si esegue un singolo script (transazione) con l'istruzione di ripristino. Il ripristino con ripristino si occuperà di ripristinare il database in modalità multiutente.
Svein Terje Gaup,

1

Nessuna delle opzioni sopra ha funzionato per me perché il server è stato martellato da più tentativi di connessione remota.

Quando ho chiuso la porta specifica del database sul firewall di Windows, il normale Alter .. Set Multi_User ha funzionato nel primo tentativo.


-1

Quanto segue uccide effettivamente tutte le connessioni. Molto utile nei casi in cui l'impostazione della modalità utente singolo non riesce

declare @execSql varchar(1000), @databaseName varchar(100)
-- Set the database name for which to kill the connections
set @databaseName = 'databasename'
set @execSql = '' 
select  @execSql = @execSql + 'kill ' + convert(char(10), spid) + ' '
from    master.dbo.sysprocesses
where   db_name(dbid) = @databaseName
     and
     DBID <> 0
     and
     spid <> @@spid
exec(@execSql)

1
Questo non funziona perché sysprocessesnon tiene sempre conto di tutte le sessioni che potrebbero contenere blocchi in quel database (si pensi al semplice scenario in cui una query viene eseguita nel contesto del database A ma unisce una tabella in A e una tabella in B) .
Aaron Bertrand

-1

È possibile utilizzare lo script di seguito per eseguire l'annullamento di tutti o modificarlo per un DB specifico.

Tutto ciò che può essere ucciso, lo sarà! Gli SPID del servizio SQL tuttavia non saranno interessati.

Drop table #who

go 

Create table #who(  [spid] int,
                    [ECID] int,
                    [Status] varchar(100),
                    [Loginname] varchar(200),
                    [Hostname] varchar(200),
                    [blk] bit,
                    dbname varchar(200),
                    cmd varchar(1000),
                    requestID int
                  )

go

Insert into #who (Spid, ECID, Status, Loginname, hostname,blk, dbname, cmd, requestid)
exec sp_who

Declare cursKillUsers Cursor for Select 'Kill ' + cast(spid as varchar(100)) + ';' [SQL] from #who where dbname like '%'
Declare @sql varchar(200)
Open cursKillUsers
Fetch next from cursKillUsers into @sql
While @@fetch_status = 0 
begin

    print @sql
    Exec (@sql)
    Fetch next from cursKillUsers into @sql

end

close cursKillUsers
deallocate cursKillUsers

-3

Io uso questo codice:

ALTER DATABASE [Dbname] set offline with rollback immediate
GO
ALTER DATABASE [Dbname] set online
GO

Ma vedo che l'esempio SINGOLO UTENTE è meno da digitare.


3
Anche la reimpostazione del database online significa che altri utenti possono riconnettersi prima di iniziare il ripristino.
Aaron Bertrand
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.