Время выполнения Операции INSERT

[Константин!]

Коллеги подскажите, пожалуйста от чего зависит время выполнения операции INSERT.
На днях занялся изучением скорости работы системы с помощью клиент монитора и Code Coverage. Помимо забытых ключей в основных кодеюнитах (время выполнения операции Find доходит до 1400 ms) заметил характерную особенность, что самое узкое место находится в ф-ях 22 CU Ф-ях InsertValueEntry и InsertItemLedgerEntry, но что характерно при учете отгрузки время на эти операции находится в пределах 300-400 мс а при получение транзита время повышается до 600 мс. Отсюда вопрос: от чего это может зависеть и как можно уменьшить это время?

Сервер NAtiv 3.70b размер базы 17 Гб
ItemLedgerEntry= 870146 записей
ValueEntry=1307904 записей
Тестирование проходило на накладных кол-во записей в которых >50 шт

[mazzy]

навскидку:
1. уменьшить количество ключей
2. уменьшить количество flowFields, которые зависят от данной таблицы

[Константин!]

Спасибо.
А почему зависит от вида учитываемого документа(кол-во активных ключей и flowFields постоянно)
Как найти нейспользуемые в донной конфигурации flowFields и ключи?

[mazzy]

Цитата:

Сообщение от Константин!

А почему зависит от вида учитываемого документа

<{POST_SNAPBACK}>

Потому что код, реализующий учет, разный.
Но лезть в код для оптимизации? Так стоит делать в последнюю очередь, по-моему.

[navi-prog]

Цитата:

Сообщение от Константин!

Спасибо.
А почему зависит от вида учитываемого документа(кол-во активных ключей и flowFields постоянно)
Как найти нейспользуемые в донной конфигурации flowFields и ключи?

<{POST_SNAPBACK}>

Полагаю что при учета транзита вставляются две записи (расход с транзитного склада и приход) - поэтому время возрастает вдвое .

Поиск неиспользуемых ключей - к сожалению только опытным путем - enable/disable на ключи или снятие галки Mantain на Sift Level List.

[Константин!]

for navi-prog
Конечно понятно что две записи вставляется, но я имею ввиду время выполнения отдельно взятого оператора INSERT.

[Константин!]

Если клиен монитор фильтрануть по TableName=Стоимость Операций
и Function Name=INSERT то получаем такую большую амплитуду изменения занчений времени в течение выполнения одной операции Учет Отгрузки Транзитного Перемешения (0-391мс) и все эти операций Insert выполняются в одной в ф-и на одном операторе.
Почему такой разброс?

[Константин!]

Обнаружил закономерность что строки в клиент маниторе с большим временем вставки имеют большие значение в полях
Disk Read,DiskWrite что значат эти поля и в каких еденицах их мереют.
т.е что значит такая запись
<div class='XPPtop'>X++</div><div class='XPP'>
EntryNo. |TableName          |FunctionName   |ElapsedTime (ms) |DiskReads| DiskWrites
59526    |Стоимость Операция |INSERT         |187              |23       |76
59657    |Стоимость Операция |INSERT         |63               |7        |7</div>
за 187 мс диск прочитал 23 ед.измер и записал 76 ед.измер

[Wizard_imported]

Время выполнения операции вставки зависит от многих причин...
1. Надо выделить пространство для новой записи, разместить на странице...
2. Надо внести изменения в SQL ключи (или нативные ключи, они тоже должны как-то храниться)
3. Надо перестроисть SIFT
...
Такая разница может быть обусловлена значениями полей, входящих в индексы. Думаю, в первом случае селективность, скажем, номера товара была плохой (много записей с таким значением), во втором - получше (записей было меньше - отсюда и меньшее количество дисковых опреаций)
Для SQL условные единицы измерения, если не ошибаюсь - страницы. В байты переводится в зависимости от настройки размера этих страниц.

[Константин!]

Все понятно занчит, что ускорить втсавку в стаблицы надо Отключать определенные FlouFields и оптемизировать ключи (что и советовал Mazzy).
Объесните пожалуста суть всех дополнительных галочек в ключе т.к я это все понимаю очень поверхностно и могу чего нибуть испортить.

MaintainSQLIndex-?
MaintainSIFTIndex-?
SIFT Levels To Maintain-?

[Scorpie]

Цитата:

Сообщение от Константин!

Все понятно занчит, что ускорить втсавку в стаблицы  надо Отключать определенные FlouFields и оптемизировать ключи (что и советовал Mazzy).
Объесните пожалуста суть всех дополнительных галочек в ключе т.к я это все понимаю очень поверхностно и могу чего нибуть испортить.

