Ускорение 1С 7.7 в 10 раз и более(на SQL) - Созданием Нестандартных ИНДЕКСОВ +Кэш SQL

27.04.11

База данных - HighLoad оптимизация

После повторных тестов пришел к выводу:

Доп.Индексы - да ускоряют получение данных,
но эффект явно виден при закэшированной(в ОЗУ SQL-сервера) базе данных!

******************************************************
******* Принудительное КЭШИРОВАНИЕ на SQL СЕРВЕРЕ******
(эффективно если на SQL сервере ОЗУ больше чем размер Базы)
методики см. в описании ниже по тексту))

Идея взята путем переработки информации из следующих источников:
http://softpoint.ru/article.php?id=18
http://www.softpoint.ru/article_id15.htm
http://www.forum.mista.ru/topic.php?id=400197
*********************
Автор плагина для обмана 1с 7.7 насчет доп.Индексов
http://itland.ru/forum//index.php?showtopic=2439&hl=DDX
***********************
Запрос №1A279; (что то похожее порой шлет сама 1С)
Select  top 50 * from SC46(NOLOCK INDEX=VI4135) order by SP4135, ROW_ID

Время выполнения:  10203 мс
-----------------------------------------------------------------------------
Запрос №2 - видоизмененный запрос 1 без указания индекса

Select  top 50 * from SC46 order by SP4135, ROW_ID

Время выполнения: 4105 мс
-------------------------------------------------------------------------------------
Запрос №3 - Добавим Все Поля входящие в Индекс

Select  top 50 * from SC46(NOLOCK INDEX=VI4135) order by SP4135, Descr, ROW_ID

Время выполнения:156  мс
********************
А чтобы ОдынЦэ не убивало ЛЕВЫЕ)) индексы берем разработку -скрипт-плагин для OpenConf -файл приложен + Обработка загрузки БД в память SQL))
.....BIN\config\scripts\ExtDD.vbs
и
....Каталог_Инф_Базы\1cv7.ddx (Эти индексы в БД SQL создаст Конфигуратор при РЕСТРУКТОРИЗАЦИИ БД)
пример куска содержания моего DDX
X=RA405    %#Доп. индекс Регистр (Дв.) ОстаткиТМЦ
X=RA405    %I=MY_IDDOC                        |              |0     |IDDOC                                 |0  

Скачать файлы

Наименование Файл Версия Размер
ALL.zip
.zip 131,79Kb
146
.zip 131,79Kb 146 Скачать

Мной были расмотрены варианты следуюшие варианты решение проблемы Индексов:

1) Перехват и парсилка От 1С до ODBC - драйвера - тормозно и сложно "-"

2)Изменение хранимых процедур - уже получше но сложно "-"

3) и Наконец - СОЗДАНИЕ НЕСТАНДАРТНЫХ ИНДЕКСОВ - результат приятно удивил Laughing

 

Сразу уточняю размер БД взятой для теста 1С - на SQL около 25 ГБ, конфигурация Комплексная (дописанная до Производства), таблицы с Десятками милионов записей не редкость)), MS SQL 2008, ОЗУ сервера =40 ГБ.

таки 1с 7.7+ SQL не такой тормоз как я думал))

Все документы проводились ЗАДНИМ ЧИСЛОМ ( т.е. не на ТА):
       3.1)SQL БД- стандартная
           а)(БЕЗ КЭШИРОВАНИЯ) Среднее время проведения 1 документа(19 строк) 30 сек
           б)(С КЭШИРОВАНИЕМ) Среднее время проведения 1 документа(19 строк) 9 сек
 
       3.2)DBF БД- стандартная
           Среднее время проведения 1 документа(19 строк) 15 сек - приведено просто до кучи))) DBF без СУБД прошу не обсуждать в КОММЕНТАРИЯХ СТАТЬИ, буду игнорировать!

 
       3.3)SQL БД + добавление простых Индексов по КАЖДОМУ полю (таблицы три- четыре менял: Журнал доков, Регистр ОстаткиТМЦ...)
           а)(БЕЗ КЭШИРОВАНИЯ) Среднее время проведения 1 документа(19 строк) 27 сек
           б)(С КЭШИРОВАНИЕМ) Среднее время проведения 1 документа(19 строк) 3 сек

Народ прошу помощи как АВТОМАТИЗИРОВАТЬ создание Оптимальных Индексов, догадываюсь что сбором ТРАСС в SQL Server Profiler и потом прогонять в Database Engine Tuning Advisor, т.е. на выходе получить готовый скрипт с созданием индексов!

См. также

Блокировки SQL базы данных 1С 7.7

