[Gustav]

Цитата:

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

дырок действительно очень много. При "использованных" свыше 3,5 млрд номеров RecId у нас в базе всего около 400 млн записей. И ее еще можно почистить...

У нас похожий процент заполненности, даже еще меньше: на 1.3 млрд RecId - около 100 млн записей.

Я набросал еще один джоб, помогающий понять степень заполненности базы по диапазонам-этапам (stages) размером в 100 млн. номеров RecId.

static void Job351_CountRecIdsPerStage(Args _args)
{
    // расчет количеств RecId по этапам
    int             i, nLines;
    int             timeFullStart, timeFullFinish;

    Dictionary      dictionary = new Dictionary();
    TableId         tableId;
    DictTable       dictTable;
    Common          common;
    int             row, timeStart;
    int             recordCount;

    int             stage;
    int             stageCnt        = 22;
    int             recIdPerStage   = 100000000;
    int             recIdStart      = 1;
    int             recIdEnd        = recIdPerStage;
    int             recIdCount;

    ;

    timeFullStart = timenow();

    for (stage=1; stage<= stageCnt; stage++)
    {
        recIdCount = 0;
        for (i=1; i<= dictionary.tableCnt(); i++)
        {
            tableId   = dictionary.tableCnt2Id(i);
            dictTable = new DictTable(tableId);

            print strFmt('%1 -- %2 -- %3', stage, tableId, dictTable.name());

            // если в очередной таблице нет записей
            // то переходим к следующей
            try
            {
                nLines = infolog.line();
                recordCount = new SysDictTable(tableId).recordCount();
            }
            catch //может случиться, если таблица есть в репозитарии, но нет в базе
            {
                infolog.clear(nLines);
                recordCount = 0;
            }
            if (! recordCount)
                continue;

            common = dictTable.makeRecord();

            select count(RecId) from common
                where common.RecId >= recIdStart && common.RecId <= recIdEnd;

            recIdCount += common.RecId;
        }

        info(strFmt('%1 -- %2 -- %3 -- %4', stage, recIdStart, recIdEnd, recIdCount));

        if (! recIdCount) 
            break;

        recIdStart      = recIdEnd + 1;
        recIdEnd        = recIdEnd + recIdPerStage;
    }

    timeFullFinish = timenow();
    box::info(strfmt('Total running time: %1 sec', timeFullFinish - timeFullStart));
}

У меня джоб трудился около часа и по окончании выдал следующую информацию (привожу в слегка облагороженном виде):

stage recIdStart      recIdEnd        recIdCount   % к 100 млн.
---------------------------------------------------------------
 1                1     100 000 000    8 050 727    8%
 2      100 000 001     200 000 000      878 353    1%
 3      200 000 001     300 000 000    1 478 347    1%
 4      300 000 001     400 000 000    1 131 490    1%
 5      400 000 001     500 000 000    2 195 859    2%
 6      500 000 001     600 000 000    1 427 424    1%
 7      600 000 001     700 000 000    1 259 705    1%
 8      700 000 001     800 000 000    2 905 657    3%
 9      800 000 001     900 000 000   16 803 406   17%
10      900 000 001   1 000 000 000   12 565 324   13%
11    1 000 000 001   1 100 000 000   16 741 287   17%
12    1 100 000 001   1 200 000 000   21 317 892   21%
13    1 200 000 001   1 300 000 000   11 187 373   11%
14    1 300 000 001   1 400 000 000            0    0%
---------------------------------------------------------------
                                      97 942 844

Такая вот занятная картина получается. Явная пустота первых 700 млн - полагаю, интенсивная черновая работа на внедрении. Хотя все равно с трудом представляю, как за внедрение можно столько id-шек растратить... Ну и как же тут не захотеть по дыркам повторно пройтись?

Кстати, нашёл у себя аксесный mdb-файл на 28 млн. записей таблицы UsedRecId (см. мой пред. пост). Так вот этот файл имеет размер 1 Gb. Можно использовать это соотношение как оценочное при планировании "завоевания" этапов.

Alenka, а у вас поставщик-внедренец Аксапты - не GMCS ли тоже? У них в приложении масса полезных запросов-отчетов, которые, тем не менее, RecId расходуют нещадно - за счет заполнения вспомогательных таблиц временными данными (не путать с временными таблицами). Т.е. на "совесть" этих запросов-отчетов в нашем приложении половину дыр точно можно списывать...