derly, это известная фича в Cache v.2007.1-2010.1. В документации есть чёткий рецепт по её обходу. Ищите строку "Using the Shadow for Queries".

Приведу выдержку из док-и к Cache 2010.1, т.к. здесь изложено наиболее полно:
Док-я к Cache 2010.1Versions of Caché prior to release 2007.1 turned off journaling for any changes to the cached query definition global (^mcq); however, this version does journal updates to this global. As a result, if you plan to execute SQL queries on the destination shadow you must segregate updates of the ^mcq global on the source from the activity on the destination. This prevents logical corruption of the ^mcq global on the shadow.
You can do this easily with global and routine mapping. For each namespace on the source from which you run dynamic queries, do the following:
Create a new database on the source to isolate the source cached queries.
Add global mapping for the ^mcq global in the source namespace to the new database.
Add routine mapping for all versions of the cached query routines (the default prefix is CacheSql) in the source namespace to the new database.
You can then exclude the new database from any mapping to the shadow, therefore preventing any updates to the^mcq global or the CacheSql routines on the source from being transferred to the shadow.

Использование СТЕНЬ для обработки запросовЕсли вы выполняете SQL-запросы на СТЕНЬ, Caché использует глобал ^mcq. Если параллельно запросы обрабатываются на СБД, ^mcq будет передаваться на СТЕНЬ и, соответственно, «замусориваться» на СТЕНЬ. Поэтому вам придется отделить обновления ^mcq, порождаемые СБД, от СТЕНЬ. Это легко осуществимо с помощью механизма отображения глобалов и программ. Для каждой области на СБД выполните следующие действия:
1.Создайте новую БД на СБД (пусть она называется mcqdb).
2.Добавьте отображение глобала ^mcq из вашей области в mcqdb.
3.Добавьте отображение программ для всех версий кэшированных запросов (по умолчанию - CacheSql*) из вашей области в mcqdb.
4.В будущем, при редактировании настроек теневого сервера избегайтие включения mcqdb в список БД, копируемых на теневой сервер.

Выполненные настройки позволят избавиться от передачи изменений глобала ^mcq или программ – скомпилированных запросов на СТЕНЬ. Derly , не хочу впадать в менторский тон, но в общем-то док-я по Cache написана на базовом техническом английском, понимание которого, как мне кажется, вам по-любому пригодится, даже если уйдёте в сторону от Cache. Посмотрите, какие темы популярны у формчан: "Как вернуть английский?" :)

В общем-то, про версии 2007.1-2010.1 всё давно известно, стоит ли теоретизировать?
Что касается 2010.2, там ситуация несколько иная:
- больше нет ^mcq, теперь ^%sqlcq
- больше нет программ CacheSql*, теперь %sqlcq.pSYS.*
- всё это хозяйство отображено в специальную ("скрытую") БД cache.
Т.е. проблемы возможной порчи SQL-запросов на СТЕНЬ больше не существует.
Тем не менее, раздел документации про "тень", который был приведён выше, пока сохранён, как видно, документаторы немного отстают :)ну яТеневой - это репликация по журналу (передает демон журнала). А репликация блоков - это зеркало (передает демон записи блоков). Это не совсем так:
1) и в тени, и в зеркале передачей занимаются специальные демоны, а не демоны общего назначения
2) оба механизма основаны на передаче блоков журнала. В случае mirroring см.:Caché Mirroring ConceptsAll mirrored databases on the primary failover member are journaled, regardless of any system configuration or user code that may attempt to bypass journaling for those databases.
...
Mirroring uses the journal write cycle on the primary failover member to synchronize data across the mirror.

Блочная - не нарушится. SQL-запросы на "тени" запускать можно (если они без побочных эффектов :). Когда-то даже попадались рекомендации типа "убирайте тяжёлую аналитику на теневой сервер". Но организовать это не так-то просто...