Есть ли логическая причина наличия другого табличного пространства для индексов? - PullRequest
Новая
       33

Есть ли логическая причина наличия другого табличного пространства для индексов?

12 голосов
/ 30 ноября 2009

Привет. Может, некоторые дадут мне знать, почему мы создали другое табличное пространство для индекса и данных.

Ответы [ 3 ]

16 голосов
/ 30 ноября 2009

Широко распространено мнение, что хранение индексов и таблиц в отдельных табличных пространствах повышает производительность. Сейчас многие уважаемые эксперты считают это мифом (см. эту ветку «Спроси Тома» - ищите «миф» ), но это все еще обычная практика, потому что старые привычки сильно умирают!

Стороннее редактирование

Выписка из асктома: "Индекс табличного пространства" из 2001 для Oracle версии 8.1.6 вопрос

  • Является ли все еще хорошей идеей хранить индексы в их собственном табличном пространстве?
  • Это влияет на производительность или это скорее проблема восстановления?
  • Отличается ли ответ от одной платформы к другой?

Первая часть ответа 

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.
2 голосов
/ 30 ноября 2009

Это имеет смысл в 80-х годах, когда было не так много пользователей, а размер баз данных был не слишком большим. В то время было полезно хранить индексы и таблицы в разных физических томах.

Теперь есть логические тома, raid и т. Д., И нет необходимости хранить индексы и таблицы в разных табличных пространствах.

Но все табличные пространства должны управляться локально с одинаковым размером расширений. С этой точки зрения индексы должны храниться в другом табличном пространстве, поскольку таблица с 50 столбцами может храниться в табличном пространстве с размером 5 МБ exteds, когда табличное пространство для индексов будет иметь расширенный размер 512 КБ.

1 голос
/ 28 августа 2014
  • Производительность. Это должно быть проанализировано от случая к случаю. Я думаю, что хранение всего вместе в одном табличном пространстве становится еще одним мифом! Должно быть достаточно шпинделей, достаточно луна и позаботиться об очередях в операционной системе. если кто-то считает, что создания одного табличного пространства достаточно и оно такое же, как и у многих табличных пространств, без учета всех других факторов, это означает еще один миф. Это зависит!
  • Высокая доступность. Использование отдельных табличных пространств может улучшить высокую доступность системы в случае повреждения файлов, повреждения файловой системы, повреждения блоков. Если проблема возникает только в табличном пространстве индекса, существует возможность выполнить восстановление в оперативном режиме, и наше приложение по-прежнему доступно для клиента. см. также: http://richardfoote.wordpress.com/2008/05/02/indexes-in-their-own-tablespace-recoverability-advantages-get-back/
  • использование отдельных табличных пространств для индексов, данных, больших двоичных объектов, сгустков, в конечном итоге некоторые отдельные таблицы могут быть важны для управляемости и затрат. Мы можем использовать нашу систему хранения для хранения наших больших двоичных объектов, сгустков и, в конечном итоге, архивирования на другом уровне хранения с различным качеством обслуживания
...