HighLoad оптимизация Платформа 1С v7.7 Конфигурации 1cv7 Абонемент ($m)

Конфигурация на 1С 7.7, показывающая блокировки на MS SQL сервере и доменных пользователей по SPID. Используется 1С++ и классы.

1 стартмани

09.11.2021    4615    8    ShoDm    17    

11

Ускорение работы 1С 7

HighLoad оптимизация Платформа 1С v7.7 Конфигурации 1cv7 Бесплатно (free)

Недорогое повышение скорости работы 1С

31.05.2013    12999    ins-post    22    

-1

Удаление нулевых значений в промежуточных регистрах

Чистка данных HighLoad оптимизация Платформа 1С v7.7 Конфигурации 1cv7 Абонемент ($m)

По статье "Зачем в 1С нужно периодически пересчитывать итоги по регистрам?" http://infostart.ru/public/177171/ Обработка для 7.7, чтобы посмотреть что же творится в БД для SQL

1 стартмани

13.03.2013    23180    54    maxpiter    15    

8

Не гибкие блокировки в "1С:Предприятие 7.7", но чуть-чуть "Управляемые".

HighLoad оптимизация Оперативный учет 7.7 Бухгалтерский учет 7.7 Расчет 7.7 Конфигурации 1cv7 Россия Бесплатно (free)

Обратились ко мне с вопросом по теме форума: http://forum.mista.ru/topic.php?id=558772 Автор темы: "DennizzM". Название: "v7: 1c v7.7 ошибки транзакции - как отловить виновника?" Текст с сокращениями: "Вопрос наверняка не новый... Итак - есть база 1c v7.7 (самописная конфа). Периодически у пользователей возникает ошибка при проведении транзакции. База работает под терминалом. Нагрузка на дисковую подсистему небольшая, CPU на нуле, RAM до черта свободного. Вопрос вот в чем - как отловить инициатора первой транзакции которая всех держит? Итак - как мне выкрутиться? ;) ...я не имею права и не могу лезть внутрь конфы и модифицировать ее.".

13.07.2011    26202    hogik    16    

11
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
0. sanfoto 502 01.01.70 03:00 Сейчас в теме
После повторных тестов пришел к выводу:

Доп.Индексы - да ускоряют получение данных,
но эффект явно виден при закэшированной(в ОЗУ SQL-сервера) базе данных!

******************************************************
******* Принудительное КЭШИРОВАНИЕ на SQL СЕРВЕРЕ******
(эффективно если на SQL сервере ОЗУ больше чем размер Базы)
методики см. в описании ниже по тексту))

Идея взята путем переработки информации из следующих источников:
http://softpoint.ru/article.php?id=18
http://www.softpoint.ru/article_id15.htm
http://www.forum.mista.ru/topic.php?id=400197
*********************
Автор плагина для обмана 1с 7.7 насчет доп.Индексов
http://itland.ru/forum//index.php?showtopic=2439&hl=DDX
***********************
Запрос №1 (что то похожее порой шлет сама 1С)
Select top 50 * from SC46(NOLOCK INDEX=VI4135) order by SP4135, ROW_ID

Время выполнения: 10203 мс
-----------------------------------------------------------------------------
Запрос №2 - видоизмененный запрос 1 без указания индекса

Select top 50 * from SC46 order by SP4135, ROW_ID

Время выполнения: 4105 мс
-------------------------------------------------------------------------------------
Запрос №3 - Добавим Все Поля входящие в Индекс

Select top 50 * from SC46(NOLOCK INDEX=VI4135) order by SP4135, Descr, ROW_ID

Время выполнения:156 мс
********************
А чтобы ОдынЦэ не убивало ЛЕВЫЕ)) индексы берем разработку -скрипт-плагин для OpenConf -файл приложен + Обработка загрузки БД в память SQL))
.....BIN\config\scripts\ExtDD.vbs
и
....Каталог_Инф_Базы\1cv7.ddx (Эти индексы в БД SQL создаст Конфигуратор при РЕСТРУКТОРИЗАЦИИ БД)
пример куска содержания моего DDX
X=RA405 %#Доп. индекс Регистр (Дв.) ОстаткиТМЦ
X=RA405 %I=MY_IDDOC | |0 |IDDOC |0

Перейти к публикации

