Выгрузка измененных клиентов во внешнюю систему

[Ace of Database]

Я как-то делал отчет, который из журнала базы данных достает историю изменения выбранных полей. Вроде довольно быстро работает на базе в 500 Гб. Правда там журнал базы данных хранился только за последние 2 недели, а потом обрезался.
А вам всего-то надо узнать какие записи изменились из списка нужных вам таблиц.

[Vadik]

Цитата:

Сообщение от Ace of Database

Я как-то делал отчет, который из журнала базы данных достает историю изменения выбранных полей. Вроде довольно быстро работает на базе в 500 Гб

"Довольно быстро", или "достаточно быстро чтобы непрерывно делать это 10+ раз в минуту", учитывая других читателей-писателей в лог ?

[Ace of Database]

Цитата:

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

"Довольно быстро", или "достаточно быстро чтобы непрерывно делать это 10+ раз в минуту", учитывая других читателей-писателей в лог ?

Я делал отчет, который парсил контейнер, чтобы достать значения конкретных полей. И еще надо поймать момент изменения именно нужного поля среди прочего мусора. Поэтому основное время уходило на этот парсинг.
А запрос к таблице SysDatabaseLog вроде быстро выполнялся. Прошло уже несколько лет с того времени. По-любому надо пробовать. По-моему это самый простой способ решить данную проблему. А начинать пробовать надо с простых способов.
Хотя все-таки поймать изменение конкретного поля через таблицу SysDatabaseLog - задача не очень тривиальная, но пример как это сделать есть. Даже на этом форуме выкладывали.

[Ace of Database]

Запустил у себя сейчас такой джоб.
Для 26 тысяч клиентов он отработал примерно за 2 минуты (если убрать вывод в инфолог)
Это для Аксапты версии 3.0

static void sysDatabaseLogFieldChangedCustAxForum(Args _args)
{
    CustTable                    custTable;
    SysDatabaseLog               SysDatabaseLog;

    int                          i;
    container                    tmp;

    SysOperationProgress         sysOperationProgress = new SysOperationProgress(1);
    int                          stepCount;
    int                          total;
    UserInfo                    UserInfo;

;
    select count(RecId) from custTable;
    total = custTable.RecId;

    sysOperationProgress.setTotal(total);

    while select custTable
    {
        stepCount ++;
        sysOperationProgress.setCount(stepCount);
        sysOperationProgress.setText(strFmt("%1 запись из %2", stepCount, total));

        while select SysDatabaseLog order by createdDate, createdTime
            where SysDatabaseLog.LogRecId == custTable.RecId
              &&  SysDatabaseLog.table    == custTable.TableId
        {
            if (typeOf(conpeek(SysDatabaseLog.Data, 1)) == Types::Container)
            {
                for ( i = 1; i <= conlen(SysDatabaseLog.data); i ++)
                {
                    tmp = conpeek(SysDatabaseLog.Data, i );
                    if (fieldExt2Id(conpeek(tmp, 1)) == fieldnum(custTable, zResponsibleDivision))
                    {
                        if(conpeek(tmp, 3) != conpeek(tmp, 2))
                        {
                            select firstonly UserInfo where UserInfo.Id == SysDatabaseLog.createdBy;
                            info(strfmt("%1 ~ %2 ~ %3 ~ %4 ~ %5", custTable.AccountNum, UserInfo.name,  SysDatabaseLog.createdDate, conpeek(tmp, 3),conpeek(tmp, 2) ));
                        }
                    }
                }
            }
        }
    }
}

[Ace of Database]

Т.е. 26000 вызовов select для таблицы SysDatabaseLog срабатывают за 2 минуты и плюс еще время на парсинг

[Ace of Database]

В таблице SysDatabaseLog сейчас 74 миллиона записей. Похоже, что ее перестали обрезать

[Ace of Database]

Автор топика может для своих нужд переписать джоб так, чтобы он отправил всего один запрос к SysDatabaseLog вместо 26 тысяч запросов, но тогда придется усложнить парсинг, чтобы сохранять предыдущие значения полей для каждой записи. Все-таки у него 6 миллионов клиентов, а не 26 тысяч. Но в выборку у него попадут не более нескольких сотен записей, т.к. ему нужны изменения только за последнюю минуту.

[Pustik]

Цитата:

Сообщение от Ace of Database

Правда там журнал базы данных хранился только за последние 2 недели, а потом обрезался.
А вам всего-то надо узнать какие записи изменились из списка нужных вам таблиц.

Там еще хотят запускать за определенные периоды :

Цитата:

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

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

т.е. лог придется хранить для этих таблиц как минимум год. Но идея хорошая если лог небольшой и скорость будет приемлемая.Опять таки надо пробовать.
На худой конец можно создать свой лог-таблицу под эту задачу.
У нас практикуется репликация о которой говорил axm2017.

Цитата:

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

Типичное ( во всяком случае видел реализации подобной идеи на пакете)

Параметр - время запуска

При запуске процесса выбираем все измененные записи от параметра до текущего момента (ессно при включенном modified time).

Далее после обработки сохраняем в параметре текущее время.

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

Цитата:

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

"Довольно быстро", или "достаточно быстро чтобы непрерывно делать это 10+ раз в минуту", учитывая других читателей-писателей в лог ?

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