인덱스에 대해 테이블스페이스가 다른 논리적인 이유가 있습니까?

인덱스에 대해 테이블스페이스가 다른 논리적인 이유가 있습니까?

안녕하세요. 인덱스와 데이터에 대해 다른 테이블 공간을 만든 이유를 알려주실 수 있나요?

인덱스와 테이블을 별도의 테이블스페이스에 보관하면 성능이 향상된다는 것이 널리 알려져 있습니다.이것은 이제 많은 존경할 만한 전문가들에 의해 신화로 여겨지지만(이 질문 톰 스레드 - "신화" 검색 참조), 오래된 습관은 잘 죽지 않기 때문에 여전히 일반적인 관행입니다.

서드 파티 편집

asktom에서 발췌: Oracle 버전 8.1.6을 위한 2001년의 "Index Tablespace" 질문

• 인덱스를 자신의 테이블스페이스에 유지하는 것이 여전히 좋은 생각입니까?
• 성능이 향상됩니까? 아니면 복구 문제에 가깝습니까?
• 플랫폼마다 답이 다릅니까?

응답의 첫 번째 부분

Yes, no, maybe.

The idea, born in the 1980s when systems were tiny and user counts were in the single 
digits, was that you separated indexes from data into separate tablespaces on different 
disks.

In that fashion, you positioned the head of the disk in the index tablespace and the head 
of the disk in the data tablespace and that would be better then seeking 2 times on the 
same disk.

Drives back then were really slow at seeking and typically measured in the 10's to 100's 
of megabytes (if you were lucky)


Today, with logical volumes, raid, NN gigabyte (nn is rapidly becoming NNN gigabytes) 
drives, hundreds/thousands of concurrent users, thousands of tables, 10's of thousands of 
indexes - this sort of "optimization" is sort of impossible.

What you strive for today is to be able to manage things, to spread IO out evenly 
avoiding hot spots.

Since I believe all things should be in locally managed tablespaces with UNIFORM extent 
sizes, I would say that yes, indexes would be in a different tablespace from the data but 
only because they are a different SIZE then the data.  My table with 50 columns and an 
average row size of 4k might belong in a tablespace that has 5meg extents whereas the 
index on a single number column might belong in a tablespace with 512k or 1m extents.

I tend to keep my indexes separate from the data but for the above sizing reason.  The 
tablespaces frequently end up on the same exact mount points.  You strive for even io 
across your disks and you may end up with indexes and data on the same devices. 

사용자가 많지 않고 데이터베이스 크기가 크지 않았던 80년대에는 일리가 있습니다.그 당시에는 인덱스와 테이블을 서로 다른 물리적 볼륨에 저장하는 것이 유용했습니다.

이제 논리 볼륨, raid 등이 있으므로 인덱스와 테이블을 서로 다른 테이블스페이스에 저장할 필요가 없습니다.

그러나 모든 테이블스페이스는 동일한 확장자 크기로 로컬로 관리되어야 합니다.인덱스에 대한 테이블 공간이 512Kb 확장 크기로 충분할 때 50개의 열이 있는 테이블을 5Mb 확장 크기의 테이블 공간에 저장할 수 있으므로 이 관점에서 인덱스를 다른 테이블 공간에 저장해야 합니다.

• 성능.그것은 사례별로 분석되어야 합니다.저는 모든 것을 한 테이블 공간에 함께 두는 것도 또 다른 신화가 된다고 생각합니다!충분한 스핀들과 충분한 LUN이 있어야 하며 운영 체제에서 대기열을 관리해야 합니다.만약 누군가가 하나의 테이블스페이스를 만드는 것으로 충분하고 다른 모든 요소들을 고려하지 않고 많은 테이블스페이스와 같다고 생각한다면, 이것은 또 다른 신화를 의미합니다.상황에 따라 다릅니다.
• 고가용성.별도의 테이블스페이스를 사용하면 일부 파일 손상, 파일 시스템 손상, 손상 차단 시 시스템의 고가용성을 향상시킬 수 있습니다.인덱스 테이블 영역에서만 문제가 발생하는 경우 온라인으로 복구할 수 있으며 애플리케이션은 고객이 계속 사용할 수 있습니다.참고 항목: http://richardfoote.wordpress.com/2008/05/02/indexes-in-their-own-tablespace-recoverability-advantages-get-back/
• 인덱스, 데이터, Blob, Clobs를 위해 별도의 테이블스페이스를 사용하는 것은 궁극적으로 일부 개별 테이블이 관리 용이성과 비용에 중요할 수 있습니다.스토리지 시스템을 사용하여 BLOB, Clobs를 저장한 후 서비스 품질이 서로 다른 다른 스토리지 계층에 아카이브할 수 있습니다.

언급URL : https://stackoverflow.com/questions/1819522/is-there-any-logical-reason-of-having-different-tablespace-for-indexes