1. Alav 13 22.04.11 18:25 Сейчас в теме
Вот низачто не поверю что в типовой 1С изменений индекса ускорит запись документа в 10 раз и после этого он станет писаться в 5 раз быстрее чем дбф (чтения у скуля и так быстрее, чем у дбф, а вот запись всегда хромала)
6. sanfoto 502 23.04.11 12:23 Сейчас в теме
(1) запись при добавлении доп.Индексов - согласен замедлится, это логично писать надо будет и в таблицу и + в доп индексы.
Но вся проблема в том что НАПРИМЕР "расчет итогов регистров" при проведении не на ТА занимает от 60 до 85 % времени проведения.
16. Alav 13 23.04.11 19:53 Сейчас в теме
(6) А что тогда понимается в статье под "время проведения 1 документа"? Разве сюда не включается запись? Или это чисто теоритическое время получения итогов в вакууме?
18. sanfoto 502 23.04.11 21:52 Сейчас в теме
(16)(17) уважаемый Alav прочитайте пожалуйста сообщение (6), время записи у меня в SQL базе НИЧТОЖНО малО ! ))
19. Alav 13 24.04.11 01:34 Сейчас в теме
(18) Еще раз читаю статью

3.1)SQL БД- стандартная Среднее время проведения 1 документа(19 строк) 30 сек
3.2)DBF БД- стандартная Среднее время проведения 1 документа(19 строк) 15 сек

3.3)SQL БД + добавление простых Индексов по КАЖДОМУ полю (таблицы три- четыре менял: Журнал доков, Регистр ОстаткиТМЦ...) - Среднее время проведения 1 документа(19 строк) 3 сек

С учетом (6) правильно ли я понял, что у вас в дбф расчет занимает 14,5 сек и сама запись 0,5 сек?
Правильно ли я понимаю что в SQL у вас расчет занимал 29 сек, а запись 1 сек

Т.е. у вас скуль получал итоги в 2 раза медленее чем дбф??? Простите вы скуль на первом пне с 64 метрами поставили?

Ведь как вы сказали добавления индексов не ускоряет запись (что логично), т.е. в можно предположить, что в п. 3.3 в 3 сек грубо говоря расчет - 2 сек + 1 сек запись


Я пока что всё верно рассуждаю?
Ёпрст; +1 Ответить
20. sanfoto 502 24.04.11 08:58 Сейчас в теме
(19)Alav,
Alav пишет:
Т.е. у вас скуль получал итоги в 2 раза медленее чем дбф??? Простите вы скуль на первом пне с 64 метрами поставили?

1) SQL стоит на серверной платформе 4-ех ядерный Проц., RAID 10, 40 Гб ОЗУ.
2) Оболочки 1с 7.7 запускаем тоже на серверной платформе на Терминальном сервере 4-ех ядерный проц, RAID 10, 10 ГБ ОЗУ.

Alav пишет:
С учетом (6) правильно ли я понял, что у вас в дбф расчет занимает 14,5 сек и сама запись 0,5 сек?

не совсем верно, Расчет регистров занимает от 60-85%, но есть же еще партионные алгоритмы и т.д.

А насчет использования DBF без СУБД хочу закончить наш спор, моему подразделению(Производство -одно из ...в крупной торговой фирме)) ) не подойдет:
1)Объемы БД не те (SQL бд уже 25 ГБ) (притом восстановление последовательности доков в отдельной БД - потом Синхронизируем УРБД)
2)Объемы документооборота все время растут
3)работа в программе КРУГЛОСУТОЧНАЯ - следовательно никакие многочасовые ПЕРЕ-ИНДЕКСАЦИИ неприемлемы.
4)Урезки/Порезки тоже не пойдут.. отчетность будет проблемна... налоговая... собственник фирмы и т.д.

Не хочу никого обидеть, но 1c 7.7 +DBF без СУБД -- ИМХО для "ларьков"! ))
Cobalt River; +1 1 Ответить
21. Alav 13 24.04.11 10:14 Сейчас в теме
(20) Я все еще пытаюсь понять откуда 3 сек. Но пока что не могу понять

было 30 сек * 85% = 25 сек расчет регистров
Значит на оставшиеся проверки и записи остается 5 сек

Индексы не дадут ускорения оставшейся части (проверки и записи). Значит после "правильных" индексов время проведения должно быть
новое время расчета + более 5 сек = время как минимум больше 5 сек. А по вашим расходам - 3 сек. Я вот понять не могу где и у кого ошибки расчета?

