Файл табличного пространства

Dima_NN
Дата: 29.07.2005 11:05:22
КАк правильно увеличить файл табличного пространства?
Partos
Дата: 29.07.2005 11:32:45
Он увеличивается сам в зависимости от потребностей заполнения данного табличного пространства....при условии что у Вас стоит возможность автоматического расширения этого файла....
(вот пример как включить: ALTER DATABASE DATAFILE '/oracle/zapad/example01.dbf' AUTOEXTEND ON MAXSIZE UNLIMITED)
и каждый раз будет увеличиваться на заданную величину
(ALTER DATABASE
DATAFILE '/oracle/zapad/example01.dbf' AUTOEXTEND
ON NEXT 100М MAXSIZE UNLIMITED)

тоесть если табличному пространству не будет хватать 100 килобайт оно всё равно увеличится на 100М....про запас так сказать...но очень маленькой эту величину тоже не стоит делать...есть причины

Т.е. если в табличном пространство, к которому относится Ваш файл (или группа файлов) полностью забито и надо добавить в него "информации" то расширяется один или несколько файлов, принадлежащих к этому табличномцу пространству сам.
Partos
Дата: 29.07.2005 11:38:15
А, забыл сказать...
Если же всё-таки стоит делом принципа увеличить размер файла то пожалуйста:

ALTER DATABASE DATAFILE '/u02/oracle/rbdb1/stuff01.dbf'
RESIZE 100M;

Где указывайте любую величину...но по-моему этого не стоит делать....поскольку потом ужать этот файл не всегда представляется возможным
Oleg Afanasiev
Дата: 29.07.2005 11:41:06
"Правильно" будет расчитать тенденцию роста БД
и создать нужное количество файлов данных для ТП,
а в случае нехватки места - добавить ещё файл(ы).


-----------------------
Вечны налоги,
Смерть и потеря данных.
Что на этот раз?
Картинка с другого сайта.
Dima_NN
Дата: 29.07.2005 12:47:02
Тут такая ситуация: разворачивал приложение и создал TableSpace с размером файла данных 250М а разработчики рекомендуют 500М. Перед изменением нужно тушить instance? И чем нужно менять SQL+ или можно SVRMGRL?
Oleg Afanasiev
Дата: 29.07.2005 12:55:33
Не нужно.
Чем хочешь.

по документации SVRMGRL - рудимент. ( о каких я словей знаю )



-----------------------
Вечны налоги,
Смерть и потеря данных.
Что на этот раз?
Картинка с другого сайта.
Владимор Конев
Дата: 29.07.2005 12:57:19
Oleg Afanasiev
по документации SVRMGRL - рудимент.
А может атавизм? ;-)
Partos
Дата: 29.07.2005 13:37:34
Oleg Afanasiev
"Правильно" будет расчитать тенденцию роста БД
и создать нужное количество файлов данных для ТП,
а в случае нехватки места - добавить ещё файл(ы).


-----------------------
Вечны налоги,
Смерть и потеря данных.
Что на этот раз?
Картинка с другого сайта.


А почему это правильно??? Почему "Неправильно" чтоб отношение "табличное пространство: файл БД" было один к одному????

По-моему, (может я не прав...тогда объясните плиз) есть смысл распихивать табличное пространство по разным файлам когда распихиваешь эти файлы по разным дискам для так сказать "убирания горячих мест ввода-вывода".

Если же например используется RAID5 или вся база лежит на одном диске (или даже все файлы одного табличного пространства будут лежать на одном диске) то наврятли стоит плодить несколько файлов к одному табличному пространству...

Если я не прав - поправте пожалуйста и объясните почему мои мысли неправильны
Partos
Дата: 29.07.2005 13:39:12
Владимор Конев
Oleg Afanasiev
по документации SVRMGRL - рудимент.
А может атавизм? ;-)


Товарищи...не давите интелектом... :) тут и так человек в потерях насчёт Oracle а как Вас послушает так и Oracle и DBA будет обходить стороной :)
Oleg Afanasiev
Дата: 29.07.2005 14:04:38
Это уже столько раз обсуждалось!!!
Вбей в поиск слово autoextend.

Из того что помню(для ТП с данными):
- проблема с количеством блоков в 1 датафайле
- ограничение на размер датафайла


-----------------------
Вечны налоги,
Смерть и потеря данных.
Что на этот раз?
Картинка с другого сайта.