오라클 데이터베이스에 데이터 스토리지를 위한 테이블스페이스가 두 개 이상 있어야 합니까?

오라클 데이터베이스에 데이터 스토리지를 위한 테이블스페이스가 두 개 이상 있어야 합니까?

저희 팀은 약 200GB 크기의 Oracle 데이터베이스를 유지 관리하고 있습니다.모든 데이터(테이블, 인덱스 등)는 단일 'USERS' 테이블스페이스 내에 있습니다.나쁜 생각인가요?테이블스페이스가 여러 개인 경우 어떤 이점이 있습니까? 어떤 상황에서 데이터베이스에 추가하고 싶습니까?

감사합니다!

저의 편견(그리고 이것은 대부분 개인적 선호도의 문제)은 추가 테이블스페이스를 만드는 것에 대한 설득력 있는 이점이 없다면 단일 테이블스페이스로 삶이 더 쉬워진다는 것입니다.

• 개체를 다른 테이블스페이스에 배치해도 성능상의 이점은 없습니다.테이블과 인덱스를 분리하면 성능 면에서 어느 정도 이점이 있다는 오래된 신화가 있습니다.사용 가능한 모든 스핀들에 I/O를 분산하는 것에는 잠재적인 이점이 있지만, Oracle은 SAN이 I/O를 균등하게 하지 않는다고 가정하고 여러 데이터 파일의 익스텐트를 라운드 로빈 방식으로 할당하기 때문에 단일 테이블 공간에 있는 여러 데이터 파일을 사용하는 것이 좋습니다.
• 더 작은 트랜잭션 테이블스페이스를 가져오기만 하면 데이터베이스의 새 복사본을 클라이언트 사이트로 가져올 수 있는 대규모 정적 조회/기록 테이블이 있다면 여러 테이블스페이스를 고려해야 할 이유가 됩니다.하지만 이런 종류의 설정을 가진 응용 프로그램은 거의 없습니다.200GB를 모두 가져와야 한다면 테이블스페이스가 몇 개 있는지는 중요하지 않습니다.
• 마찬가지로 읽기 전용 개체가 큰 경우 읽기 전용 테이블 공간에 개체를 배치하면 백업에 필요한 시간과 공간을 크게 줄일 수 있습니다.그러나 데이터 웨어하우스 외부에서는 이러한 현상이 특히 일반적이지 않습니다.
• 일부 개체의 하위 집합 없이 응용 프로그램을 실행할 수 있는 경우 별도의 테이블스페이스를 만들어 오프라인으로 전환하고 테이블스페이스 수준 복원을 수행할 수 있습니다.그러나 개체 집합 없이 실행할 수 있는 애플리케이션은 거의 없습니다. 예를 들어 인덱스 테이블 공간을 잃게 되면 애플리케이션이 모든 것을 잃었을 때와 마찬가지로 비활성화될 가능성이 높습니다.
• 빈 테이블이나 대부분 빈 테이블이 많고 매우 큰 테이블이 많은 경우 공간 활용 측면에서 익스텐트 할당 정책이 서로 다른 별도의 테이블스페이스가 선호될 수 있습니다.이 문제는 패키지화된 앱에서 가끔 발생하는데, 특정 설치에서 사용 가능한 테이블의 상대적으로 적은 비율을 사용하고 있으며 빈 테이블 각각에 상대적으로 큰 익스텐트를 할당하지 않으려는 경우입니다.로컬로 관리되는 테이블스페이스에서 자동 익스텐트 관리를 사용할 경우 이는 큰 문제가 되지 않으며 균일한 익스텐트를 사용할 경우 더욱 문제가 될 수 있습니다.
• 개체마다 디스크 성능에 대한 우선 순위가 다르고 사용 가능한 디스크 유형이 다른 경우 테이블스페이스를 별도로 사용하여 다른 개체를 다른 디스크 집합에 배치할 수 있습니다.예를 들어 데이터 웨어하우스에서 오래된 데이터는 더 느리고 저렴한 디스크에 저장하고 최신 데이터는 더 비싼 디스크에 저장할 수 있습니다.OLTP 애플리케이션에서는 이러한 현상이 많이 발생하지 않습니다.