P.S. На разных база что ли тестировали, или откуда данные про проведения в дбф, если у вас база большая?
22. sanfoto 502 24.04.11 12:16 Сейчас в теме
(21)
Alav пишет:
Индексы не дадут ускорения оставшейся части (проверки

утверждение НЕВЕРНО! Ускорение доступа по таблицам SQL для 1с: Регистров, Документов и справочников -- также ускорит работу(поиск и получение данных) с ОБЪЕКТАМИ 1С в самих программных модулях языка 1С.

Alav пишет:
P.S. На разных база что ли тестировали, или откуда данные про проведения в дбф, если у вас база большая?

Да есть другая БД DBF, база отличается от SQL, но только объемом данных - а не Конфигурацией.
т.е. в DBF даже меньше данных значительно!
23. Alav 13 24.04.11 12:37 Сейчас в теме
24. sanfoto 502 24.04.11 12:58 Сейчас в теме
(23)
Alav пишет:
(22) В чем неверно?

sanfoto пишет:
Ускорение доступа по таблицам SQL для 1с: Регистров, Документов и справочников -- также ускорит работу с ОБЪЕКТАМИ 1С в самих программных модулях языка 1С.
ldma1979; +1 Ответить
8. sanfoto 502 23.04.11 12:51 Сейчас в теме
(1) про запись я и не писал)) я написал что общее время ПРОВЕДЕНИЯ ускорилось в 10 раз по сравнению с БД на SQl(стандарт) и в 5 раз быстрей DBF БД(стандарт)
17. Alav 13 23.04.11 19:54 Сейчас в теме
(8) "общее время ПРОВЕДЕНИЯ" - что сюда включается? Разве это не получение итогов + расчет/контроль + запись (!)?
2. hogik 443 22.04.11 22:13 Сейчас в теме
(0)
Сделайте замеры во всех режимах с перезагрузкой системы.
Т.е. исключите влияние системного и СУБД-шного кэширования.
3. vcv 89 23.04.11 10:07 Сейчас в теме
(2) Проведение документа вряд ли сильно ускорит. Например, регистр остатков в ТиС. Измерения Фирма/Склад/Номенклатура. По ним троим есть комплексный индекс. Все трое известны при проведении документа. Индекс достаточно оптимален. Вот для отчетов добавление своих индексов может кардинально ускорить быстродействие.
7. sanfoto 502 23.04.11 12:42 Сейчас в теме
vcv пишет:

(2) Проведение документа вряд ли сильно ускорит. Например, регистр остатков в ТиС. Измерения Фирма/Склад/Номенклатура. По ним троим есть комплексный индекс. Все трое известны при проведении документа. Индекс достаточно оптимален. Вот для отчетов добавление своих индексов может кардинально ускорить быстродействие.


а Связь Регистра с Таблицей ЖурналаДокументов и Справочников - вы уверены что все индексы будут использоваться ОПТИМАЛЬНО? ))
11. sanfoto 502 23.04.11 15:44 Сейчас в теме
(2) Уважаемый Владимир - ваши разработки насчет СУБД для DBF(ну или почти DBF), я пробовал/тестировал, но таки там без изменения КОДА 1С ускорения не достигнуть))
Тесты более подробные - наверное закину после выходных, как буду на работе.
12. hogik 443 23.04.11 16:43 Сейчас в теме
(11)
Я не вижу связи между Вашей публикацией и моими разработками.
А посмотреть результаты (замеры) тестов будет интересно.
Думаю, имеет смысл их обнародовать в "моих" темах форума.
Но, только с учетом моего замечания из #2 сообщения данной темы.
14. sanfoto 502 23.04.11 16:45 Сейчас в теме
(12) Связь одна есть)) УСКОРИТЬ работу 1с 7.7
притом изменяя как можно меньше кода))
15. hogik 443 23.04.11 18:29 Сейчас в теме
(14)
"УСКОРИТЬ работу 1с 7.7"(с)
Интересная разработка: http://www.wirth.ru/publ/test_1_v7dbnet/1-1-0-1
4. vcv 89 23.04.11 10:09 Сейчас в теме
(0)
3.3)SQL БД + добавление простых Индексов по Одному полю (таблицы три- четыре менял: Журнал доков, Регистр ОстаткиТМЦ...)

А разве простые индексы по одному полю не добавляются установкой галочек "Отбор движений" и "Отбор итогов" ?
5. sanfoto 502 23.04.11 12:10 Сейчас в теме
(4) )) Конфигуратор 1с 7.7 фигачит Составные Индексы и другого не дано, а с Регистрами вообще все плохо((,
моя статья приводит только пример - Тест Технологии)), я согласен что простые индексы - не всегда оптимальны. Просто тестировал данную технологию.
А вот как раз по примеру из начала статьи.
Запрос №1
Select top 50 * from SC46(NOLOCK INDEX=VI4135) order by SP4135, ROW_ID

