AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 04.06.2007, 10:32   #1  
Rect is offline
Rect
Участник
 
43 / 11 (1) +
Регистрация: 29.05.2006
Запросы к связанным таблицам
Добрый день.

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

Вопрос: как можно это победить?
Старый 04.06.2007, 10:51   #2  
konopello is offline
konopello
SAP
SAP
 
628 / 76 (4) ++++
Регистрация: 08.11.2005
Адрес: Минск
Интересная задача. Я думаю что это не удастся сделать без блокировки. А эти таблицы блакировать смерть. А для чего это надо?
Старый 04.06.2007, 10:53   #3  
Gustav is offline
Gustav
Moderator
Аватар для Gustav
SAP
Лучший по профессии 2009
 
1,858 / 1152 (42) ++++++++
Регистрация: 24.01.2006
Адрес: Санкт-Петербург
Записей в блоге: 19
"Довольно долго" - это сколько? Минуты? Часы?
Если есть возможность, считайте ночью.
Старый 04.06.2007, 11:05   #4  
Rect is offline
Rect
Участник
 
43 / 11 (1) +
Регистрация: 29.05.2006
Цитата:
Сообщение от Gustav Посмотреть сообщение
"Довольно долго" - это сколько? Минуты? Часы?
Довольно долго - это около получаса.
Старый 04.06.2007, 11:03   #5  
Rect is offline
Rect
Участник
 
43 / 11 (1) +
Регистрация: 29.05.2006
Запросы используются при составлении отчета по складам. Без InventSum'а впринципе можно обойтись, но тогда отчет будет формироваться очень долго. Ночью считать неполучится т.к. идут отгрузки, а следовательно блокировать таблицы нельзя. К тому же, есть ситуации, когда нужны актуальные данные.
Может можно как-то решить эту задачу используя средства СУБД (в моем случае СУБД - Oracle)?
Старый 04.06.2007, 11:09   #6  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2925 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
не знаю, может в оракле есть snapshot isolation и его можно как-то прикрутить к аксапте?
Старый 04.06.2007, 11:19   #7  
Gustav is offline
Gustav
Moderator
Аватар для Gustav
SAP
Лучший по профессии 2009
 
1,858 / 1152 (42) ++++++++
Регистрация: 24.01.2006
Адрес: Санкт-Петербург
Записей в блоге: 19
Ну, даже если операции идут круглосуточно, отчет же наверное все равно составляется на какой-то определенный момент времени? Например, на 20-00 часов. Можно же отсечь операции после этого периода - по CreatedTime, по RecId. "Полчаса" - это обсчет какого периода времени? Можно же обсчитывать, наверное, только последние сутки и "прибавлять" их отчету за предыдущие сутки (т.е. такой персональный "InventSum" получится)
Старый 04.06.2007, 11:34   #8  
Rect is offline
Rect
Участник
 
43 / 11 (1) +
Регистрация: 29.05.2006
Цитата:
Сообщение от Gustav Посмотреть сообщение
Ну, даже если операции идут круглосуточно, отчет же наверное все равно составляется на какой-то определенный момент времени? Например, на 20-00 часов. Можно же отсечь операции после этого периода - по CreatedTime, по RecId. "Полчаса" - это обсчет какого периода времени? Можно же обсчитывать, наверное, только последние сутки и "прибавлять" их отчету за предыдущие сутки (т.е. такой персональный "InventSum" получится)
Я на эту тему уже тоже думал. Мы можем отсечь по RecId строки InventTrans, которые были созданы после запуска запроса по InventSum, но если строка не создавалась, а была изменена? Отбросить мы ее не можем, а данные получаются некорректные.
Может можно как-нибудь сделать snapshot и потом его использовать?
Старый 04.06.2007, 12:03   #9  
Gustav is offline
Gustav
Moderator
Аватар для Gustav
SAP
Лучший по профессии 2009
 
1,858 / 1152 (42) ++++++++
Регистрация: 24.01.2006
Адрес: Санкт-Петербург
Записей в блоге: 19
Цитата:
Сообщение от Rect Посмотреть сообщение
но если строка не создавалась, а была изменена?
Раз такое дело, то можно включить системные поля ModifiedDate, ModifiedTime для таблицы InventSum

P.S. Вы знакомы с этим материалом: http://axapta.mazzy.ru/lib/inventsumdate/ ?
Старый 04.06.2007, 12:17   #10  
AndyD is offline
AndyD
Участник
КОРУС Консалтинг
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
2,560 / 2479 (88) +++++++++
Регистрация: 20.08.2005
Цитата:
Сообщение от Gustav Посмотреть сообщение
Раз такое дело, то можно включить системные поля ModifiedDate, ModifiedTime для таблицы InventSum