애플리케이션이 이러한 특별한 경우에 해당하지 않는 한, 별도의 테이블스페이스를 갖는 것의 유일한 이점은 DBA의 조직 감각에 호소하는 것입니다.개인적으로 개체를 만들 때마다 테이블스페이스 이름을 지정하지 않거나 기본 테이블스페이스에서 실수로 생성될 경우 "잘못된" 테이블스페이스에서 개체를 이동하는 데 사용할 수 있어 매우 기쁩니다.개인적으로, 저는 로컬에서 관리되는 테이블스페이스를 자동 익스텐트 관리 기능과 함께 사용할 때 동일한 익스텐트 크기를 가진 손으로 최적화된 테이블스페이스 세트를 사용할 때 수십 MB의 공간이 "낭비"되는 것에 대해 크게 우려하지 않습니다.반면에 좋은 DBA는 "그저 그렇다"는 식으로 정리되는 것에 대해 매우 우려하는 경향이 있으므로, DBA가 다른 사람의 미적 감각에 호소한다고 해서 인덱스와 데이터 테이블 공간을 따로 마련하는 것에 대해 강력하게 반대하지는 않습니다.

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 을 참조하십시오.

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

데이터베이스 데이터에 대한 디스크 공간 할당 제어

데이터베이스 사용자에 대한 특정 공간 할당량 할당

개별 테이블스페이스를 온라인 또는 오프라인으로 전환하여 데이터 가용성 제어

부분 데이터베이스 백업 또는 복구 작업 수행

여러 장치에 데이터 스토리지를 할당하여 성능 향상

다른 테이블스페이스를 사용하는 한 가지 이유는 데이터베이스 간에 데이터를 이동하기 위해 테이블스페이스 전송을 사용하려는 경우입니다.데이터를 내보내고 가져올 필요 없이 이동하려는 데이터 집합이 제한적인 경우 테이블스페이스 전송이 좋은 옵션입니다. 특히 데이터가 원본 시스템과 정확히 동일한 물리적 구조(예: 성능 분석 작업용)를 가지고 있다는 테스트 이유로 중요한 경우에는 더욱 그렇습니다.

저는 저스틴 케이브스의 평가에 강력히 반대합니다.프로덕션 DBA의 의견은 매우 다를 수 있습니다.

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

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

크기가 너무 크기 때문에 특정 테이블스페이스만 고정된 날짜에 백업합니다. 많은 곳에는 이렇게 큰 데이터베이스가 없습니다. 위의 점과 같은 이유입니다.

응용 프로그램에 따라 응용 프로그램 측에서 서로 독립적으로 작동할 수 있는 모듈이 있다고 가정해 보겠습니다.각각 고유한 테이블스페이스 집합이 있는 경우 다른 모듈에 영향을 주지 않고 한 앱 테이블스페이스를 오프라인으로 전환하여 로그를 수행할 수 있습니다.그들은 정상적으로 달릴 수 있습니다.

데이터와 인덱스를 분리하는 경우: 전통적인 이유는 두 디스크를 서로 다른 디스크에 배치하여 성능 면에서 서로 경쟁하지 않기 때문입니다.SAN과 같은 오늘날의 스토리지 기능에는 큰 문제가 없습니다. SAN은 스토리지 영역이 모두 동일합니다.그러나 인덱스와 테이블을 로컬로 구분할 수 없는 동일한 테이블 공간에 모든 개체가 있는 경우 로컬로 관리되는 테이블스페이스에서도 파일 헤더 수준에서 경합이 발생할 수 있다는 점을 고려해야 합니다.테이블 공간 하나에 20개의 데이터 파일을 생성하더라도 테이블과 인덱스가 어디로 가는지 결정할 수 없습니다. 어느 날 인덱스가 같은 데이터 파일에 있는 테이블에 대한 엄청난 작업으로 인해 파일 헤더 수준에서 중요한 경합이 발생합니다.사실 그것은 폐기합니다.t가 하나만 있으면 파일 헤더 경합이 발생할 수 있습니다.

논리적으로 분리해야 하는 이유는 더 많습니다. 아니요, 대부분의 경우 성능이 아니라 운영 환경의 관리에 관한 것입니다.

S. Lott는 이미 그것을 여러 테이블스페이스로 나누고 싶어하는 일반적인 이유들의 좋은 목록을 제공했습니다.

상황을 좀 더 구체적으로 말씀드리면...

저는 지금 상황을 바꿔야 할 구체적인 이유가 있는지 자문하고 싶습니다.그렇게 구조적인 변화를 만드는 것은 작은 일이 아닙니다.성능 문제가 있습니까?스토리지 공간 제한을 위반하고 있습니까?공간 할당량을 할당해야 합니까?현재 백업 및 복원 계획이 귀사의 요구사항을 충족합니까?

과거로 돌아가서 처음부터 다시 시작할 수 있다면 데이터베이스를 여러 테이블 공간으로 현명하게 분할할 계획을 세우고 싶을 것입니다.하지만 지금 그럴 가치가 있을까요?

언급URL : https://stackoverflow.com/questions/1291317/should-an-oracle-database-have-more-than-one-tablespace-for-data-storage