Собственно прикол неприкольный:
есть база, MDF гдето мегов 800
есть бекап - фулбекап средствами SQL  - тоже мегов гдето 800.

восстанавливаю в новую базу - пишет заммечательную фразу про то что нехватает места на диске для восстановления.

это при том что на диске свободных 150 гигов.


сталкивались?

причем в настройках бекапа стоит флажок проверки..

у тебя лог пухнет, перенеси лог новой базы на пустой терабайтник и модель поставь семпл

а файло скульное точно на этом диске лежит, и на него востанавливается.

(2) для гиговой базы лог больше чем 150 гб? быть не может.

(2) в том то и дело  что модель семпл была у исходной базы.
лог - неуспевает распухнуть - то есть размер тупо не меняется.

(3) файло лежит там же..
причем пробовал и в пустую новую и в старую восстанавливать..

(4) симпле

автоприращение "вкл"?

темпдб по умолчанию на диске ц, посмотри свободное место там

а вообще лог должен пухнуть при востановлении

(6) угу.. стандартные 10% неограниченные

>а вообще лог должен пухнуть при востановлении

да, но не на 150 Гб.

глупый вопрос - а диск не на fat32?

да непухнет там ничего
оно даже не начинает восстанавливаться - мгновенно вырубается с ошибкой

причем самый прикол в том что я на виртуалке поднял СУБД - там тоже не грузится...ровно с такой же причиной

(9) при востановления гига даже больше, друге дело что сразу после он шринкуется...

(10) бгыы фат16 епта...
ясное дело что нет :)

причем оригинальный сервак x64 сервер 2003тий
виртуалка - XP 32p

(12) >друге дело что сразу после он шринкуется...

это понятно - контрольная точка наступает...

(13) служба скуля от кого крутится?

вот чо пишет http://gyazo.com/7b2f1d83fa67e8917f36ca900935ebb3

(15) гы...

(14)  под системной учеткой

может, бэкап битый?

220 гигов - многовато

(18) прикол в том что бекапит без проблем.. в плане стоит проверка бекапов... и так восстанавливаются ВСЕ бекапы (они каждый день делаются полные) - вернее ВСЕ бекапы с такой ошибкой восстанавливаюстя - вернее невосстанавливаются.

(19) угу.. это скрин с виртуалки где всего 10 гигов..  :)

что говорит тестирование бэкапа?

(22) + и базы?

а нагуя ты его на С: восстанавливаешь? попробуй восстанови на Д:
и мдф и лдф

(23) база рабочая.. без проблем все.. просто надо было восстановить на предмет "чо было до обновления" :)
бекапы бекапятся.. флажок "верифи бекап интегрити" стоит и ошибок не выдает - все бекапится как положено...

(24) это виртуалка - на ней нет Д.
на рабочем серваке где Д 150 гигов - пробовал туда восстановить - та же херь...

а что за база? 1с? или чо?

(27) 1С, 1С... типовая бухня...

(26) ну найди диск с 300 гигами и восстанови туда

(28)если сделать выгрузку - сколько она занимает? и восстанавливается ли?

тааааак.... а у тебя бэкапится не транзакшн лог случаем???

+31 и может это только дельта на 200 мегов?

+32 и вообще. С: под ось, Д: под мдф, Е: под лдф

что говорит restore headeronly ? там точно просто фулбекап?

Глава корпорации Microsoft Билл Гейтс в 1981 г. считал, что "640 килобайт памяти должно быть достаточно для каждого компьютера"

о! попробуй восстановить бэкап не на точку "бэкапирования" а на секунду пораньше

>о! попробуй восстановить бэкап не на точку "бэкапирования" а на секунду пораньше

это каким манером из фулбэкапа то?

(37) указать дату и время в поле "To a point in time"

Ща домой приеду - скормлю ему террабацтник. Пусь подавиться сволоч.

(38) я может чё не понимаю, но для симпл-базы и фулл-бэкапа это какую роль сыграет?

(38) и давно фулбэкап научился работать с "To a point in time"?

(41) терзают меня сомнения что там как раз не фулл и не симпл

(42) а спросил про это в (34)

(15) Правильно пишет. На диске С у вас действительно недостаточно места.
И если будете задавать вопрос - какого хрена? Тогда вам нужно один раз взять урок у админа и забыть о проблеме.

IamAlexy , отпишись по результатам, пожалуйста

(44) расскажи это диску Це у которого 140 гигов свободно...
(45) угу.. поднимаю виртуалку на террабайт.. буду тестить седня

(43) не.. фул фул.. в настройках бекапа по крайней мере стоит что фул и что проверять и тд и тп - то есть типические настройки.. совсем обычные...

(47) тупой вариант:
выгрузить в dt
создать новую базу на сиквеле
загрузить из dt
забэкапить
попробовать восстановить

и таким образом понять где локализована ошибка ?

(48) я уже предлагал

(48) есть выгрузка.. все нормуль и тудым и сюдым восстанавливается.

прикол в том что есть грубо говоря "вчерашний" бекап от которого выгрузки в dt нет, а очень хочется глянуть чо в базе было именно вчера...

ща ща ща.. террабайтная виртуалка поднимется - посмотрим чо оно скажет :)

(50) скока весит?

(52) ?

бак - весит 800 метров
дт - 250 - но там конфа с разрешенными изменениями.. то есть 2 цфника... то есть нормальный размер

