Добрый день!
Кто-нибудь из вас занимался переносом таблиц в дополнительные табличные пространства меняя параметры хранения?
Например для больших таблиц типа Magoper, perevod, oborot ?
Oracle. Иземение параметров хранения таблиц.
Модератор: mike
-
- топ-софт
- Сообщения: 6
- Зарегистрирован: Пт, 23/01/2009 13:23
- Имя Фамилия: Омельянович Денис
- Откуда: ТопСофт
- Контактная информация:
Конечно :) они все описаны в документации и других официальных источниках типа металинка для Вашей конкретной версии СУБД. Кроме версии СУБД нужно определиться с количественными параметрами, характеризующими относительное понятие слова БОЛЬШОЙ :) Если у Вас таблица в 3 млн записей, то это совсем небольшая таблица с некоторых точек зрения на этот вопрос :)
Это я всё к тому, что если задавать вопрос типа "а есть ли?" скорее всего можно будет получить ответ "конечно есть!". И тогда решение растягивается на кучу страниц пустых рассуждений и ответных вопросов для вытягивания более подробной информации. А вот если задать вопрос более конкретно, типа "У нас используется версия СУБД 9i R2. В таблицах Magoper, perevod, oborot количество записей соответственно 3 млн, 20 млн, и 10 тысяч. Какие вы бы могли посоветовать более оптимальные параметры хранения для этих таблиц в данном случае?", можно получить вполне конкретный ответ. Ведь всем известно, что в хорошо построенном и заданном вопросе часто содержится довольно неплохая порция ответа на этот вопрос :)
Если брать версии 10g то там достаточно автоматизировано много вопросов, связанных с физическим хранением информации. Если версии 9i - то можно будет попробовать подумать и что-то предложить в конкретном случае. Одно можно сказать точно для любой версии - индексы и таблицы лучше разносить по различным физическим устройствам хранения (рейд-контроллеры/физические диски) для уменьшения конкуренции при доступе к информации. Т.е. можно залить все индексы в одно ТП, все таблицы в другое ТП, это всё дело разместить на одном рейде. Индексы для самых больших таблиц - в отдельное ТП, которое поместить на отдельное устройство, и сами таблицы в своё отдельно ТП которое так же поместить на отдельное устройство. Так же хорошо помогает применение ASM. Вообще, настройка производительности - это индивидуальное занятие в каждом конкретном случае. Общие рекомендации конечно же существуют и их много, но вот всё же чаще используются индивидуальные подходы с учетом специфики конкретного случая.
Это я всё к тому, что если задавать вопрос типа "а есть ли?" скорее всего можно будет получить ответ "конечно есть!". И тогда решение растягивается на кучу страниц пустых рассуждений и ответных вопросов для вытягивания более подробной информации. А вот если задать вопрос более конкретно, типа "У нас используется версия СУБД 9i R2. В таблицах Magoper, perevod, oborot количество записей соответственно 3 млн, 20 млн, и 10 тысяч. Какие вы бы могли посоветовать более оптимальные параметры хранения для этих таблиц в данном случае?", можно получить вполне конкретный ответ. Ведь всем известно, что в хорошо построенном и заданном вопросе часто содержится довольно неплохая порция ответа на этот вопрос :)
Если брать версии 10g то там достаточно автоматизировано много вопросов, связанных с физическим хранением информации. Если версии 9i - то можно будет попробовать подумать и что-то предложить в конкретном случае. Одно можно сказать точно для любой версии - индексы и таблицы лучше разносить по различным физическим устройствам хранения (рейд-контроллеры/физические диски) для уменьшения конкуренции при доступе к информации. Т.е. можно залить все индексы в одно ТП, все таблицы в другое ТП, это всё дело разместить на одном рейде. Индексы для самых больших таблиц - в отдельное ТП, которое поместить на отдельное устройство, и сами таблицы в своё отдельно ТП которое так же поместить на отдельное устройство. Так же хорошо помогает применение ASM. Вообще, настройка производительности - это индивидуальное занятие в каждом конкретном случае. Общие рекомендации конечно же существуют и их много, но вот всё же чаще используются индивидуальные подходы с учетом специфики конкретного случая.