Добро пожаловать в форум, Guest >> Войти | Регистрация | Поиск | Правила | | В избранное | Подписаться | ||
Все форумы / Microsoft SQL Server |
![]() ![]() |
prog01 Member Откуда: Сообщений: 72 |
допустим полная модель восстановления и полная копия делается раз в неделю раз в день делаются разностные раз в полчаса журнал транзакций ну или как-то так может быть журнал будет раз в 15 минут а разностные раз в два часа а полная раз в день вопрос: в какой момент при таком подходе можно сокращать журнал транзакций? в какой момент ... делать шринк базы? ... делать шринк файлов? и не решает ли этих проблем автошринк в настройках базы? |
19 сен 12, 16:04 [13190292] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104751 |
Зачем вообще делать сжатие ? |
||
19 сен 12, 16:08 [13190327] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31785 |
Шринк можно делать после каких то нештатных ситуаций (например, переделали кластерный индекс для большой таблицы, занимающей 90% базы) |
||
19 сен 12, 16:10 [13190356] Ответить | Цитировать Сообщить модератору |
prog01 Member Откуда: Сообщений: 72 |
в какой момент его делать? только перед созданием очередной полной копии? |
||||
19 сен 12, 16:27 [13190548] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104751 |
после каких то нештатных ситуаций |
||
19 сен 12, 16:28 [13190561] Ответить | Цитировать Сообщить модератору |
prog01 Member Откуда: Сообщений: 72 |
только вопрос в призяке к контексту, чтобы не нарушить последовательность копий, сжатие когда можно делать? http://msdn.microsoft.com/ru-ru/library/ms190217(v=sql.105).aspx на мой взгляд перед полной копией |
||||
19 сен 12, 16:37 [13190652] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104751 |
сжатие никак не может нарушить последовательность бэкапов. |
||
19 сен 12, 16:39 [13190680] Ответить | Цитировать Сообщить модератору |
prog01 Member Откуда: Сообщений: 72 |
так вот и вопрос о том и есть что учитывает ли сжатие модель восстановления |
||||
19 сен 12, 16:53 [13190849] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104751 |
сжатие есть процесс возврата свободного(!) места оп.системе как на это должна влиять модель восстановления, если при этом никакие данные не меняются ? |
||
19 сен 12, 16:56 [13190876] Ответить | Цитировать Сообщить модератору |
prog01 Member Откуда: Сообщений: 72 |
но ведь журнал транзакций при этом уменьшается почти до нуля, по крайней мене при простой модели восстановления а я спрашиваю как это будет на полной |
||||
19 сен 12, 18:01 [13191286] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104751 |
Еще раз сжатие - это процесс возврата свободного места. Какая разница что за модель, если свободное место в любой модели выглядит одинаково. Вы просто плохо представляете себе, когда в разных моделях место, занятое транзакцией, становится свободным. |
||
19 сен 12, 18:05 [13191307] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31785 |
Поэтому если была нештатная ситуация, и файл лога стал очень большой, то лучше сделать шринк до бакапа, чтоб не было проблем с местом при восстановлении. Ни на что остальное, как уже сказал Glory, это не повлияет. Главное, не делать шринк, если не было нештатной ситуации. |
||
19 сен 12, 19:02 [13191561] Ответить | Цитировать Сообщить модератору |
prog01 Member Откуда: Сообщений: 72 |
т.е. в 2008 r2 нет проблемы разрастания лога? если есть то как его сокращать? |
||||
20 сен 12, 13:54 [13195903] Ответить | Цитировать Сообщить модератору |
prog01 Member Откуда: Сообщений: 72 |
а если auto shrink стоит тогда не надо? |
||||
20 сен 12, 16:48 [13197471] Ответить | Цитировать Сообщить модератору |
prog01 Member Откуда: Сообщений: 72 |
вообще шринк датабасе и шринк файл только после нештатных ситуаций делать или их вполне можно делать непосредственно в цепочке резервного копирования по времени, т.е. напрмер модель полная баки делаются и ещё одним расписанием раз в сутки эти шринки? |
20 сен 12, 16:51 [13197487] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31785 |
Только нужно установить режим "не сохранять старые ненужные записи в логе", если вам действительно не нужно эти старые записи хранить для каких то ваших целей. |
||||
20 сен 12, 16:51 [13197488] Ответить | Цитировать Сообщить модератору |
prog01 Member Откуда: Сообщений: 72 |
alexeyvg, не сохранять старые ненужные записи в логе - как? |
20 сен 12, 16:54 [13197506] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31785 |
Шрик базы вообще приводит к её порче, хоть заново создавай. Шринк лога безопасен, но скорость уменьшает на некоторое время. Вам это уже написали по несколько раз, сколько можно? Распечатайте этот тред, прочитайте, отметьте непонятные фразы, задавайте конкретные вопросы, а не повторяйте одно и то же!. |
||
20 сен 12, 16:54 [13197510] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31785 |
|
||
20 сен 12, 16:55 [13197516] Ответить | Цитировать Сообщить модератору |
Glory Member Откуда: Сообщений: 104751 |
У вас каша в голове. Все буквы знаете, а слово угадать не можете |
||
20 сен 12, 16:55 [13197518] Ответить | Цитировать Сообщить модератору |
prog01 Member Откуда: Сообщений: 72 |
alexeyvg, т.е. если как у меня однажды было база до шринка была 35 послке стала 9 гигов или в другом случае после шринка файла изменилась с 75 на 50 гигов то в обоих случаях ничего хорошего я не сделал? |
20 сен 12, 16:57 [13197526] Ответить | Цитировать Сообщить модератору |
alexeyvg Member Откуда: Moscow Сообщений: 31785 |
В первом случае в принципе если размер файла данных будет стабильно 9, то можно сделать, но только шринк одного файла и без реорганизации данных. |
||
20 сен 12, 17:02 [13197557] Ответить | Цитировать Сообщить модератору |
prog01 Member Откуда: Сообщений: 72 |
кажется что-то понял ))) всем большое спасибо!!! |
20 сен 12, 17:16 [13197645] Ответить | Цитировать Сообщить модератору |
Все форумы / Microsoft SQL Server | ![]() |