Oracle 데이터베이스에 데이터 스토리지를 위해 둘 이상의 테이블 스페이스가 있어야합니까?

Question

우리 팀은 약. 크기 200GB. 모든 데이터 (테이블, 인덱스 등)는 단일 '사용자'테이블 스페이스 내에 있습니다. 이것이 나쁜 생각입니까? 여러 테이블 스페이스를 갖는 데 어떤 이점이 있으며, 어떤 상황에서 내 데이터베이스에 더 많은 것을 추가하고 싶습니까?

감사!

Answer 1

저의 편견 (그리고 이것은 대부분 개인 취향의 문제입니다). 추가 테이블 스페이스를 만드는 데 강력한 이점이 없다면 단일 테이블 스페이스에서는 삶이 더 쉽다는 것입니다.

• 다른 테이블 스페이스에 객체를 넣는 것은 성능 이점이 없습니다. 테이블과 인덱스를 분리하는 것은 성능 이점이 있다는 오래된 신화가 있습니다. 사용 가능한 모든 스핀들에 I/O를 전파하는 데 잠재적 인 이점이 있지만, Oracle은 SAN ISN이 귀하의 SAN ISN을 가정 할 때 다른 데이터 파일에 범인의 라운드 로빈 할당을 수행하기 때문에 여러 테이블 스페이스에서 여러 테이블 스페이스에서 여러 데이터 파일로 수행하는 것이 좋습니다. '이미 I/O를 고르게하기 위해 무언가를하고 있습니다.
• 더 작은 트랜잭션 테이블 스페이스를 가져 와서 클라이언트 사이트에 새 데이터베이스 사본을 가져올 수 있도록 크고 정적 조회/ 히스토리 테이블이있는 경우 여러 테이블 스페이스를 고려해야 할 이유입니다. 그러나 이러한 종류의 설정이있는 응용 프로그램은 거의 없습니다. 200GB를 모두 가져와야한다면, 당신이 얼마나 많은 테이블 스페이스를 가지고 있는지는 중요하지 않습니다.
• 같은 줄을 따라 읽기 전용 객체가 큰 경우 읽기 전용 테이블 스페이스에 넣으면 백업에 필요한 시간과 공간이 크게 줄어들 수 있습니다. 그러나 이것은 데이터웨어 하우스 이외의 상황에서 특히 일반적이지 않습니다.
• 객체의 일부 하위 집합없이 응용 프로그램이 실행될 수있는 경우 별도의 테이블 스페이스를 만들면 하나의 오프라인을 취하고 테이블 스페이스 레벨 복원을 수행 할 수 있습니다. 다시 말하지만, 일련의 객체 없이는 응용 프로그램이 거의 실행될 수 있습니다. 예를 들어 인덱스 테이블 스페이스를 잃어 버리면 응용 프로그램이 모든 것을 잃어버린 것만 큼 죽을 수 있습니다.
• 비어 있거나 비어있는 테이블이 많고 많은 매우 큰 테이블이있는 경우, 공간 활용 관점에서 할당 정책이 다른 별도의 테이블 스페이스를 선호 할 수 있습니다. 이것은 주어진 설치가 사용 가능한 테이블의 상대적으로 적은 비율을 사용하는 패키지 앱에서 때때로 발생하며 빈 테이블 각각에 비교적 많은 범위가 지정되기를 원하지 않습니다. 로컬에서 관리되는 테이블 스페이스의 자동 범위 관리를 통해 큰 관심사가 아닌 경향이 있으므로 균일 한 범위를 사용하려는 경우 더 중요 할 수 있습니다.
• 다른 객체가 디스크 성능에 대한 우선 순위가 다르고 다른 유형의 디스크가있는 경우 별도의 테이블 스페이스를 사용하면 다른 디스크 세트에 다른 객체를 넣을 수 있습니다. 예를 들어, 데이터웨어 하우스에서 더 비싼 디스크에 더 느리고 저렴한 디스크 및 최신 데이터에 이전 데이터를 넣을 수 있습니다. 이것은 OLTP 응용 프로그램에서는별로 발생하지 않습니다.

신청서가 이러한 특별한 경우 중 하나에 속하지 않는 한, 별도의 테이블 스페이스를 갖는 유일한 이점은 DBA의 조직 감각에 어필하는 것입니다. 개인적으로, 나는 객체를 만들 때마다 테이블 스페이스 이름을 지정하지 않거나 기본 테이블 스페이스에서 필연적으로 기본 테이블 스페이스에서 생성 될 때 "잘못된"테이블 스페이스에서 객체를 움직이는 사이클을 소비하는 것을 피할 수있어서 기쁩니다. 개인적으로, 나는 균일 한 범위의 크기가 다른 손으로 최적화 된 테이블 스페이스 세트에 대해 자동으로 관리되는 로컬 관리 테이블 스페이스를 사용할 때 수십 개의 MB의 공간이 "낭비"되는 경우 지나치게 걱정하지 않습니다. 반면에, 좋은 DBA는 "그냥 그렇게"정리되는 것에 대해 매우 걱정하는 경향이 있으므로 DBA가 다른 사람의 미학에 호소하기 때문에 DBA가 별도의 색인과 데이터 테이블 스페이스를 갖기를 원한다면 군사적으로 반대하지 않습니다.

