오늘 서비스 브로커 문제를 해결하는 동안 데이터베이스 소유자는 회사를 떠난 직원의 Windows 로그인이라는 것을 알았습니다. 그의 로그인이 제거되어 쿼리 알림이 실패했습니다.
아마도 이것을 다루는 가장 좋은 방법은 데이터베이스 소유자를 'sa'로 만드는 것입니다. 우리는 그것을 바꾸었고 대기열을 정리했습니다.
내 (매우 기본적인) 질문 : 데이터베이스 소유자는 무엇이며 그 목적은 무엇입니까?
답변:
한쪽의 'dbo'(사용자)와 'db_owner'(고정 역할)의 데이터베이스 개념과 다른 쪽의 'database owner'의 인스턴스 개념 사이에는 약간의 혼동이 있습니다. 'dbo'및 'db_owner'는 종종 '데이터베이스 소유자'라고합니다. 당신이 요구하는 것에서 당신은 데이터베이스를 소유하는 서버 주체로서 데이터베이스 소유자에 대해 이야기하고 있습니다.
이론은 다음과 같습니다. 사용 권한을 부여 할 수있는 것은 '보안 가능' 입니다. 모든 유가 증권에는 소유자가 있습니다. 유가 증권 소유자는 유가 증권에 대한 절대적인 통제권을 가지며 어떠한 특권도 부인할 수 없습니다. 인스턴스 레벨 보안 가능 항목은 서버 프린시 펄 (로그인) 이 소유 합니다. 데이터베이스 수준 보안 개체는 데이터베이스 보안 주체 (사용자)가 소유합니다. 교장은 1 차 (정체성)와 2 차 (구성원)의 두 가지 맛이 있습니다. 서버 레벨 보안 가능 파일은 기본적으로 현재 로그 된 기본 서버 프린시 펄이 소유합니다. 기본적으로 스키마 소유자가 소유 한 스키마 바운드 개체를 제외하고 데이터베이스 수준 보안 개체는 기본적으로 현재 데이터베이스 보안 주체가 소유합니다. 모든 유가 증권은 생성시 다른 소유자를 시행하기 위해 AUTHORIZATION 절을 지원합니다.ALTER AUTHORIZATION 나중에 보안 가능한 소유자를 변경하는 데 사용할 수 있습니다.
데이터베이스는 보안 가능한 서버 레벨이므로 기본적으로 CREATE DATABASE 문을 발행 한 기본 프린시 펄이 소유합니다. 즉. 출발 한 직원의 NT 로그인.
따라서 귀하의 질문은 " 유가 증권이 왜 소유자가 필요합니까? "입니다. 주인이 신뢰의 근원이기 때문입니다. 개체에 대한 권한을 부여, 거부 및 취소하는 것은 소유자입니다. 보안 시스템 소유자없이 보안 시스템을 설계 할 수 있습니까? 아마도 그렇습니다. 그러나 현재 모델에서 역할 소유자가 수행하는 역할을 대체 할 메커니즘이 있어야합니다. 예를 들어 아빠 유가 증권에는 소유자가 없다고 생각하십시오 (예 : 유가 증권을 소유하는 대신 원래 작성자에게는 제어 권한이 부여됨). 유가 증권을 만들고 자신을 포함 하여 모든 사람에게 액세스 권한을 취소 할 수 있습니다 . 소유자가 자신을 잠글 수 없기 때문에 소유자의 요구 사항이이 문제를 피할 수 있습니다.
원래 NT 로그인이 소유 한 보안 가능 (데이터베이스)을 작성하는 CREATE DATABASE의 부작용은 알려진 바가 거의 없습니다. 규칙은 모든 보안 가능에 대해 동일하지만 일부 요인으로 인해 DATABASE 소유자 문제가 악화됩니다.
dbo주체) 또는 다른 데이터베이스 보안 주체 가 소유함으로써 종료 되므로 소유자는 데이터베이스에 포함EXECUTE AS context. 이 후자의 문제는 대부분의 사용자를 태우는 것입니다. Service Broker는 EXECUTE AS를 광범위하게 사용하므로 (메시지 배달에는 암시 적 EXECUTE AS 컨텍스트와 명시 적 컨텍스트가있는 큐 활성화가 있음) 일반적으로이 문제를 먼저 발견하는 Service Broker 사용자입니다.BTW, 원래 문제를 조사하고 수정하기위한 Kudos :)
데이터베이스 owner는 SQL Sever 2005에서 (적절한) 스키마가 도입되기 전의 시간으로 약간 되돌아 왔습니다.
기본적으로 데이터베이스 소유자 는 데이터베이스 의 기본 dbo(데이터베이스 소유자)이며 데이터베이스 자체는 데이터베이스 오브젝트 입니다.
로부터 SQL Server 2000의 문서 ...
는
dbo데이터베이스의 모든 활동을 수행 할 수있는 권한을 암시 한 사용자입니다.
이전 버전의 SQL Server에서 스키마가 개체를 "소유"할 수없는 경우 ( 또는 모든 개체, 테이블, 뷰 등이 소유 dbo하고 있고 다른 스키마가 없음을 명시해야 함 ) "user"는 그것을 소유해야합니다. 왜 무언가 가 데이터베이스를 소유 해야하는지 말하지 않아야 합니다 (또는 일반적으로 권한이 다소 어려울 수 있습니다)
따라서 기술적으로 이전 버전의 SQL Server (또는 업그레이드 된 데이터베이스)에서는 "Foo"테이블이 아니고 "dbo.Foo"테이블은 ... dbo소유자가되었습니다.
SQL Server 2005의 출현으로 "bar"라는 스키마와 "Foo"라는 테이블이 있다고하는 것처럼 스키마 소유 데이터베이스 개체를 가질 수 있습니다 bar.Foo.
SELECT * FROM bar.Foo WHERE etc = 'blah`;까다로운 부분은 데이터베이스를 생성 하는 사용자 가 소유자 로 자동 설정되어 직원 전환 등의 문제가 발생 한다는 사실과 함께 제공 됩니다 .
따라서이 sa계정을 계정으로 변경 하거나 조직의 운영 / IT 팀이 관리 할 수있는 도메인 계정으로 변경하는 것이 가장 좋습니다 .
이 기사 는 오래된 "소유자"방식과 새로운 "스키마"기반 소유권 시스템의 차이점을 설명합니다.
소유자와 스키마의 차이점을 이해하기 위해 개체 소유권을 검토하는 데 시간을 할애하십시오. SQL Server 2000 이전 버전에서 개체를 만들 때는 개체에 소유자가 있어야합니다. 대부분의 경우 소유자는“dbo”이며 데이터베이스 소유자라고도합니다.