Можно для Этого случая составить Индекс из Двух полей SP4135, ROW_ID пусть Будет "SP4135_ROW_ID" , ТОГДА SQL при составлении плана запроса

сделает примерно так Select top 50 * from SC46(NOLOCK INDEX=SP4135_ROW_ID) order by SP4135, ROW_ID,
тогда выйдем примерно на те же "Время выполнения:156 мс " и возможно даже быстрей ибо всего Два поля в индексе а не три)) размер то меньше однако!
9. nicxxx 254 23.04.11 14:58 Сейчас в теме
так ведь это боян тыщелетней давности, еще кажется на итлэнде проскакивал этот ddx
10. sanfoto 502 23.04.11 15:21 Сейчас в теме
(9) да плагин оттуда. Плагин нужен только для обмана 1С что у нее все в порядке с индексами и левых типо нету))
13. sanfoto 502 23.04.11 16:43 Сейчас в теме
А вообще...
Народ прошу помощи как АВТОМАТИЗИРОВАТЬ создание Оптимальных Индексов, догадываюсь что сбором ТРАСС в SQL Server Profiler и потом прогонять в Database Engine Tuning Advisor, т.е. на выходе получить готовый скрипт с созданием индексов!
MS SQL 2008
25. sanfoto 502 24.04.11 13:32 Сейчас в теме
http://www.sql.ru/articles/mssql/03120104BuildRightIndex.shtml
я кажется понял почему помогло даже тупое) добавление Простых Индексов по каждому полю больших таблиц!!
Любое поле, используемое в агрегирующей функции (сумма, агрегат и т.д.), которая содержит предложения GROUP BY или ORDER BY и используется в JOIN, должно рассматриваться как кандидат на индекс. Дело в том, что движок базы данных для этих операций использует индексы.
vdolynsky; +1 Ответить
26. Alav 13 24.04.11 13:39 Сейчас в теме
Все равно не согласен с методикой сравнения. Сравнивать, теплое с мягким, и на основании этого делать вывод, что красное лучше зеленого.
27. sanfoto 502 24.04.11 13:50 Сейчас в теме
Alav,
Каждому свое))
Но название статьи "Ускорение 1С 7.7 SQL в 10 раз и более - Созданием Нестандартных ИНДЕКСОВ",
а не сравнение DBF с SQL
28. Ёпрст 1063 25.04.11 10:32 Сейчас в теме
3.2)DBF БД- стандартная
Среднее время проведения 1 документа(19 строк) 15 сек - приведено просто до кучи))) DBF без СУБД прошу не обсуждать в КОММЕНТАРИЯХ СТАТЬИ, буду игнорировать!

Это полный ПЭ..

Что такое ДБФ без СУЮД ? Это как ?
Если что, база 18 гигов в ДБФ, среднее время проведения 1 документа <1 секунда на ТА и чуть больше в заднем числе.
29. Ёпрст 1063 25.04.11 10:34 Сейчас в теме
+28 ну и построение нестандартного индекса ну никак не приводит к ускорению ЗАПИСИ..

Получение останков с использованием своего индекса, да, ускорит, а вот запись - нет.
ldma1979; +1 Ответить
30. sanfoto 502 25.04.11 12:07 Сейчас в теме
(29)Ёпрст,
про запись я и не говорил)) это Alav, уперся))


(28) DBF с СУБД , это разработки типо
hogik пишет:
"УСКОРИТЬ работу 1с 7.7"(с) Интересная разработка: http://www.wirth.ru/publ/test_1_v7dbnet/1-1-0-1

или на СУБД Advantage, CodeBase 6.5 от hogik,
31. Ёпрст 1063 25.04.11 12:20 Сейчас в теме
(30) у меня обычная дбф база.
Попробуй "обгони" на скуле..
:)

Комплексная, 2 плана счетов, добавлены ресурсы для упр учета во все регистры.
База крутится 24 часа в сутки, рег. работы в воскресенье.
Перепровод - сутки - 1 год.
Что я делаю не так ?
32. Ёпрст 1063 25.04.11 12:21 Сейчас в теме
(31) единственный минус - реиндекс, на новом сервере, 15-20 минут, на старом 30-40.
48. sanfoto 502 27.04.11 12:06 Сейчас в теме
Процедура ПриОткрытии()
ЗагрузитьВнешнююКомпоненту("rainbow.dll");
КонецПроцедуры