MaintainSQLIndex-?
MaintainSIFTIndex-?
SIFT Levels To Maintain-?

<{POST_SNAPBACK}>

FlowFields отключать не нужно. Они не обновляются, не пересчитываются в момент добавления, модификации или удаления записей

[Scorpie]

Цитата:

Сообщение от Константин!

Все понятно занчит, что ускорить втсавку в стаблицы  надо Отключать определенные FlouFields и оптемизировать ключи (что и советовал Mazzy).
Объесните пожалуста суть всех дополнительных галочек в ключе т.к я это все понимаю очень поверхностно и могу чего нибуть испортить.

MaintainSQLIndex-?
MaintainSIFTIndex-?
SIFT Levels To Maintain-?

<{POST_SNAPBACK}>

SIFT Levels to maintain - самый быстрый путь решения вопроса. Не обязательно панацея, но поможет сильно.
Рассмотрим 2 стандартных ключа для 17й таблицы:
1) G/L Account No.,Business Unit Code,Global Dimension 1 Code,Global Dimension 2 Code,Close Income Statement Dim. ID,Posting Date,Agreement No.
2)G/L Account No.,Business Unit Code,Global Dimension 1 Code,Global Dimension 2 Code,Posting Date,Agreement No.

Набор SIFT полей для данных ключей одинаковый :
Amount,Debit Amount,Credit Amount,Additional-Currency Amount,Add.-Currency Debit Amount,Add.-Currency Credit Amount

Итак. когда происходит запись в таблицу все 6 суммовых полей должны быть пересчитаны для всех уровней обоих ключей.
Несложно заметить что первые 4 уровня - "G/L Account No.,Business Unit Code,Global Dimension 1 Code,Global Dimension 2 Code" в обоих ключах одинаковы... соответственно идём в свойство 2го ключа и отключаем для этих 4х уровней галочку Maintain. Т.е. убираем элементарное дублирование...

Что произойдёт когда в коде будет явно использоваться 2й ключ и пойдёт расчёт CALCSUM(Amount) по полям "G/L Account No.,Business Unit Code,Global Dimension 1 Code" !? Движок определив что данный уровень для данного ключа отключён, возьмёт расчитанные суммы из первого ключа - ведь они там хранились бы одинаковые...

Вообщем это самый быстрой способ немного ускориться абсолютно никак не рискуя потерять в производительности...

[Галина]

Если уберете flowfield поля-у вас не будет информации по этим полям и какие то отчеты просто не выполнятся. Про
MaintainSQLIndex-?
MaintainSIFTIndex-?
SIFT Levels To Maintain-? не знаю-это для sql.
Чтобы оптимизировать ключи и убрать flow field поля-вы должны лезть в таблицы и там править. Абсолютно не верный путь. Ключи же не просто так создаются-если вы знаете где используется информация отсортированная по ключам -вперед правьте а после не забудьте исправить в отчетах и т.д. А поля flowfield -вообще трогать нужно осторожно. А то получите скорость при insert а после будете часами ждать выполнения отчетов и заданий.

[Константин!]

Супер , тогда как усткорить эту операцию

[Галина]

Scorpie.
А это все про sql версию?

[Scorpie]

Цитата:

Сообщение от Галина

Scorpie.
А это все про sql версию?

<{POST_SNAPBACK}>

Только для SQL сервера. На Native эти настройки никак не влияют. Они меняются, сохраняются в объектах но эффекта не будет

[Константин!]

Это относится и к Nativ серверу.

[Галина]

Странно а везде где я читала -везде написано вроде про sql.

[Константин!]

Вопрос в тему, на что повлияеет снятие галочек MaintainSQLIndex,
MaintainSIFTIndex, на ключах неимеющих SIFT полей?

[Scorpie]

Цитата:

Сообщение от Константин!

Вопрос в тему, на что повлияеет снятие галочек MaintainSQLIndex,
MaintainSIFTIndex, на ключах неимеющих SIFT полей?

<{POST_SNAPBACK}>

Для ключей не имеющих SIFT полей.
MaintainSIFTIndex не на что не повлияет.
MaintainSQLIndex - соответсвующий ключу индекс таблицы будет физически удалён на уровне SQL. Соответственно когда будет использоваться данный ключ серверу придётся сортировать данные без индекса что для большого кол-ва исходных данных естественно значительно медленее.