Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Непоянтный размер бекапа.
|
|||
|---|---|---|---|
|
#18+
Добрый день. У меня что то последнее время стал очень быстро расти размер бекапа. Вчера когда оставалось на диске всего 200 mb начал просматривать базу и нашол в ней таблицу которая не чистилась уже несколько лет и в которой накопилось 20 млн записей. Удалил половину данных из таблицы , но место того что бы уменьшится бекап еще и разросся и сожрал оставштеся 200 мб. Подскажите из за чего такое может быть ? У меня стоит IDS 9.4 пишу бекап в файл ontape -om ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2008, 11:17 |
|
||
|
Непоянтный размер бекапа.
|
|||
|---|---|---|---|
|
#18+
Бэкап сервера состоит из бэкапа журналов + бэкап пространств данных. Если на сервере идет много транзакций, то кол-во архивированных файлов журналов тоже будет расти. Вот вы удаляли записи из таблицы, и эти операции удаления писались в лог (если база с журналированием), который соответственно бэкапился. Если бэкапы не удалять, то они будут занимать все больше места, как ни странно. Далее есть такое понятие для бэкапа: retention policy или по русски политика хранения. Это то время, которое должен хранится бэкап (архивы пространств и журналов). Как правило эту политику должны определять пользователи данных, они решают сколько времени бизнес должен хранить архивы данных. Здесь никакого "правильного" решения не существует: для каждой "конторы" применимы свои правила хранения архивов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2008, 11:31 |
|
||
|
Непоянтный размер бекапа.
|
|||
|---|---|---|---|
|
#18+
Я может немного не правильно задал вопрос . Из за чего у меня после удаления большого количества данных , не уменьшился размер базы данных ? Я удалил очень много , но при этом я заметил что процент загружености спейса где лежит эта таблица не как не изменяется , хотя по логике вещей ведь должен был . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2008, 12:04 |
|
||
|
Непоянтный размер бекапа.
|
|||
|---|---|---|---|
|
#18+
update statstics high ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2008, 12:11 |
|
||
|
Непоянтный размер бекапа.
|
|||
|---|---|---|---|
|
#18+
А можно ли его выполнять на продакшен сервере без остановки ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2008, 13:16 |
|
||
|
Непоянтный размер бекапа.
|
|||
|---|---|---|---|
|
#18+
KyRoЯ может немного не правильно задал вопрос . Из за чего у меня после удаления большого количества данных , не уменьшился размер базы данных ? Я удалил очень много , но при этом я заметил что процент загружености спейса где лежит эта таблица не как не изменяется , хотя по логике вещей ведь должен был . Каждая таблица состоит из экстентов - непрерывных групп страниц на диске. Так вот если удалять из таблицы записи, то пустые экстенты по прежнему будут принадлежать таблице и не будут входить в свободное место на диске. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2008, 13:37 |
|
||
|
Непоянтный размер бекапа.
|
|||
|---|---|---|---|
|
#18+
авторКаждая таблица состоит из экстентов - непрерывных групп страниц на диске. Так вот если удалять из таблицы записи, то пустые экстенты по прежнему будут принадлежать таблице и не будут входить в свободное место на диске. Ну я приблизительно так и подумал . А вот как освободить их , особенно на постоянно работающей пром системе ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2008, 13:51 |
|
||
|
Непоянтный размер бекапа.
|
|||
|---|---|---|---|
|
#18+
В 7 версии информикса можно было как то освободить экстенты, а в других версиях вроде бы никак - только если сделать truncate, но это немного не то (при помощи truncate очищается вся таблица). Как вариант можно попробовать ALTER FRAGMENT ON TABLE ... INIT IN, но тут много всяких нюансов, так что это тоже не очень удобный способ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2008, 14:15 |
|
||
|
Непоянтный размер бекапа.
|
|||
|---|---|---|---|
|
#18+
Если таблица постоянно используется, то никак. Если информация из таблицы нужна, то создать еще одну таблицу, перенести туда жизненно необходимые записи. Старую таблицу грохнуть, новую переименовать. Но! Это все, если эта таблица не имеет референшел констрейнтов с другими таблицами. Ибо если они есть, процесс может затянуться на долго. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2008, 14:15 |
|
||
|
Непоянтный размер бекапа.
|
|||
|---|---|---|---|
|
#18+
KyRoИз за чего у меня после удаления большого количества данных , не уменьшился размер базы данных ? Я удалил очень много , но при этом я заметил что процент загружености спейса где лежит эта таблица не как не изменяется , хотя по логике вещей ведь должен был . Это по вашей логике. А там логика своя, вполне оправданная и обоснованная. Если в таблице уже было много данных, значит снова будут, т.е. уже выделенное пространство (экстенты) будут использоваться для вставки новых записей без выделения экстентов. А так как выделение экстентов (да еще и маленьких) довольно тяжелая операция, то зачем ее делать снова и снова ? Опять таки, вы удаляете строки ведь не подряд, а по своему критерию и почему должны будут освободиться экстенты целиком ? Для того, чтобы освободить экстент автоматом, на нем не должно быть ни одной строки, значит надо некий фоновый процесс, который бы переписывал таблицу (уплотнял строки)... Вообщем, как говорится, это by design. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2008, 18:39 |
|
||
|
Непоянтный размер бекапа.
|
|||
|---|---|---|---|
|
#18+
AndronВ 7 версии информикса можно было как то освободить экстенты, а в других версиях вроде бы никак... Как вариант можно попробовать ALTER FRAGMENT ON TABLE ... INIT IN, но тут много всяких нюансов, так что это тоже не очень удобный способ. В этом смысле 7-ка от 9-ки и 10 никак не отличается. Т.е. способы освобождения экстентов те же самые и ALTER FRAGMENT ON TABLE ... INIT IN является одним из самых удобных и быстрых. Правда для больших таблиц и не больших логов может возникнуть длинная транзакция, тогда применимы остальные известные способы (здесь они не раз упоминались). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2008, 18:43 |
|
||
|
Непоянтный размер бекапа.
|
|||
|---|---|---|---|
|
#18+
KyRoУ меня что то последнее время стал очень быстро расти размер бекапа. У меня стоит IDS 9.4 пишу бекап в файл ontape -om Можно сжимать архив "на лету" или использовать onbar с ISM-ом (у него есть опция сжатия) или просто взять новый и емкий диск (тут рейд не нужен, а 500Гб стоят меньше $150). Вам полезно будет почитать ФАК OnBar - ISM - Ontape (Archive and Restore) http://www.sql.ru/faq/faq.aspx?id=557 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.06.2008, 18:50 |
|
||
|
|

start [/forum/topic.php?fid=44&msg=35393391&tid=1608068]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
69ms |
get topic data: |
9ms |
get forum data: |
3ms |
get page messages: |
48ms |
get tp. blocked users: |
1ms |
| others: | 297ms |
| total: | 455ms |

| 0 / 0 |