Процедура Сформировать()
ЗапросРадуги=СоздатьОбъект("ODBCQuery");
СЗ=СоздатьОбъект("СписокЗначений");
ТекстЗапроса="Select RTRIM(CONVERT(char(30),TABLE_NAME)) from INFORMATION_SCHEMA.TABLES
|WHERE TABLE_TYPE='BASE TABLE' AND TABLE_NAME<>'dtproperties'";
Если ЗапросРадуги.Prepare(ТекстЗапроса,0,0)=1 Тогда
Если ЗапросРадуги.Open()=1 Тогда
ЗапросРадуги.GotoNext();
Пока ЗапросРадуги.IsOK()=1 Цикл
СЗ.ДобавитьЗначение(ЗапросРадуги.GetString(0));
ЗапросРадуги.GotoNext();
КонецЦикла;
ЗапросРадуги.Close();
Иначе
Предупреждение("Ошибка открытия запроса!",10);
Возврат;
КонецЕсли;
ЗапросРадуги.Reset();
Иначе
Предупреждение("Ошибка выполнения запроса!",10);
Возврат;
КонецЕсли;
Для к=1 по СЗ.РазмерСписка() Цикл
Если ЗапросРадуги.Prepare("SELECT COUNT(*) FROM "+СЗ.ПолучитьЗначение(к),0,0)=1 Тогда
Если ЗапросРадуги.Open()=1 Тогда
ЗапросРадуги.Close();
КонецЕсли;
ЗапросРадуги.Reset();
КонецЕсли;
КонецЦикла;
ЗапросРадуги="";
Предупреждение("Память для базы данных выделена!",10);
Сообщить("Память для базы данных выделена!");
КонецПроцедуры
//________________________________________________________
49. sanfoto 502 27.04.11 12:08 Сейчас в теме
(48) загружает БД в Память SQL сервера))
эффект КЭШИРОВАНИЯ достигнут!!!!! ))
50. hogik 443 27.04.11 16:13 Сейчас в теме
(49)
Да. Есть такой способ.
Это работает во всех задачах ввода/вывода.
Сделайте, пару раз, копию файла на локальном диске.
Копирование второй раз будет в 10 раз быстрее... ;-)
Вроде, я об этом и написал в сообщениях #2 и #42 данной темы.
И ЧТО мы обсуждаем? :-( :-( :-( ...
55. al_zzz 309 05.05.11 10:59 Сейчас в теме
(48) Сделал себе кэширование по Вашему посту, но прироста не получил. Тестировал на Групповой обработке(проводил 77 документов, которые медленнее всего). Результат:
- до Документ.ЗаказНаряд.Модуль Документа 1456 ПроведениеПоРегистрам(); 77 705.314887 99.02
- после Документ.ЗаказНаряд.Модуль Документа 1456 ПроведениеПоРегистрам(); 77 725.706179 99.15.
Т.е. ускорения не произошло. Объем базы 10,6Гб, ОЗУ 16Гб, MS Sql Server 2000 SP4, Windows Server 2003.
Мне не понятно, процедура "Сформировать()" должна запускаться каждым пользователем или достаточно чтобы только первым? Может я что-то не правильно делаю?
56. _Z1 38 12.05.11 19:52 Сейчас в теме
(55) Да не нужно делать никакого кеширования вообще.
не получите от этого никакого выигрыша.минимум не станет хуже.
sql сервер гораздо лучше знает
что ему надо а что не надо кешировать.

простой пример предположим у Вас есть очень большой документ Счет ( по размеру sql таблицы)
и Вам надо провести 10 000 расходных накладных. Загнав все счета в кеш Вы съедите
у sql сервера память(буферную) ( со временем конечно все сбалансируется но на время балансировки
памяти будет меньше у sql сервера да и на то чтобы снова все сбалансировать (выпихивать счета)
тоже понадобиться ресурсы sql)
33. Ёпрст 1063 25.04.11 12:21 Сейчас в теме
34. sanfoto 502 25.04.11 13:17 Сейчас в теме
Ёпрст, хорош флудить)), статья про 1с 7.7 SQL, а не сравнение с DBF

вот это по делу)))
Ёпрст пишет:
Получение останков с использованием своего индекса, да, ускорит, а вот запись - нет.
35. Alav 13 25.04.11 13:21 Сейчас в теме
Я не уперся, я просто хочу посмотреть на тот скуль, который при прочих равных условиях рвет дбф в 5 раз по скорости записи (проведение реализации)
36. sanfoto 502 25.04.11 13:50 Сейчас в теме
(35)Alav,
у тебя есть SQL сервак?
загони туда свою базу.... желательно очень большого объема.
а на самых больших табличках навешай индексов по каждому полю, а еще на _1SJOURN - это в обяз))
****************************************************
например моя Тестовая SQL БД(рабочая еще больше)

ТАБЛИЦА /Колич записей.

