Есть ли логическая причина наличия разных табличных пространств для индексов?
привет может некоторые дайте мне знать, почему мы создали другое табличное пространство для индекса и данных.
3 ответов
широко распространено мнение, что сохранение индексов и таблиц в отдельных табличных пространствах повышает производительность. Теперь это считается мифом многими уважаемыми специалистами (см.--2-->this Ask Tom thread-поиск "мифа"), но это все еще распространенная практика, потому что старые привычки умирают трудно!
редактирование третьей стороной
извлечение из asktom: "Index Tablespace" С 2001 года для Oracle версии 8.1.6 вопрос
- это все еще хорошо идея сохранить индексы в собственном табличном пространстве?
- это производительность inhance или это больше проблема восстановления?
- отличается ли ответ от одной платформы к другой?
первая часть ответа
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 и так далее, и нет необходимости хранить индексы и таблицы в разных табличных пространствах.
но все табличные пространства должны управляться локально с равномерным расширением размера. С этой точки зрения индексы должны храниться в различные табличные пространства как таблица с 50 столбцами могут быть сохранены в табличном пространстве с размером exteds 5 Мб, когда табличное пространство для индексов будет достаточно 512kb расширенный размер.
- производительность. Его следует анализировать от случая к случаю. Я думаю, что сохранение всего вместе в одном табличном пространстве становится еще одним мифом! Должно быть достаточно шпинделей, достаточно luns и позаботиться о очереди в операционной системе. если кто-то думает, что достаточно сделать одно табличное пространство, и это то же самое, что и многие табличные пространства, не принимая во внимание все другие факторы, означает снова другой миф. Это зависит!
- Высокая Avalilability. использование отдельных табличных пространств может улучшить высокая доступность системы в случае, если какой-то файл corrution, повреждение файловой системы, блокировать повреждение. Если проблема возникает только в табличном пространстве индекса, есть желание сделать восстановление онлайн, и наше приложение по-прежнему доступно клиенту. см. также: http://richardfoote.wordpress.com/2008/05/02/indexes-in-their-own-tablespace-recoverability-advantages-get-back/
- использование отдельных табличных пространств для индексов, данных, blobs, clobs, в конечном итоге некоторых отдельные таблицы могут иметь важное значение для управляемости и расходов. Мы можем использовать нашу систему хранения для хранения наших blobs, clobs, в конечном итоге архивировать на другой уровень хранения с различным качеством обслуживания