Recentemente è emersa una domanda in cui l'utente dboin un database aveva un indirizzo sidnon corrispondente a owner_sidin sys.databases. Capisco come il proprietario del database sia diverso dai membri del ruolo, db_ownerma ho sempre pensato che l'utente dbofosse il vero proprietario del database. Non è così? E se sì, ci sono delle reali differenze tra dboe cosa c'è dentro sys.databases?
Risposte:
Ho sempre pensato che l'utente
dbofosse l'effettivo proprietario del database.
Questo è (o almeno dovrebbe essere) corretto. Il nome "dbo" di quell'utente non cambia mai, eppure il SID sottostante lo fa a seconda di chi ha creato il database o di chi è stato impostato tramite sp_changedbowner ( attivo anche se incluso SQL Server 2005) o ALTER AUTHORIZATION (a partire da SQL Server 2008).
In tutti e tre questi casi, anche il record in sys.databasesviene modificato in modo da mantenerli sincronizzati. Tuttavia, quando si ripristina un database, da un altro sistema o dalla stessa istanza ma da un DB di cui è stato eseguito il backup / scollegato prima di uno di quei 2 comandi SQL eseguiti per modificare il proprietario, quindi su RESTORE o collegamento, ci sarà essere un disallineamento tra la owner_sidcolonna sys.databasese il "dbo" sidin sys.database_principalsfatto che DB.
Per quanto ne so, il record in sys.database_principalsogni DB è il vero proprietario e la owner_sidcolonna in sys.databasesè una questione di conservazione / convenienza (simile alla denormalizzazione; senza che sys.databasesil sistema avrebbe bisogno di effettuare query separate in tutti i DB per ottenere tali informazioni, ogni volta che richiesto!) e sicurezza. Una cosa per cui è usato è identificare un DB potenzialmente dannoso / non ripristinato / collegato è che quei record non corrispondono. Tentativo di accedere agli assembly SQLCLR contrassegnati come uno EXTERNAL_ACCESSo UNSAFEnon verranno caricati se si è scelto di seguire il percorso meno sicuro dell'abilitazione in TRUSTWORTHYquanto si basa sul SID "dbo" in quanto deve corrispondere a un account di accesso che ha il EXTERNAL ACCESS ASSEMBLYoUNSAFE ASSEMBLYautorizzazione. E quando c'è una discrepanza nel SID tra quelle due viste del catalogo di sistema, non è possibile determinare quale utilizzare e utilizzare come bandiera rossa per un potenziale problema di sicurezza. In effetti, provo questa condizione nello script di installazione di SQL # per avvisare qualcuno di apportare le modifiche appropriate, solo in modo che non debbano perdere tempo a cercarlo nel caso in cui SQL Server si lamenta ad un certo punto.