_1SACCSEL /29 792 921 -Отбор Счетов
..........
.......
_1SSBSEL /10 332 026
_1SENTRY /8 812 137
RA328 /5 623 467 - регистр
RA4674 /5 563 064 - регистр
RA405 /5 506 885 - регистр
....................
...................
PS: т.е. в таблицах МИЛЛИОНЫ и ДЕСЯТКИ миллионов записей!
37. sanfoto 502 25.04.11 13:55 Сейчас в теме
SQL скрипт получение количества записей
select o.name, i.rowcnt from sysobjects o
inner join sysindexes i on i.id = o.id where o.type = 'u' and indid = 1
38. Alav 13 25.04.11 16:45 Сейчас в теме
Чем больше база тем быстрее проводиться? Я же непротив что при определенных условиях правильно настроенный скуль (в том числе и индексы) будет быстрее чем типовой.
Я просто хочу понять, как у тебя без прямой записи в скуль время проведения в 5 раз меньше, чем в дбф
39. Alav 13 25.04.11 16:48 Сейчас в теме
Если бы ты написал, что время проведения в дбф - 1,5 сек. А в скуль, при правильных индексах - 3 сек, я бы и слово не сказал бы. В это я охотно поверю. Но 15 сек VS 3 сек на скуле средствами 1С - для меня выглядит, мягко говоря, невероятно
43. sanfoto 502 26.04.11 07:36 Сейчас в теме
(39) конфа не типовая у меня.
Нормальное(т.е. перезагрузка и т.п.) тестирование на рабочих серверах никто не даст мне сделать.
Буду раскачивать виртуальную тачку... как раскидаюсь с делами на работе))
40. Alav 13 25.04.11 16:49 Сейчас в теме
Ладно проехали. Ждем нормальное тестирование на сопоставимых данных
41. Alav 13 25.04.11 16:49 Сейчас в теме
Ладно проехали. Ждем нормальное тестирование на сопоставимых данных
42. hogik 443 25.04.11 23:37 Сейчас в теме
(0)
... ... (sanfoto)
При создании индекса просматриваются все записи таблицы.
И "умные" СУБД оставляют данные в оперативной памяти.
А "глупые" СУБД - не оставляют, но это за них делает операционная система.
После этого система по чтению работает быстрее, чем до создания индекса.
Но после перезагрузки сервера (железа) скорость чтения возвращается к первоначальному состоянию. А запись начинает работать, естественно, медленнее из-за лишних индексов.
Присоединяюсь к сообщению #41:
"Ждем нормальное тестирование на сопоставимых данных"(с)
44. sanfoto 502 26.04.11 18:10 Сейчас в теме
(42) да похоже дело было в случае SQL в КЭШИРОВАНИИ

первоначальный замер проводился после Группового проведения документов...нужно было для сбора трасс в ПРОФАЙЛЕРЕ


сегодня перезагружали сервера

сделал новый замер время проведения в SQL БД(тестовой) 27 секунд..
скорей всего тему закрою((

hogik,
Alav,
Ёпрст,
vcv,
спасибо за участие в обсуждении... ибо в споре рождается истина))
45. hogik 443 26.04.11 19:09 Сейчас в теме
(44)
"время проведения в SQL БД(тестовой) 27 секунд"(с)
И это очень медленно для документа в 19 строк на таком железе.
Есть над чем работать...
46. sanfoto 502 26.04.11 20:50 Сейчас в теме
(45) на движке v7dbnet
тот же док 19 строк
1)время проведения без установки ТА на документ 5 сек
2)с установкой ТА на док 0,5 сек
47. hogik 443 26.04.11 21:25 Сейчас в теме
(46)
Я не призываю использовать альтернативные "движки" в части повышения скорости.
Думаю, прежде всего надо пересматривать концепцию самой 1С.
Т.к., по моему опыту, без такого пересмотра - смена "движка" не очень помогает.
Признаюсь, я уже "не понимаю" таких слов как: "без установки ТА/с установкой ТА".
У нас нет никаких ТА уже больше десяти лет... ;-)
51. spock 601 27.04.11 19:23 Сейчас в теме
странно, почему никто не минуснул за:
- перепост;
- абсурдные выводы;
52. sanfoto 502 27.04.11 19:49 Сейчас в теме
hogik пишет:
И ЧТО мы обсуждаем? :-( :-( :-( ...

да уже наверное нечего обсуждать)) тема была создана для выяснения так сказать ИСТИНЫ))
а еще думаю кому то поможет.
spock пишет:
- абсурдные выводы;

выводы ... хм, по 1с 7.7 +SQL

