2010-05-24 2 views
3

저는 Oracle 11g 데이터베이스 테이블의 디자인을 여전히 수정하고있는 꽤 새로운 프로젝트를 진행하고 있습니다. 따라서 테이블 생성 스크립트가 변경 될 때마다 예상대로 작동하는지 확인하기 위해 테이블을 상당히 자주 삭제하고 다시 만듭니다.삭제 및 재 작성중인 테이블에 대해 GRANT를 유지하는 방법은 무엇입니까?

데이터베이스는 2 개의 스키마로 구성됩니다. 하나의 스키마에는 INSERT 트리거가있는 일부 테이블이있어 데이터가 두 번째 스키마의 테이블에 복사되는 경우가 있습니다. 예를 들어 sysdbaGRANT과 같은 관리자 계정으로 데이터베이스에 로그인해야 첫 번째 스키마에 대한 두 번째 스키마의 필요한 테이블에 대한 액세스가 필요합니다.

GRANT ALL ON schema_two.SomeTable TO schema_one; 

우리의 문제는 때마다 우리는 우리의 데이터베이스 디자인을 변경 한 드롭, 우리 GRANT 테이블이 떨어졌다 때 멀리 갔다 schema_one에 -ed 접근을 우리의 데이터베이스 테이블을 다시 만들어야 할 것입니다. 따라서 관리자 계정으로 로그인해야이 테이블 중 하나를 삭제하고 다시 만들 때마다 액세스가 다시 이루어져야합니다.

이것은 큰 문제는 아니지만 개발 및 테스트 절차에서 가능한 많은 단계를 없애고 싶습니다. 어떤 방법으로도 GRANT 테이블에 액세스 할 수 있습니까? GRANT -ed 권한은 테이블이 삭제 된 후 다시 살아남을 때 생존 할 수 있습니까? 그리고 이것이 가능하지 않다면, 이것에 대해 갈 수있는 더 좋은 방법이 있습니까?

답변

3

select any table, insert any table 등을 schema_one에 부여 할 수 있지만 과장된 것처럼 보이며 사용자가 제작 과정에서 바라는 바를 반영하지 않습니다. schema_two로 로그인 한 상태에서 테이블을 생성하는 것과 동시에 권한을 발행 할 수없는 이유는 무엇입니까? 필자는 항상 생성 스크립트에서 그렇게했으며 관리자 계정을 사용하여 제 3 자 또는 시스템 권한을 부여했습니다. 나는 뭔가를 놓친 것 같아요 ...

+1

예 - 우리에게 이것은 테이블 생성 스크립트의 일부입니다. 나는 또한 문제 설명에서 무언가를 놓쳐 버렸음에 틀림 없다. – DaveE

+0

감사합니다. 실제로'SELECT ANY TABLE' 권한에 대해서는 알지 못했습니다. 나는 GRANT ALL ON schema_one. *과 동등한 것이 없다는 것을 알았으므로 스키마 담요에 이와 같은 권한을 줄 수 있다는 것을 깨닫지 못했습니다. –

+1

그건 아마 당신이 프로덕션에서 원하는 것이 아니거나 당신도 그 env를 소유하지 않으면 가질 수 있다고 가정해야합니다. 왜 테이블 생성과 같은 스크립트에서 권한을 부여 할 수 없는지 잘 모르겠습니다. schema_two는 모든 사람에게 자체 개체에 대한 사용 권한을 부여 할 수 있어야하며 프로덕션 설치를 시작할 때 단계를 줄일 수 있습니다. 네가 할 수없는 이유가 있니? –

3

ALTER TABLE 문으로 처리 할 수없는 작업은 무엇입니까?

다음 최적의 옵션은 일시적으로 사라지는 테이블을 참조하는 뷰를 만드는 것일 수 있습니다. 뷰가 사라지지 않고 테이블이 그러한 상황에 존재하지 않으면 오류가 발생합니다. IE :

CREATE VIEW table_vw AS 
    SELECT t.* 
    FROM DISAPPEARING_TABLE t 

* 표기법을 사용하면보기를 계속 업데이트하여 테이블의 열을 표시 할 필요가 없습니다.

+2

IIRC : 기본 테이블에 열을 추가하면 SELECT *가 도움이되지 않습니다. Oracle은 *가 생성 된 지점의 열 목록으로 변환합니다. - 원본으로 사용하는 테이블에 다른 열을 추가하면 이후에 추가되지 않습니다. 뷰를 삭제하고 열을 삭제하면 뷰가 무효화됩니다. –

+0

단순히 ALTER TABLE 문을 수행 할 때의 문제점은 초기에 새로 생성 된 테이블에 데이터를 채우는 스크립트뿐만 아니라 테이블 생성 스크립트를 다시 테스트하려는 것입니다. 이상적으로 우리는 가능한 한 빨리 파손을 감지하기 위해 변경 작업을 할 때마다 이것을 테스트하고 싶습니다. 그래서 우리는 테이블을 삭제하고 다시 만들고 싶습니다. –

1

DDL 트리거 또는 권한을 자동으로 부여하는 몇 분마다 실행되는 일괄 작업이있을 수 있습니다. 그러나 그것은 약간의 보안 허점이며 생산을 대표하지 않을 것입니다.

6

그래서 권한 부여가 취소 된 이유는 새 테이블이 다른 개체라는 것입니다.

SQL> select object_id from user_objects 
    2 where object_name = 'T72' 
    3/

OBJECT_ID 
---------- 
    659195 

SQL> drop table t72 
    2/

Table dropped. 

SQL> create table t72 (id number) 
    2/

Table created. 

SQL> select object_id from user_objects 
    2 where object_name = 'T72' 
    3/

OBJECT_ID 
---------- 
    659212 

SQL> 

보조금은 개체 이름이 아니라 개체에 있습니다.

문제점에 대해 잘 모르는 부분은 다음과 같습니다. schema_two에 표를 삭제하고 다시 만드는 프로세스가 있습니다. 해당 프로세스가 해당 테이블에 대한 권한을 schema_one에 부여하지 않는 이유는 무엇입니까? 왜 대신 관리자 계정을 가지고 있습니까? DROP 및 CREATE 문을 실행하기 위해 schema_two으로 연결한다고 가정합니다. 왜 그 단계에 GRANT 문을 추가하지 않는 것이 좋을까요?

개체에 대한 권한을 부여하는 것이 테이블을 만드는 것만큼이나 설치의 일부이기 때문입니다. 그래서 모든 일을 처리하는 과정을 가져야합니다.

1

테이블을 만드는 데 사용하는 계정에 보조금을 실행할 수있는 권한을 부여하는 것이 좋습니다.

공유하고 즐기십시오.

관련 문제