Answer 2

보다 http://download.oracle.com/docs/cd/b10501_01/server.920/a96521/tspaces.htm

보다 http://download.oracle.com/docs/cd/b28359_01/server.111/b28318/physical.htm

여러 테이블 스페이스를 사용하여 다음 작업을 수행 할 수 있습니다.

데이터베이스 데이터의 제어 디스크 공간 할당

데이터베이스 사용자에 대한 특정 공간 할당량을 지정합니다

개별 테이블 스페이스를 온라인 또는 오프라인으로 가져 와서 데이터의 제어 가용성

부분 데이터베이스 백업 또는 복구 작업을 수행하십시오

성능을 향상시키기 위해 장치 전체에 데이터 스토리지를 할당하십시오

Answer 3

다른 테이블 스페이스를 사용하는 한 가지 이유는 데이터베이스 간 데이터 이동에 테이블 스페이스 전송을 사용하려는 욕구입니다. 내보내고 가져 오지 않고 이동하려는 제한된 데이터 세트가있는 경우 테이블 스페이스 전송이 좋은 옵션입니다. 특히 데이터가 소스 시스템과 정확히 동일한 물리적 구조를 갖는 것이 테스트하는 것이 중요하다면 ( 예를 들어 성능 분석 작업의 경우).

Answer 4

저스틴 동굴 평가에 강력하게 동의하지 않습니다. 생산 DBA는 매우 다른 의견을 가질 것입니다.

전송 가능한 테이블 스페이스 기능은 전체 데이터베이스를 이동할 필요없이 데이터베이스 간 데이터의 하위 집합을 이동할 수 있습니다.

읽기 전용 테이블 스페이스 따라서 매주 전체 데이터베이스를 백업하지 않으므로 몇 시간이 걸릴 수 있으며 속도를 제한하더라도 그 시간 동안 성능을 견딜 수 없습니다.

많은 장소에 데이터베이스가 크지 않지만 크기로 인해 고정 날짜로 특정 테이블 스페이스 만 백업합니다. 위의 점과 같은 이유.

응용 프로그램에 따라 응용 프로그램 측면에서 서로 독립적으로 작동 할 수있는 모듈이 있다고 가정 해 봅시다. 각각 고유 한 테이블 스페이스 세트가 있으면 하나의 앱 테이블 스페이스를 오프라인으로 가져갈 수 있습니다.

데이터와 인덱스의 분리에 관해서는 : 전통적인 이유는 두 디스크를 다른 디스크에 넣어 서로 경쟁하지 않았기 때문입니다. Sans와 같은 오늘날의 스토리지 기능은 모두 같은 저장 공간이지만 아직 로컬로 관리되는 테이블 스페이스에서도 파일 헤더 레벨에서 경합을받을 것이라는 점을 고려하여 테이블에서 인덱스를 원형으로 분리 할 수없는 동일한 테이블 스페이스에 모든 객체를 가지고 있다면 !! 하나의 테이블 스페이스에서 20 개의 데이터 파일을 생성하더라도 테이블과 인덱스가 어디로 갈지 결정할 수 없으며, 언젠가 인덱스가있는 테이블에 대한 대규모 활동으로 인해 파일 헤더 레벨에서 주요 경합이 있음을 알 수 있습니다. 같은 데이터 파일에 있습니다! 실제로 그것을 긁어냅니다. TS가 하나만 있다면, 당신은 당신입니다 ~ 할 것이다 의심 할 여지없이 파일 헤더 경합을 경험합니다.

논리적 분리를하는 데 더 많은 이유가 있으며, 아니요, 대부분의 성능에 관한 것이 아니라 생산 환경의 관리에 관한 것입니다.

Answer 5

S. Lott already gave a good list of general reasons why one might want to split that up onto multiple tablespaces.

More specific to your situation...

I would ask myself if there are specific reasons to change things now. It's no small task to make a structural change like that. Are there performance issues? Are you running against storage space limits? Do you need to assign space quotas? Does your present backup and restore plan meet your needs?

If you could go back in time and redo things from the beginning you would certainly want to plan to sensibly divide the database into different table spaces. But is it worth it now?