Запросы к связанным таблицам

[Rect]

Добрый день.

Столкнулся недавно вот с какой задачей: по таблицам InventSum и InventTrans делаются запросы. Сначала по одной таблице, затем по другой. Оба запроса выполняются довольно долго т.ч. иногда после их выполнения получаю некорректные данные (к примеру, сначала сделал запрос по InventSum, а во время его выполнения в InventTrans произошли изменения т.о. перед выполнением запроса по InventTrans полученные данные по InventSum уже неверны). Очевидно, что блокировать любую из этих таблиц надолго нельзя.

Вопрос: как можно это победить?

[konopello]

Интересная задача. Я думаю что это не удастся сделать без блокировки. А эти таблицы блакировать смерть. А для чего это надо?

[Gustav]

"Довольно долго" - это сколько? Минуты? Часы?
Если есть возможность, считайте ночью.

[Rect]

Цитата:

Сообщение от Gustav

"Довольно долго" - это сколько? Минуты? Часы?

Довольно долго - это около получаса.

[Rect]

Запросы используются при составлении отчета по складам. Без InventSum'а впринципе можно обойтись, но тогда отчет будет формироваться очень долго. Ночью считать неполучится т.к. идут отгрузки, а следовательно блокировать таблицы нельзя. К тому же, есть ситуации, когда нужны актуальные данные.
Может можно как-то решить эту задачу используя средства СУБД (в моем случае СУБД - Oracle)?

[belugin]

не знаю, может в оракле есть snapshot isolation и его можно как-то прикрутить к аксапте?

[Gustav]

Ну, даже если операции идут круглосуточно, отчет же наверное все равно составляется на какой-то определенный момент времени? Например, на 20-00 часов. Можно же отсечь операции после этого периода - по CreatedTime, по RecId. "Полчаса" - это обсчет какого периода времени? Можно же обсчитывать, наверное, только последние сутки и "прибавлять" их отчету за предыдущие сутки (т.е. такой персональный "InventSum" получится)

[Rect]

Цитата:

Сообщение от Gustav

Ну, даже если операции идут круглосуточно, отчет же наверное все равно составляется на какой-то определенный момент времени? Например, на 20-00 часов. Можно же отсечь операции после этого периода - по CreatedTime, по RecId. "Полчаса" - это обсчет какого периода времени? Можно же обсчитывать, наверное, только последние сутки и "прибавлять" их отчету за предыдущие сутки (т.е. такой персональный "InventSum" получится)

Я на эту тему уже тоже думал. Мы можем отсечь по RecId строки InventTrans, которые были созданы после запуска запроса по InventSum, но если строка не создавалась, а была изменена? Отбросить мы ее не можем, а данные получаются некорректные.
Может можно как-нибудь сделать snapshot и потом его использовать?

[Gustav]

Цитата:

Сообщение от Rect

но если строка не создавалась, а была изменена?

Раз такое дело, то можно включить системные поля ModifiedDate, ModifiedTime для таблицы InventSum

P.S. Вы знакомы с этим материалом: http://axapta.mazzy.ru/lib/inventsumdate/ ?

[AndyD]

Цитата:

Сообщение от Gustav

Раз такое дело, то можно включить системные поля ModifiedDate, ModifiedTime для таблицы InventSum

P.S. Вы знакомы с этим материалом: http://axapta.mazzy.ru/lib/inventsumdate/ ?

А что это даст?
Будет установлен сам факт модификации, но не что изменялось и на сколько.

[Rect]

Цитата:

Сообщение от Gustav

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

Если я правильно понял, то предлагается создать аналог таблицы InventSum. Такое сделать конечно можно и это будет решением, вот только ради одного отчета создавать довольно большую таблицу не хочется. Может есть всё же какое-нибудь другое решение?

[belugin]

Мне кажется по-человечески сделать так:
1. Либо включить Snapshot isolation для данной транзакции в Oracle (как, не знаю, может через Connection сказать ему какую-то команду)

2. Либо сделать отдельную базу для отчетов и периодически копировать туда данные (не знаю оракл, поэтому не скажу, как лучше в SQL 2005 - backup-restore или database snapshot) -- насколько я знаю, это достаточно распространенное решение для снижения нагрузки на основную OLTP базу

[Gustav]

Цитата:

Сообщение от AndyD

А что это даст?
Будет установлен сам факт модификации, но не что изменялось и на сколько.

Хм, да, наверное, не сильно спасёт...

Цитата:

Сообщение от belugin

Мне кажется по-человечески сделать так:
1. Либо включить Snapshot isolation для данной транзакции в Oracle (как, не знаю, может через Connection сказать ему какую-то команду)

Можно попробовать дёрнуть данные одним сложным запросом (например, с использованием WITH с подзапросами). В этом случае Oracle, вроде, должен всё сделать сам и автоматически. В том числе, должен гарантировать согласованность данных на момент начала выполнения запроса.

[fed]

Цитата:

Сообщение от belugin