1)правильные доп.индексы - да ускоряют получение данных.
+
2)принудительное Кэширование данных в SQL - да ускоряет(завтра буду автоматизировать сей процесс :D ).
*********** работает есно эффективно если у SQL сервера МНОГО оперативной памяти.... больше БАЗЫ ДАННЫХ хотябы на 2 ГБ.

---сделав пункты 1) и 2) я опять вышел на те же 3 сек. проведения дока(19 строк) )))

---если исключить пункт 1) и выполнить только п. 2), то
а) до кэширования -проведение 30 сек.
б) после кэширования около 9 сек.
53. spock 601 27.04.11 20:03 Сейчас в теме
спасибо, кэп. Ну тогда плюс поставлю :)
54. ldma1979 04.05.11 16:05 Сейчас в теме
Если вот уж совсем быть флудером, то мне вообще непонятно желание сделать индексы по ВСЕМ полям таблиц... чем-то мне это напоминает поиск наиболее вкусного яблока путем перенадкусывания всех яблок :)
57. al_zzz 309 13.05.11 06:18 Сейчас в теме
Подскажите, как создать файл .ddx? Ато везде написано, как его использовать, а как создавать - нигде не нашел....
59. sanfoto 502 01.06.12 09:34 Сейчас в теме
(57) al_zzz,
файл .ddx - формат с примером внутри файлов на скачивание.
58. awk 741 06.04.12 08:32 Сейчас в теме
(0) Оформи статью пожалуйста. За такое оформление минус, без относительно содержания.
60. sanfoto 502 01.06.12 09:39 Сейчас в теме
(58) awk,
Оформить немного в лом)).
Тема лично для меня уже неактуальна.ИМХО полностью перешел на платформу 8.2.
Но если подскажите что не нравится - поправлю.
61. MICK77 13 08.06.12 13:02 Сейчас в теме
Выложи пожалуйста свой ddx для комплексной базы. а то чет туплю с его написанием
можно прямо тут текстом
62. MICK77 13 08.06.12 14:21 Сейчас в теме
написал ddx как в примере ток с регистрами из комплексной - при загрузке выдает ошибку в строке
строки из dds
#Доп. индекс Регистр (Дв.) ОстаткиТМЦ
I=FASTACT | |0 |DATE_TIME_IDDOC,SP4062,SP408,SP418 |0

вот на вторую строку ругается :( Что не так? Подскажите!
63. MICK77 13 08.06.12 14:28 Сейчас в теме
Так методом тыка...
заменил в ddx
FASTACT на MY_IDDOC
DATE_TIME_IDDOC на IDDOC


чет это ни где не было описано, и в скачанных файлах примерчик ddx неправильный
64. sanfoto 502 23.06.12 13:26 Сейчас в теме
(63) MICK77,
это из-за различия названия полей в SQL БД - скорей всего..
В моей базе в dbo._1SJOURN у меня есть таблица DATE_TIME_IDDOC
65. ironn 5 25.04.18 14:42 Сейчас в теме
После создания доп. индексов для документа, столкнулся с ошибкой при записи документа в таблицу - Violation of PRIMARY KEY constraint 'PK_DH...'. Cannot insert duplicate key in object 'dbo.DH...'
Оказалось, что ошибка возникает, если доп. индекс расположен в файле DDS до основных индексов и, соответственно, создается до того, как создан основной индекс. Если расположить в файле DDS доп. индексы после основных, то все работает.
Поэтому пришлось немного переделать скрипт, чтобы строки с доп. индексами добавлялись после основных, если они есть.
66. ESelin 22.04.21 19:57 Сейчас в теме
(65)
Спасибо за подсказку
Подскажите, пожалуйста - как именно нужно поменять скрипт, что бы дополнительные индексы добавлялись после основных?
Спасибо
67. ESelin 23.04.21 07:30 Сейчас в теме
(66)
Похоже, нашёл вариант решения - в скрипте ExtDD.vbs заменил "F" на "I" (i) в Sub ProcessDD() - второй Do ... While цикл.
Было:
...
Case "F="
Mode = "F"
Case Else
If Mode = "F" Then
...
Стало:
...
Case "I="
Mode = "I"
Case Else
If Mode = "I" Then
...
Таким образом индексы добавляются к таблице не после описания полей, а после описания её индексов.
Единственное - если, вдруг, будет таблица без родных индексов - то и дополнительные теперь не добавятся, как я понимаю...

P.S.
Да - ExtDD.vbs работает и с 1cpp. Т.е. rainbow.dll не понадобилась.
Оставьте свое сообщение