Ostatnio mieliśmy pytanie wymyślić, gdzie użytkownik dbow bazie danych mieliśmy sid, że nie pasuje do owner_sidin sys.databases. Rozumiem, dlaczego właściciel bazy danych różni się od członków roli, db_ownerale zawsze myślałem, że użytkownik dbojest faktycznym właścicielem bazy danych. Czy tak nie jest? A jeśli tak, to czy są jakieś rzeczywiste różnice między dbotym, co jest sys.databases?
Odpowiedzi:
Zawsze myślałem, że użytkownik
dbojest faktycznym właścicielem bazy danych.
To jest (a przynajmniej powinno być) prawidłowe. Nazwa „dbo” tego użytkownika nigdy się nie zmienia, ale bazowy identyfikator SID zmienia się w zależności od tego, kto utworzył bazę danych lub kto był ustawiony za pomocą sp_changedbowner (chociaż, włącznie z SQL Server 2005) lub ALTER AUTHORIZATION (zaczynając od SQL Serwer 2008).
We wszystkich tych trzech przypadkach rekord w sys.databasesjest również zmieniany, aby były zsynchronizowane. Jednak podczas przywracania bazy danych z innego systemu lub z tej samej instancji, ale z bazy danych, której kopię zapasową utworzono / odłączono przed wykonaniem jednej z tych 2 komend SQL w celu zmiany właściciela, a następnie PRZYWRÓCIĆ lub dołączyć, nastąpi występować niezgodność pomiędzy owner_sidkolumny sys.databasesi „dbo” sidw sys.database_principalstym, że DB.
O ile mi wiadomo, rekord w sys.database_principalskażdej bazie danych jest prawdziwym właścicielem, a owner_sidkolumna w sys.databasesto kwestia prowadzenia dokumentacji / wygody (podobnie jak w przypadku denormalizacji; bez sys.databasessystemu musiałby tworzyć osobne zapytania dla wszystkich baz danych, aby zdobądź te informacje za każdym razem!) i bezpieczeństwo. Jedną z rzeczy, której się używa, jest identyfikacja potencjalnie szkodliwej / niepoprawnej przywróconej / dołączonej bazy danych, że te rekordy się nie zgadzają. Próba dostępu SQLCLR Zgromadzeń oznaczonych jako albo EXTERNAL_ACCESSczy UNSAFEnie będzie ładować jeśli ktoś zdecydował się pójść mniej bezpieczną trasę umożliwiając TRUSTWORTHYjako że opiera się na „dbo” SID, ponieważ musi pasować do logowania, który ma albo EXTERNAL ACCESS ASSEMBLYalboUNSAFE ASSEMBLYpozwolenie. A gdy w SID występuje rozbieżność między tymi dwoma widokami katalogu systemowego, nie można ustalić, którego użyć, i użyć go jako czerwonej flagi, aby wskazać na potencjalny problem bezpieczeństwa. W rzeczywistości testuję ten warunek w skrypcie instalacyjnym dla SQL #, aby ostrzec kogoś, aby dokonał odpowiedniej zmiany, tak aby nie musiał tracić czasu na szukanie go na wypadek, gdyby SQL Server narzekał na to w pewnym momencie.