Мне кажется по-человечески сделать так:
1. Либо включить Snapshot isolation для данной транзакции в Oracle (как, не знаю, может через Connection сказать ему какую-то команду)

Насколько я помню Oracle - там для этого есть команда "SET TRANSACTION READ ONLY". Только нужно помнить, что если такая транзакция слишком долго длится - может закончится undo tablespace. Но обычно его не трудно наростить.

[Gustav]

Привожу цитату отсюда: http://doc.novsu.ac.ru/oracle/conceps/7013scm.10.html про оракловую многоверсионную модель согласованности по чтению (текст там сформатирован так, что представление его здесь с тегом CODE представляется наиболее оптимальным).

Итак, цитата:

Многоверсионная модель согласованности

--------------------------------------



        ORACLE обеспечивает согласованность по чтению на двух  различных

        уровнях:  на   уровне  предложения   и  на   уровне  транзакции.

        Следующие   секции    объясняют   каждый    из   этих    уровней

        согласованности  по  чтению,  а  также механизмы, которые ORACLE

        использует   для   реализации   своей   многоверсионной   модели

        согласованности данных.



Согласованность по чтению на уровне предложения



        ORACLE всегда обеспечивает  согласованность по чтению  на уровне

        предложения, которая гарантирует, что данные, возвращаемые одним

        запросом,  согласованы  по  отношению  к  моменту  начала  этого

        запроса.   Поэтому  запрос  никогда  не видит никаких изменений,

        осуществленных теми  транзакциями, которые  подтверждены в  ходе

        выполнения данного запроса.



        Чтобы   обеспечить   согласованность   по   чтению   на   уровне

        предложения,  ORACLE  фиксирует  текущий  SCN  (системный  номер

        изменения),  когда  запрос  входит  в  фазу выполнения.  По мере

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

        подтверждены  к  моменту  запомненного  SCN;  запрос  не   видит

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

        после того, как запрос начал выполняться.



        Состоятельность множества результатов гарантируется для  каждого

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

        Такие предложения SQL, как  SELECT, INSERT с запросом,  UPDATE и

        DELETE, всегда  опрашивают данные,  явно или  неявно, и  все они

        получают  состоятельное  множество   данных.   Каждое  из   этих

        предложений использует  запрос, чтобы  определить, какие  данные

        будут  затронуты  (соответственно  выбраны, вставлены, обновлены

        или  удалены).   Предложение  SELECT  является явным запросом, и

        может   иметь   вложенные   запросы   или   операцию соединения.

        Предложение   INSERT   может   использовать   вложенные запросы.

        Предложения UPDATE и DELETE  могут использовать фразы WHERE  или

        подзапросы,  чтобы  воздействовать   на  подмножество  строк   в

        таблице.   Хотя  запросы,  используемые  предложениями   INSERT,

        UPDATE и DELETE,  получают состоятельное множество  результатов,

        они   не   видят   изменений,   осуществляемых   самими    этими

        предложениями DML.



Согласованность по чтению на уровне транзакции



        ORACLE    также    предоставляет    необязательную   возможность

        согласованности  по   чтению  на   уровне  транзакции,   которая

        гарантирует, что данные, которые видят ВСЕ запросы внутри  одной

        и  той  же  транзакции,  согласованы  по отношению к одной точке

        времени   (моменту    начала   транзакции).     Таким   образом,

        согласованность  по  чтению  на  уровне  транзакции обеспечивает

        повторяемость чтений.



        ORACLE  обеспечивает   согласованность  по   чтению  на   уровне

        транзакции с помощью различных методов:



        транзакции      Транзакции   read-only   (только-чтение)   могут

        read-only       содержать только запросы; они не могут содержать

                        никаких   предложений   DML.   Чтобы  обеспечить

                        повторяемость    чтений    внутри     транзакции

                        read-only,   ORACLE   фиксирует   момент  начала

                        транзакции.   В  течение  транзакции ей доступны

                        лишь  те  данные,  которые  были  подтверждены к

                        моменту начала транзакции.



        монопольные     Если повторяемость чтений необходимо  обеспечить

        блокировки      в  транзакциях,  содержащих  предложения DML, то

        таблиц          транзакция  может  явно  запросить   разделяемые

        и строк         блокировки   по    таблицам   или    монопольные

                        блокировки   по   тем   строкам,   которые будут

                        считываться    неоднократно.     Это     решение

                        обеспечивает согласованность по чтению на уровне

                        транзакции,    хотя    и    уменьшает    степень

                        одновременного доступа к данным.



        Суммируя,  можно  сказать,  что  ORACLE  способен   обеспечивать

        согласованность по чтению  как на уровне  предложения, так и  на

        уровне   транзакции,   предоставляя   каждому   предложению  или

        транзакции  ее  собственную  "версию"  данных  по  состоянию  на

        конкретный  момент  времени  (начало  выполнения предложения или

        транзакции).

Т.е., действительно, можно попробовать отправить прямо в Oracle (через Connection или через ADO) один сложный SELECT и быть уверенным, что данные будут согласованы на момент начала выполнения этого запроса. Если что, готов помочь с его написанием.