SAPфорум.RU
https://sapboard.ru/forum/

Дефрагментация продуктивной базы
https://sapboard.ru/forum/viewtopic.php?f=14&t=95701		 Страница 1 из 1
Автор:  RikoNw [ Ср, ноя 08 2017, 17:25 ]
Заголовок сообщения:  Дефрагментация продуктивной базы
Добрый день !
Планирую проводить работы по выделению датафайлов продуктивной базы на отдельный диск, о чем спрашивал ранее в http://sapboard.ru/forum/viewtopic.php?f=14&t=95541

Алгоритм:
0. Остановить систему
1. Подключить новый диск
2. Создать табличное пространство PSAPSR3NEW такого же объема
3. Проверить ТП PSAPTEMP на достаточный объем
4. Выполнить перемещение таблиц (brspace -u / -f tbreorg -s PSAPSR3 -t "*" -n PSAPSR3NEW -p 16)
5. Проверить что в ТП не осталось таблиц типа plan_table и индексов.
5. Дропнуть старое ТП. (brspace -u / -f tsdrop -t PSAPSR3)
6. Переименовать ТП. (brspace -u / -f tsalter -a rename -t PSAPSR3NEW -n PSAPSR3)
7. Пересобрать статистику (brconnect -u / -c -f stats -t PSAPSR3 -f collect -p 4)

Это должно:
0. Датафайлы будут на отдельном диске
1. Уменьшить объем базы (на 20% по моим подсчетам)
2. Дефрагментировать ее

Все правильно, я ничего ведь не забыл ? :roll:
Ес, ноу, камелот, советы, замечания, предложения? Спасибо!

З.Ы. Конфига: VmWare + Windows + Oracle
Автор:  bdmalex [ Ср, ноя 08 2017, 23:59 ]
Заголовок сообщения:  Re: Дефрагментация продуктивной базы
RikoNw написал:
Все правильно, я ничего ведь не забыл ? :roll:
Ес, ноу, камелот, советы, замечания, предложения?

...
А разве после 4 пункта для перемешённых таблиц индексы не развалятся ?¿?
Автор:  Skif [ Чт, ноя 09 2017, 08:50 ]
Заголовок сообщения:  Re: Дефрагментация продуктивной базы
RikoNw написал:
Добрый день !
Проверить ТП PSAPTEMP на достаточный объем

:P
p.s. алгоритм в целом правильный, только дефрагментация тут ни при чём, а вот для включения компрессии - самое то.
Автор:  RikoNw [ Чт, ноя 09 2017, 09:06 ]
Заголовок сообщения:  Re: Дефрагментация продуктивной базы
Skif написал:
RikoNw написал:
Добрый день !
Проверить ТП PSAPTEMP на достаточный объем

:P
p.s. алгоритм в целом правильный, только дефрагментация тут ни при чём, а вот для включения компрессии - самое то.


Делал на копии - объем данных в табличных пространствах упал на 20%, какие-то таблички посдувались думается...
А разве это не назвать дефрагментацией ? Ведь экстенты табличкек в новом ТП уложатся по порядку, да, скорости это не прибавит, но термин вроде употребим :D
Автор:  RikoNw [ Чт, ноя 09 2017, 09:08 ]
Заголовок сообщения:  Re: Дефрагментация продуктивной базы
bdmalex написал:
RikoNw написал:
Все правильно, я ничего ведь не забыл ? :roll:
Ес, ноу, камелот, советы, замечания, предложения?

...
А разве после 4 пункта для перемешённых таблиц индексы не развалятся ?¿?


Как я понимаю, индексы тоже перемещаются, бывает, застревают некоторые, но их удаляешь из database utility в SAP, пересоздаешь и они создаются не в старом в табличном пространстве, а в том, где лежит индексируемая таблица.
Автор:  Skif [ Чт, ноя 09 2017, 15:03 ]
Заголовок сообщения:  Re: Дефрагментация продуктивной базы
RikoNw написал:
А разве это не назвать дефрагментацией ? Ведь экстенты табличкек в новом ТП уложатся по порядку, да, скорости это не прибавит, но термин вроде употребим :D

раньше в операционных системах надо было делать дефрагментацию вручную регулярно - они не умели разбивать файлы :)
Автор:  RikoNw [ Пт, ноя 10 2017, 09:34 ]
Заголовок сообщения:  Re: Дефрагментация продуктивной базы
Skif написал:
RikoNw написал:
А разве это не назвать дефрагментацией ? Ведь экстенты табличкек в новом ТП уложатся по порядку, да, скорости это не прибавит, но термин вроде употребим :D

раньше в операционных системах надо было делать дефрагментацию вручную регулярно - они не умели разбивать файлы :)


Во, нашел:
Effects of a Reorganization
A reorganization can have the following positive effects on the database:

The data from one object can be merged into a single extent or into fewer extents.
The data from a tablespace with many small files can be merged into one or more larger data files.
Freespace fragments in an object are merged into larger freespace segments if reorganized into a new tablespace. This process is called “defragmentation”.
The fill level in the individual blocks is evened out, so reducing internal fragmentation.
Data chains are resolved in most cases.
Автор:  sap2me [ Пн, ноя 20 2017, 05:13 ]
Заголовок сообщения:  Re: Дефрагментация продуктивной базы
RikoNw написал:

Делал на копии - объем данных в табличных пространствах упал на 20%, какие-то таблички посдувались думается...
А разве это не назвать дефрагментацией ? Ведь экстенты табличкек в новом ТП уложатся по порядку, да, скорости это не прибавит, но термин вроде употребим :D

тут какое дело:в нормальной системе где есть админ проводятся регулярные чистки (раз в год к примеру). И если после чистки что-то "двигать", то размер БД конечно уменьшится, но за год опять же отрастет на столько же, а скорее всего еще чуть больше (за счет неудалямых данных). То есть получается много работы в перспективе с незаметным выхлопом. Это один момент.

Другой состоит в том, что в САПе мульён таблиц из которых непустых 2 сотни и из которых 2 десятка в сумме дают 90% размера всей БД. Вот их и можно индивидуально чистить и мувать.

Более перспективно, кмк, в САПе было бы таблицы с данными секционировать - секции с данными которые уже не будут меняться переносить в отдельное ТП и делать его ридонли. В перспективе можно было бы получить что на террабайтной БД у вас 600 гиг в РО и никак не бэкапятся (только один раз) и и это сильно бы упрощало всякие миграции и создание копий. Но я не встречал, чтобы САП хотя бы упоминал об этой отдушине админа. В тренде: знай наращивай размеры полок и скоростя дисковых массивов. ((
Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/