Есть база 60 гб крутится на mssql 2008, есть несколько разработчиков. Какие есть вариант поддержания 1 тестовой базы в актуальном стостоянии (грубо говоря копии рабочей) средствами ms sql, за исключением периодического полного копирования рабочей базы?

log shipping

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

можно пробовать синхронизацию. http://habrahabr.ru/post/5274/

(2) Что значит без изменений? К примеру я пытаюсь повторить порядок действий пользователя и провожу документ, уже произойдет удаление/запись движений. В зеркале - это возможно?

проще всего backup/restore по ночам

И какая бы не была тестовая база, ошибки проведения докуменетов наверняка не отловишь.
Я обычно для этого выгрузкой-загрузкой xml документ перебрасываю

(6) если уж в копии рабочей ты не можешь ошибку поймать, то перекинув 1 документ ты точно ничего не поймеш

(5) Бекап рестор по ночам уже есть. Но этого мало, часто нужна актуальная база и приходится в тестовой базе помещаться в хранилище и накатывать актуальный бекап, а это все занимает минут 15-20 времени

(8) на автомате всмысле, копия рабочей накатывается на тестовую, скульная копия. какое хранилище ещё?

(9) Хранилище конфигурации. Так как в своей тестовой базе что-то пишу.

(10) в смысле код пишу

(7) Если тестовую делал ночью, то сегодяшнего там точно есть

(12) *Нет )))

диф бекап каждые 15 минут и при необходимости можно "догнать" рабочую

при переносе 1 документа подтягиваются все зависимые спр/доки такч то обычно достаточно

(14) у него тестовая меняется, конфа по крайней мере. на разные базы дифы накладывать разве можно?

(14) Так в копии тоже изменения происходят.

зачем тестовую менять? есть хранилище, и есть база разработки (обновляется редко, у меня раз в месяц).

тестовая нолью накатилась, потом догнался дифами и потом подключился к хранилищу, все....

это будет самым быстрым вариантом

(18) вот ошибка в рабочей, дообновил тестовую, пока ошибку исправляешь - в тестовой меняшь данные (например ошибка закрытия месяца)

Ведь имеено из-за ошибок в данных нужная тестовая, а не потомуто runtime error Выпал

(20) я имел в виду конфигу а не данные

Как вариант. Ночью фулл бэкап + диф бэкапы.
Если требуется - догоняешь до текущего состояния. Делаешь снап шот, тестируешься. Как зхакончил - откатываешь на снапшот - в итоге если возникает следующая проблема накатываешь дифы дальше

(22) снимок - очень ресурсоемкая хрень, особенно для проведения документов, там идет смесь записи и чтения, а такая комбинация для снимков резко все вешает

что значит поддерждивать в актуальном состоянии?
Вот тебе надо открыть период, ты в тестовой открыл. А в рабочей актуальное состояние - закрытый период. И что, база должна сама закрыть период?

(0)использовать планы обмена по технологии описанной в статье http://www.its.1c.ru/db/metod81#content:1511:1

В статье есть пример организации обмена для возможности отката с 8.1 на 8.0.

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

При чем если разработчик сумел в ходе тестирований при разработке слишком сильно поломать данные, в любой момент можно просто "перезалить" свежую копию рабочей базу и снова настроить обмен и сделать подключение к хранилищу. Это занимает относительно немного времени.

(24) нет, у меня как-то в эту сторону даже мысли не были повернуты. Это все делается что бы в тестовой иметь возможность отладить работу на реальных данных

(26) копируй базу и подключай заново к хранилищу

(27) Это долго. Я же уже писал. Эта процедура занимает 15-20 минут времени

(28) Спешка нужна только при ловле блох (с)

(28) Так ли часто разработчику для тестирования нужны данные на 100% идентичные актуальным из рабочей базы?

В 99% случаев за глаза и за уши достаточно данных одно-двухмесячной давности.

(30) у нас довольно часто они нужны. несколько раз в неделю кому-то из разработчиков накатывают бекап

(23) Для теста не критично, имхо.

Хотя, имхо, 20 минут на развертку теста через бэк-ап это достаточно немного...

Если минуты критичны и максимум 1 раз в день - логшиппинг. Если потребовалось, отключаете и после разбора ситуации - фулл бэкап и включить шипинг снова.

после реструктуризации

логшипинг будет раз в 10 минимум дольше.

через пакетный режим можно подключиться к хранилищу.