P.S. Вы знакомы с этим материалом: http://axapta.mazzy.ru/lib/inventsumdate/ ?
А что это даст?
Будет установлен сам факт модификации, но не что изменялось и на сколько.
__________________
Axapta v.3.0 sp5 kr2
Старый 04.06.2007, 11:42   #11  
Rect is offline
Rect
Участник
 
43 / 11 (1) +
Регистрация: 29.05.2006
Цитата:
Сообщение от Gustav Посмотреть сообщение
Можно же обсчитывать, наверное, только последние сутки и "прибавлять" их отчету за предыдущие сутки (т.е. такой персональный "InventSum" получится)
Если я правильно понял, то предлагается создать аналог таблицы InventSum. Такое сделать конечно можно и это будет решением, вот только ради одного отчета создавать довольно большую таблицу не хочется. Может есть всё же какое-нибудь другое решение?
Старый 04.06.2007, 12:17   #12  
belugin is offline
belugin
Участник
Аватар для belugin
Сотрудники Microsoft Dynamics
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии 2011
Лучший по профессии 2009
 
4,622 / 2925 (107) +++++++++
Регистрация: 16.01.2004
Записей в блоге: 5
Мне кажется по-человечески сделать так:
1. Либо включить Snapshot isolation для данной транзакции в Oracle (как, не знаю, может через Connection сказать ему какую-то команду)

2. Либо сделать отдельную базу для отчетов и периодически копировать туда данные (не знаю оракл, поэтому не скажу, как лучше в SQL 2005 - backup-restore или database snapshot) -- насколько я знаю, это достаточно распространенное решение для снижения нагрузки на основную OLTP базу
Старый 04.06.2007, 12:43   #13  
Gustav is offline
Gustav
Moderator
Аватар для Gustav
SAP
Лучший по профессии 2009
 
1,858 / 1152 (42) ++++++++
Регистрация: 24.01.2006
Адрес: Санкт-Петербург
Записей в блоге: 19
Цитата:
Сообщение от AndyD Посмотреть сообщение
А что это даст?
Будет установлен сам факт модификации, но не что изменялось и на сколько.
Хм, да, наверное, не сильно спасёт...
Цитата:
Сообщение от belugin Посмотреть сообщение
Мне кажется по-человечески сделать так:
1. Либо включить Snapshot isolation для данной транзакции в Oracle (как, не знаю, может через Connection сказать ему какую-то команду)
Можно попробовать дёрнуть данные одним сложным запросом (например, с использованием WITH с подзапросами). В этом случае Oracle, вроде, должен всё сделать сам и автоматически. В том числе, должен гарантировать согласованность данных на момент начала выполнения запроса.
Старый 04.06.2007, 13:05   #14  
online
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,907 / 5716 (196) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от belugin Посмотреть сообщение
Мне кажется по-человечески сделать так:
1. Либо включить Snapshot isolation для данной транзакции в Oracle (как, не знаю, может через Connection сказать ему какую-то команду)
Насколько я помню Oracle - там для этого есть команда "SET TRANSACTION READ ONLY". Только нужно помнить, что если такая транзакция слишком долго длится - может закончится undo tablespace. Но обычно его не трудно наростить.
Старый 05.06.2007, 10:16   #15  
Gustav is offline
Gustav
Moderator
Аватар для Gustav
SAP
Лучший по профессии 2009
 
1,858 / 1152 (42) ++++++++
Регистрация: 24.01.2006
Адрес: Санкт-Петербург
Записей в блоге: 19
ORACLE: Multiversion Read Consistency - MVRC
Привожу цитату отсюда: 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 и быть уверенным, что данные будут согласованы на момент начала выполнения этого запроса. Если что, готов помочь с его написанием.
 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
оптимизируем запросы. SHiSHok DAX: Программирование 18 13.09.2009 21:26
RLS не работает по связанным таблицам. oxbacc DAX: Функционал 1 03.11.2006 12:38
Разные запросы в 2-х и 3-х уровневой конфигурациях. Что делать?! Anais DAX: Программирование 12 04.11.2004 12:47
Запросы к временным таблицам или group by Anais DAX: Программирование 4 23.03.2004 12:48
Заказов -> Строки заказов -> Запросы -> Пункт "Производство" Андре DAX: Программирование 1 20.09.2002 10:43

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 14:25.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.