Database SQL 2005 non accessibile

Ho spostato un database da sql 2000 a un nuovo server 2005. Tutto è andato bene fino a quando non sono entrato nello studio Sql Server Management con un solo utente. Sembra che ho eseguito l'accesso con successo, ma quando cerco di espandere il database ottengo 'Il database non è accessibile'. Posso accedere con l'authentication di Windows e con altri utenti sql senza alcun problema e posso vedere tutto.

Ho controllato e assicurato che il DB non sia in modalità singola utente. Ho anche controllato per gli accessi orfani (exec sp_change_users_login 'report') e nessuno è stato trovato. L'utente ha anche diritti sul database.

  • Imansible eseguire l'accesso a SQL Server in modalità utente singolo
  • La WMI causa la creazione di CPU?
  • Come posso aggiungere la mia authentication di Windows per il server sql locale?
  • Qual è il modo più efficace per eseguire il backup di una directory piena di file di backup di database di grandi size?
  • Qual è il modo migliore per trasferire database di 20+ a un nuovo server di database? SQL 2005
  • Su Amazon Web Services qual è la differenza tra SQL Server Standard e SQL Server Web?
  • Qualsiasi aiuto per indicarmi nella giusta direzione sarebbe molto apprezzato.

  • Le cose che each DBA di SQL Server dovrebbe conoscere
  • Cosa può fare l'utente con le autorizzazioni VIEW SERVER STATE?
  • MySQL: creazione di un utente che può connettersi da più host
  • Come dimensionare le size dei server SQL (RAM, CPU e altri)
  • Diventare una DBA, cosa devo sapere?
  • Modificare le colonne di tabelle mysql molto grandi con poco o nessun tempo di inattività
  • 6 Solutions collect form web for “Database SQL 2005 non accessibile”

    Molto probabilmente è un problema di autorizzazioni sul nuovo server. I tuoi login SQL non vengono ripresi automaticamente e se crei manualmente sul nuovo server, otterrà un SID diverso che non verrà con quello che è concesso l'accesso al database.

    Il modo migliore è usare sp_help_revlogin (KB918992 nel caso in cui il collegamento muore mai) per generare uno script degli account di accesso sul vecchio server e quindi eseguire lo script sul nuovo server. Questa procedura trasporterà le informazioni SID e password sul nuovo server ricreando effettivamente l'accesso sul nuovo server. Una volta fatto questo, i permessi impostati nel database devono essere sincronizzati con i login sul nuovo server.

    Questo non dovrebbe essere un problema per gli account di accesso di Windows in quanto SQL ottiene il SID da Windows, anche se sarà necessario impostare il login di Windows sul nuovo server. sp_help_revlogin gestirà anche questa parte per te.

    Grazie per le risposte! Dopo aver mucchiato per un po 'sono andato e cancellato l'utente dal database e ricreato, che ha funzionato! Avevo cancellato l'utente e ricreato prima, ma in precedenza l'ho fatto sul livello server e non sul livello DB. Una volta che ho eliminato l'utente dal DB e la ricrea, ha funzionato bene. Grazie ancora per l'aiuto!

    Non si avrà un problema con gli account di accesso basati su Windows poiché non sono associati indietro ai database tramite un SID. Questo è il caso con gli account di accesso SQL come causa "orphaning" come risultato. La scommessa migliore è usare sp_help_revlogin come indirizzato (in modo proattivo) o utilizzare sp_change_users_login (in modo reattivo). Ho usato il seguente script che ho preparato tutto il tempo prima di scoprire sp_help_revlogin anni fa. Questo funziona ancora:

    DECLARE @user SYSNAME DECLARE @SQL NVARCHAR(300) DECLARE cur_Users CURSOR FOR SELECT name FROM sysusers WHERE islogin = 1 AND isntname = 0 AND NAME NOT IN ('guest', 'dbo', 'sys', 'INFORMATION_SCHEMA') ORDER BY name OPEN cur_Users FETCH NEXT FROM cur_Users INTO @user WHILE @@FETCH_STATUS = 0 BEGIN SELECT @SQL = 'EXEC sp_change_users_login ' + '''' + 'UPDATE_ONE' + '''' + ', ' + '''' + @user + '''' + ', ' + '''' + @user + '''' EXEC sp_executesql @SQL FETCH NEXT FROM cur_Users INTO @user END CLOSE cur_Users DEALLOCATE cur_Users 

    Una delle cose che è cambiata dal 2000 al 2005 ha a che fare con un'authorization a livello di database di nuova generazione denominata CONNECT. In SQL Server 2000, essere un utente in un database significava anche avere accesso al database. Tuttavia, in SQL Server 2005, essere un utente in un database non è sufficiente per consentire a un utente di accedere a esso. Normalmente non si noterebbe neppure perché la creazione di un utente in SQL Server 2005, sia tramite DDL che tramite la GUI, concederà automaticamente all'utente l'authorization CONNECT. È ansible perdere questo durante l'aggiornamento in qualche modo?

    Posso ricreare il tuo problema creando un login e mappando l'accesso a un database e poi andando al database e rilasciando un nome utente REVOKE CONNECT TO. Quando cerco di accedere a tale database tramite SSMS come username, ottengo lo stesso messaggio di errore, il database non è accessibile.

    Se sei sicuro che l'utente non sia orfano, vorrei andare nella pagina delle autorizzazioni delle properties; del database tramite SSMS e verificare che l'utente del problema disponga di una concessione per l'authorization CONNECT oppure eseguire la seguente query:

    SELECT pr.name, per. * FROM sys.database_principals AS PR COMUNE sys.database_permissions AS per ON pr.principal_id = per.grantee_principal_id WHERE pr.name = 'il tuo username qui' AND per.permission_name = 'CONNECT';

    Se non vengono restituite righe, è necessario che l'utente abbia aggiunto l'authorization CONNECT per accedere al database come previsto.

    È stato un aggiornamento o hai staccato e ricollegato? Se si staccano e spostano il database in un altro server, gli utenti vengono visualizzati nel database, ma non necessariamente ricevono i ganci di sicurezza. Potrebbe essere necessario reimpostare le autorizzazioni sul server oppure eliminare l'utente e ricrearlo.

    È inoltre ansible utilizzare la stored procedure sp_change_users_login per rimodellare l'utente del database al login appropriato sul nuovo server. Questo fa il trucco senza cancellare l'utente del database. Questo conserva anche le autorizzazioni dell'utente, che è davvero utile se si sono impostate autorizzazioni granulari sugli oggetti nel database. (Notare che questo non funziona con gli account di accesso autenticati di Windows, ma di solito non ho un problema con quelli sincronizzati correttamente.)

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.