Вот что мне в скуле не нравиться, так это такие вот моменты.
Вроде душа спокойна, куча бэкапов валяется где попало, а как понадобится восстановить, так хрен.

(50) ты не въехал

создай новую базу через dt и проверь для неё валидность скулевских бэкапов

(54) вот по этому и дублируется все выгрузками в DT
правда тут никто блин не контролировал - неделю выгрузки не делались - то сеанс висел то еще чо...

в результате как раз и потребовалось поднять данные за тот период где нет бекапов...

а скуль подвел..

(55) я тупой.. как проверить валидность скулевских бекапов ?

(57) бэкап - ресторе ясен пень

но загрузив из dt ты исключишь наличие внутри какого-нибудь говна вроде не закрытой транзакции

(56) на всякий случай,
путь то к базе при ресторе ты менять пробовал

(58) я ресторе пытаюсь вообще в пустую базу восстановить - один хрен..
я же выше писал..
и в пустую пытался, и в базу которую из ДТ поднимал..
вообще пофиг

попробуй RESTORE FILELISTONLY  , чтобы зырнуть размеры файлов.

и всё-же, сдавлю дайм на разбухшие логи

(46)(60) Это не скуль тупой. Это вы тупите на пустом месте. Если он вам написал что нету места - значит его нету. И нефиг железку мучить.

(62) плять.. там места 140 гигов..  выгрузка 800
база в симпл режиме работает и занимает вместе с ldf порядка гига... ну реально  - гиг...
840 мегов мдв и 200 - лдф...

(60)[я ресторе пытаюсь вообще в пустую базу восстановить - один хрен.]
ещё раз
что у тебя на второй закладке  в качестве пути указано ?

(60) сделай (61), посмотри размеры файлов и где лежали...

и вообще как восстановление происходит? через gui или скрипт?

(64) как новые имена файлов так и старые указывал - поверх восстановленной.
то есть отключал рабочую базу, переименовывл файлы даных, восстанавливал из имеющегося DT и пробовал в нее из скульного бекапа восстановить.

когда получил ошибку об отсутствии мест - переименовал файлы даннх и попробовал в новые - один фиг..

(65) через гуи.. я что, линупсоид чтоли.. через скрипты восстанавливать...

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

хз хз.. ща тестовый виртуальный сервак запустится.. там ща тупорылые фремворки ставятся...
там террабайт места - посмотрим посмотрим..

(67) gui выкинть нах... или хотя бы сгенери по кнопке скрипт и посмотри что происходит на самом деле

блин, чё-то sql.ru лежит...

(63) Для тех кто в танке - картинка показывает что на диске С свободно всего лишь 10 Гиг.
На виртуалке поднимаете?

(72) для тех кто в таке - я же там писал что это уже картинка  с виртуалки - оно тоже самое писало на физике с 140 гигами свободными

скриншот ошибки сделай

еще бы это проверить:
http://ask.sqlservercentral.com/questions/24553/there-is-insufficient-free-space-on-disk-volumeto.html

может кто в свойства базы залез не удачно и сменил " initial size value"

короче, я мыслю так: есть размер данных базы, а есть размеры файлов базы. и, как говорят в Одессе, это две большие разницы. в этом направлении и надо копать

и тогда любая база новая будет стремиться отожрать место сколько указано в свойствах...

(76) +100

(76) угу.. яж выше писал размеры файлов базы восстановленной из ДТ... 800+200

(73) Тогда с определенной вероятностью виртуалка у вас с динамическим диском. Смотрите текущее занятое место, добавьте 40 Гиг и сделайте размер фиксированным. Все получится.
Вот только мне так и непонятно - зачем все лепить на диск С ?.. Ну да ладно.

(80) блин.. я же писал - оно то же самое на физическом диске на рабочем сервере пишет..

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

(79) ну и когда ты посмотришь свойства базы?

(81) Неверю. Чудес небывает. Если админ у вас не дурак то он не лепит все на диск С, поэтому на рабочем вероятно что действительно нехватает места для такой глупости.

(83) скуль ставится... минут через 10 посмотрю :)
я забрал все бекапы за неделю - ща буду смтреть чо там и как...

а ты при ресторе на второй вкладке имена файлов часом не забыл поменять?

(85) и вообще при востановлении в непустую базу требуется место
старая база + новая база + лог

(85) да я пробовал пробовал... (86) да дохрена места то было.. в том то и проблема.

(87) там при рестроре есть 2 механизма, один льет прямо в файл, другой через скуль ты каким делаешь?

RESTORE FILELISTONLY
FROM DISK = '<Путь_к_файлу>'

вот же наглая скотина.. 213 гигов LDF при восстановлении...
шизануца

(90) чего и следовало ожидать :) см (2)

что-бы этого избегать читай (88) и используй механизм который льет напрямую в файл

симпл, говоришь?

(92) точно, симпл...

и ведь уже полтора часа  - восстанавливается...

(94) Что б не ждать восстановления можно пойти другим путем. Шринкуешь базу, отключаешь ее, архиватором сжимаешь mdf и ldf, забираешь архивы с собой. Дома распаковываешь архив и присоединяешь базу. Будет немного быстрее. Еще быстрее если для этого воткнешь в сервак жесткий на который будешь лить сразу mdf и ldf, минуя архиватор, потом жесткий уносишь домой.