Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
03.02.2014, 20:08
|
|||
---|---|---|---|
|
|||
dump -> copy -> load |
|||
#18+
всем доброго времени суток! делаю копию базы данных на другом сервере посредством system copy исходная база 92ГБ, дамп - 24ГБ, таргет базу создал как 65ГБ исходная база перед накаткой большого пакета саповских обновлений так распухла из-за временных таблиц, которые использовались внутри базы для теневой копии репозитария, по окончании накатки они удалились, но размер базы не сократился. как бы не напрягает, база потом на месте удаленных таблиц расти будет. (если я не ошибаюсь) собственно вопрос при попытке load database получаю ошибку Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32.
т.е. нужно было перед load database увеличить таргет базу данных также до 92ГБ? или для исходной базы нужно было выполнять truncate? ЗЫ в sybase плаваю недавно, месяца полтора. и к сожалению доки по сайбейз содержат обычно краткое описание действий администратора, с указанием на какой-то дополнительный мифический источник, в котором всё это расписано подробно... ... |
|||
:
Нравится:
Не нравится:
|
|||
|
03.02.2014, 20:14
|
|||
---|---|---|---|
|
|||
dump -> copy -> load |
|||
#18+
да, забыл про версию ASE 15.7.0.110 ... |
|||
:
Нравится:
Не нравится:
|
|||
|
03.02.2014, 20:17
|
|||
---|---|---|---|
dump -> copy -> load |
|||
#18+
1. покажите что говорит select @@version 2. собственно команды load database REP from ...... и не видно в вашем логе. >> т.е. нужно было перед load database увеличить таргет базу данных также до 92ГБ? да. документация вот: http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc36272.1570/html/commands/X28090.htm тривиальная команда загрузки дампа выглядит так load database REP from '/path/to/REP.dump' ... |
|||
:
Нравится:
Не нравится:
|
|||
|
03.02.2014, 21:13
|
|||
---|---|---|---|
|
|||
dump -> copy -> load |
|||
#18+
blzz1. покажите что говорит select @@version Adaptive Server Enterprise/15.7/EBF 21708 SMP SP110 /P/x86_64/Enterprise Linux/ ase157sp11x/3546/64-bit/FBO/Fri Nov 8 05:39:38 2013 blzz2. собственно команды load database REP from ...... и не видно в вашем логе. >> т.е. нужно было перед load database увеличить таргет базу данных также до 92ГБ? да. жаль, что до 92ГБ целевую базу нужно создавать я думал, что дамп базы мусора не содержит load database не видно, т.к. до него дело не дошло хотя подозреваю, если я смог бы выполнить load database вручную, то дальнейший процесс копирования из дампа прошел бы blzzдокументация вот: http://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.infocenter.dc36272.1570/html/commands/X28090.htm тривиальная команда загрузки дампа выглядит так load database REP from '/path/to/REP.dump' спасибо уже делал, но со сменой SIDа ещё нет... :) ... |
|||
:
Нравится:
Не нравится:
|
|||
|
03.02.2014, 23:16
|
|||
---|---|---|---|
dump -> copy -> load |
|||
#18+
jack_nskя думал, что дамп базы мусора не содержитЭто дамп . В буквальном значении слова. Если ты хочешь данные без накопленного за годы мусора, надо делать ручное перекачиваниее. Отдельно создавать все объекты, отдельно переносить юзеров (не уверн что это вообще возможно без дампа) и отдельно bcp out собственно данных. Увы. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
03.02.2014, 23:32
|
|||
---|---|---|---|
|
|||
dump -> copy -> load |
|||
#18+
White Owl, ну я с сайбейзом дела ранее не имел... в Firebird достаточно было сделать бэкап/рестор и весь версионный мусор во вновь созданную базу не перетекал, база становилась меньше, особенно после удаления части таблиц в оракле пользовался brtools-ами там можно было грохнуть неиспользуемые тейблспейсы а как в сайбейзе удалить для базы 30 гигов пустого места, образовавшегося после большой накатки - увы, пока не знаю даже не знаю, возможно ли это. как бы теоретически можно конечно создать дополнительный девайс для базы, reorg туда примерно 60 000 саповских таблиц, но сдается мне - это затея того не стоит... проще смириться с лишними 30 гигами :) ... |
|||
:
Нравится:
Не нравится:
|
|||
|
03.02.2014, 23:34
|
|||
---|---|---|---|
|
|||
dump -> copy -> load |
|||
#18+
забыл про собственно database... :) Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51.
... |
|||
:
Нравится:
Не нравится:
|
|||
|
04.02.2014, 00:16
|
|||
---|---|---|---|
dump -> copy -> load |
|||
#18+
jack_nskWhite Owl, ну я с сайбейзом дела ранее не имел... в Firebird достаточно было сделать бэкап/рестор и весь версионный мусор во вновь созданную базу не перетекал, база становилась меньше, особенно после удаления части таблицFirebird это изначально моно-пользовательская база. На этом классе СУБД действительно есть смысл сокращать размер файла базы, потому что она хранится на юзерском компьютере. jack_nskв оракле пользовался brtools-ами там можно было грохнуть неиспользуемые тейблспейсыТак ты не путай tablespace и пустое место. То что в Оракле называют tablespace в ASE называют database. И их можно создавать и удалять как душе пожелается. Ну с теми же ограничениями которые тебе знакомы (я надеюсь) по Ораклу. jack_nskа как в сайбейзе удалить для базы 30 гигов пустого места, образовавшегося после большой накатки - увы, пока не знаю даже не знаю, возможно ли это.Возможно конечно. Но бессмысленно. Но возможно. alter database mydb on mydevice=1M и твои волосы будут шелковисты.... но не долго :) jack_nskкак бы теоретически можно конечно создать дополнительный девайс для базы, reorg туда примерно 60 000 саповских таблиц, но сдается мне - это затея того не стоит... проще смириться с лишними 30 гигами :)Ну так эти 30Г будут заполняться данными в будущем... Если место освободилось - оно будет использовано повторно. Какой смысл отбирать у базы зарезервированное место? Я могу придумать только один случай когда это могло бы быть полезным - база целиком уходит в архив и не будет более никогда изменяться. Тогда действительно можно сделать перезаливку базы с удалением ненужных выделенных объемов. Во всех остальных случях: место лишним не бывает. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
04.02.2014, 06:10
|
|||
---|---|---|---|
|
|||
dump -> copy -> load |
|||
#18+
White Owl, спасибо за разъяснения. :) в моем случае с Firebird я ужимал базу не потому, что она храниться на компе пользователя, она на сервере и очень активно используется в многопользовательском режиме на сервере баз данных в аналитическом режиме. просто в моем случае сокращение размера базы связано с тем, чтобы физический размер базы более менее соответствовал размеру оперативной памяти. такая вот "in-memory database" получилась в итоге... :) когда первый раз увидел сайбейз я для себя эту аналогию примерную и ввел, что тайблспейс в оракле почти похож на database в сайбейз. просто у САПа есть специфика, когда производишь апгрейд, содержимое базы, которое относится к платформе NetWeaver переезжает в новый тайблспейс, например PSAPSR3731 -> PSAPSR3740 исходный тейблспейс размером на 100 гигов остается практически пустой и мозолит глаза при создании бэкапов, тратя время и место. reorg-ом перемещаю оттуда пару-тройку оставшихся таблиц/индексов и грохаю этот ненужный более тайбспейс. в сайбейз САП хранит свои данные не на рассыпухе дата-файлов, а в одной database (за исключением служебной инфы), так что все мои телодвижения как оказалось стали не нужными... :) спасибо ещё раз, что развеял остатки моих сомнений! :) когда я осознал всю глубину моих заблуждений, то target database создал с размером чуть больше исходной и копирование САП системы с копированием базы прошло на ура. правда на синтаксис "alter database mydb on mydevice=1M" у меня руганулось, что "on" нераспознанная ошибка и не получилось выполнить "alter database ..." по причине, что база создана "for load". пока не разобрался, как это победить. так вот, шаг за шагом выхожу из непоняток, в т.ч. и благодаря вашим ценным подсказкам. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
|
04.02.2014, 10:41
|
|||
---|---|---|---|
dump -> copy -> load |
|||
#18+
Начиная с ASE 15.7 SP100 есть фича Shrinking Databases In Adaptive Server versions 15.7 SP100 and later, use the alter database command to shrink databases, freeing unused space for reuse or deletion. If Adaptive Server encounters data on the portion of the database you are shrinking, it moves the data to a new location before removing the space from the database. Once the portions to be removed are empty, the physical storage is replaced by references to a null device, which frees the space and makes it available for reuse or deletion. You can shrink databases that are online and in use. http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc00641.1570100/doc/html/mas1343943801545.html ... |
|||
:
Нравится:
Не нравится:
|
|||
|
04.02.2014, 14:29
|
|||
---|---|---|---|
|
|||
dump -> copy -> load |
|||
#18+
scroodj, спасибо. надо будет попробовать. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
04.02.2014, 16:38
|
|||
---|---|---|---|
dump -> copy -> load |
|||
#18+
jack_nskв сайбейз САП хранит свои данные не на рассыпухе дата-файлов, а в одной database (за исключением служебной инфы), так что все мои телодвижения как оказалось стали не нужными... :) база Sybase ASE состоит из: 1) сегментов 2) которые базируюся на девайсах 3) которые могут представлять собой в том числе файлы так что со стороны операционки база может выглядеть как набор файлов на файловой системе jack_nskправда на синтаксис "alter database mydb on mydevice=1M" у меня руганулось, что "on" нераспознанная ошибка и не получилось выполнить "alter database ..." по причине, что база создана "for load". пока не разобрался, как это победить. так добавь к команде alter в конец "for load" вот так : Код: sql 1.
... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.02.2014, 08:43
|
|||
---|---|---|---|
|
|||
dump -> copy -> load |
|||
#18+
komrad, спасибо! - "решительный шаг вперёд есть следствие жесткого пинка сзади!" ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.02.2014, 17:02
|
|||
---|---|---|---|
|
|||
dump -> copy -> load |
|||
#18+
scroodj, тут SAP and Microsoft do not recommend shrinking the Data files. для sybase ASE возможно такая же рекомендация... ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.02.2014, 18:32
|
|||
---|---|---|---|
dump -> copy -> load |
|||
#18+
Слова взяты из воздуха...Да и вообще речь идет у них о реалокейт спейс. Там какой-то испорченый телефон)) ... |
|||
:
Нравится:
Не нравится:
|
|||
|
06.02.2014, 19:16
|
|||
---|---|---|---|
|
|||
dump -> copy -> load |
|||
#18+
scroodj, да, поддерживается. проверил. заявлено в САПовской ноте Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.
1881347 - SYB: Can the ASE database or the database log be shrunk? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
20.03.2014, 10:52
|
|||
---|---|---|---|
dump -> copy -> load |
|||
#18+
jack_nsk, так удалось попользовать шринк? Какие впечатления? Сложилась подобная ситуация - надо "отрезать" от базы неиспользуемое место, которого скопилось достаточно много после использования компрессии, а в целом "боевая" база в состоянии практически "не растущей", за счет существующих механизмов клининга данных. А каждый ГБ на основной базе денег стоит, соотв. смысла в резерве не вижу. Но есть желание услышать были ли какие-то "особенности" при использовании "шринкования"? Или все прошло штатно? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
|
start [/forum/topic.php?fid=55&tablet=1&tid=2009865]: |
0ms |
get settings: |
9ms |
get forum list: |
16ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
34ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
104ms |
get tp. blocked users: |
2ms |
others: | 289ms |
total: | 477ms |
0 / 0 |