Yo.!Rus000приходится ли делать какие-то ухищрения для блокировочника, при условии что "закрыть период" не удастся ночью - ибо 24x7 или другие системные задачи отжирают ночное время?
тады только одно - выносить весь репортинг на отдельный сервер и туда или реплицировать или log shiping с oltp. но там тьма нюансов в зависимости от вендора и характера вашего oltp.
И это будет выглядеть просто, когда вы сможете перед запуском отчёта без проблем приостановить реплику-шиппинг, а после окончания формирования отчёта - без проблем продолжить...

А про закрытие периода, Рус000, Вы похоже, не поняли... Периоды можно закрывать "по частям": "постоянное закрытие" - например, на 22.04.2011 00:00:00.000 - закрыт банковский день и мы не ожидаем что кто-то попытается "писать в закрытый период", и "временное закрытие" - например, на текущий момент 26.04.2011 04:15:00.000 (на момент формирования отчёта минус небольшая задержка). Отчёт выставляет "временное закрытие" как можно позже - перед непосредственным чтением данных за период с 22.04.2011 00:00 по 26.04.2011 04:15:00.000. Причём сессиям в режиме 24х7 никто не запрещает вносить "документы" с "метками" времени ПОСЛЕ 26.04.2011 04:15:00.000. При этом, поскольку чтение данных за период 22.04.2011 00:00:00.000 - 26.04.2011 04:15:00.000 не очень большое - блокировка не должна оказаться длительной и критичной. Ожидать будут вынуждены только те сесии, которые попытаются во время работы отчёта писать "документы" с "меткой" в этом временном промежутке. Естественно, после окончания отчёта, отчёт снимает "временное закрытие".

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