goldenfoodsСтандартно в студии SQL при указании места куда делать бэкап по умолчанию, только локальные диски хоста я говорю про графический интерфейс, например через план обслуживания). Может быть есть какие-то обходные пути Вы бы написали, так мол и так ( только инструкцией tsql можно или где-нибудь в свойствах чего-то поставить галочку "разрешать делать бэкапы на сетевой диск").

Нет никаких обходных путей. Есть два прямых варианта:

1. Вы руками набираете UNC путь в диалоге "Select Backup Destination";
2. Выполнятете в студии инструкцию (пример):


после чего лицезреете в диалоге Locate Database Files диск Z. И осознаете, что студия отправляте запрос серверу, узнавая, какие диски у него есть. И даже если сервер установлен у Вас локально и Вы замапили сетевой диск в своей сесии, то о нем, ну совершенно ничего не известно службе SQL сервера (которая работает "в своей сесии"), к которому запросом о наличии дисков обращается студия.

Естественно, что в 1ом, что во 2ом случае у учетной записи службы SQL Server должны быть достаточные права на ресуры. Говорить о просто наборе инструкции BACKUP DATABASE ... TO DISK = N'\\server\share...' даже не хочется.

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

Вы не порверите, возможно еще понадобиться сделать и Tail-Log Backup.

goldenfoodsЗатем их последовательно накатывать какими-то инструкциями (ручное вмешательство) . В отличии от Оракла (у которого есть замечательный rman ), где у Вас есть сразу несколько одинаковых логов транзакций лежащих в разных местах в сети даже (подмонтировали файловую систему иного сервера командой линукса маунт) и Вам просто не нужно делать бэкапы логов транзакций.

Вы знаете, в отличие от "замечательного rman" - какой-то сторонней утилиты с каким то своим "языком" (хз как работающей с сервером) все операции резервного коппирования и восстановления делаются непосредственно родными инструкциями T-SQL BACKUP и RESTORE. Которые могут быть с помощью мышечных усилий отправлены из студии - да, да, просто мышкой тыкнуть в цепочку бэкапов (дерево с галками), до кудава восстанавливать, ну, или для джедаев послать их из утилиты командной строки sqlcmd.exe.

goldenfoodspkarklin
Я не говорю, что MS SQL Server это плохо...

Вам лично, лучше и не говорить, ибо то, что Вы перечислили, и то, что я поскипал, "здесь" уже неоднократно обсуждалось. И в очень многих случаях, "нападки" сторонников Oracle, как и Вашем случае, констарировали их полную некомпетентность в СУБД, на которую осуществляется "наезд".

goldenfoodsПросто Оракл идет впереди по инновационным технологиям - это данность. И при интенсивной вставки/обновлении как раз он подходит. Он не мешает мне согласованно читать транзакционную таблицу. Очень кошерно разбивать тэйблспейс на много датафайлов, разрезать таблицу на куски и эти куски-партиции рассовывать по разным стораджам. Потом нет проблемы свободного пространства: например у Вас осталось 20 ГБ на диске, Ваши действия как администратора MS? Мои действия как администратора Оракла это просто беру еще один сторадж и командой монтирования добавляю в домашнее окружение Оракла еще один девайс.

Умоляю Вас!!! Мне сугубо параллелен инновационный Oracle. Но перестаньте здесь уже "ходить под себя", ибо Вы абсолютнй делитант в вопросах администрирования Windows и MS SQL, раз элементарная операция в Windows для Вас проблема.

Yo.!Вы знаете, в отличие от "замечательного t-sql" - какой-то убогой командой BACKUP/RESTORE с каким то своим "языком" (хз как работающей с сервером) все операции резервного коппирования и восстановления делаются в вебном Enterprise manager. Которые могут быть с помощью мышечных усилий отправлены из EM - да, да, просто мышкой тыкнуть в враздел Backup, до кудава восстанавливать, ну, или для джедаев послать их из утилиты командной строки RMAN. :P

Yo.!, ну не начинайте в 25ый раз. RMAN vs MS SQL BACKUP\RESTORE мы уже перетирали, и пришли к выводу, что и мышечного и ручного функионала полно у обоих СУБД. Лучше, своего коллегу на путь истинный наставь, а то ведь городит такое...

Andrey Sribnyakpkarklin

что бы так сделать, нужно быть как минимум администратором домена :-) Иначе административные шары не доступны :-)
Даже не представляю, зачем сервер баз данных с подобными правами запускать...

Специально для "нечиталей" я в скобках написАл ( пример ), дабы каждый даже на своем локальном компьютере, смог выполнить эту инструкциию даже если служба MS SQL работает под системной учетной записью.

ЗЫ. Не хочется возить faceом об table, но администратором домена быть совсем не обязательно, дабы юзать админские шары. Достаточно быть локальным администратором на этом хосте.