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

27.04.11

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

Доп.Индексы - да ускоряют получение данных,
но эффект явно виден при закэшированной(в ОЗУ 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

Скачать файл

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование		По подписке [?]	Купить один файл
ALL.zip .zip 131,79Kb 146	146	Скачать (1 SM)	Купить за 1 850 руб.

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

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

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

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

Сразу уточняю размер БД взятой для теста 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, т.е. на выходе получить готовый скрипт с созданием индексов!

+26 –

См. также

Как ускорить 1С за 5 минут – Протокол Shared Memory (1С 7.7)

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

Вариант для SQL 77

18.10.2022 2665 Dionisiy 7

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

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

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

1 стартмани

09.11.2021 4975 9 ShoDm 17

Еще раз, по-новому: производительность 1С: 7.7/1С: 8 + SQL

HighLoad оптимизация Инструменты администратора БД Системный администратор Программист Платформа 1С v7.7 Платформа 1С v8.3 Конфигурации 1cv8 Конфигурации 1cv7 Бесплатно (free)

Еще один подход к увеличению производительности 1C+SQL = использование RAM-дисков

16.02.2015 44500 kos 35

Тест производительности 1С сервера/компьютера v.2014.1

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

1С сама проверит своё железо и скажет, чего ей не хватает!

1 стартмани

12.01.2014 23444 80 by_1Cnik 7

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

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

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

31.05.2013 13273 ins-post 22

-1

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

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

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

1 стартмани

13.03.2013 23540 54 maxpiter 15

Автоматическая переиндексация базы

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

Автоматическая переиндексация базы

11.09.2012 17687 Gazulo 3

Не гибкие блокировки в "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 26684 hogik 16

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

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 сек запись

Я пока что всё верно рассуждаю?

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 без СУБД -- ИМХО для "ларьков"! ))

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 Сейчас в теме

(22) В чем неверно?

24. sanfoto 502 24.04.11 12:58 Сейчас в теме

(23)

Alav пишет:
(22) В чем неверно?

sanfoto пишет:
Ускорение доступа по таблицам SQL для 1с: Регистров, Документов и справочников -- также ускорит работу с ОБЪЕКТАМИ 1С в самих программных модулях языка 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 444 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 444 23.04.11 16:43 Сейчас в теме

(11)
Я не вижу связи между Вашей публикацией и моими разработками.
А посмотреть результаты (замеры) тестов будет интересно.
Думаю, имеет смысл их обнародовать в "моих" темах форума.
Но, только с учетом моего замечания из #2 сообщения данной темы.

14. sanfoto 502 23.04.11 16:45 Сейчас в теме

(12) Связь одна есть)) УСКОРИТЬ работу 1с 7.7
притом изменяя как можно меньше кода))

15. hogik 444 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 255 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, должно рассматриваться как кандидат на индекс. Дело в том, что движок базы данных для этих операций использует индексы.

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. Ёпрст 1065 25.04.11 10:32 Сейчас в теме

3.2)DBF БД- стандартная
Среднее время проведения 1 документа(19 строк) 15 сек - приведено просто до кучи))) DBF без СУБД прошу не обсуждать в КОММЕНТАРИЯХ СТАТЬИ, буду игнорировать!

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

Что такое ДБФ без СУЮД ? Это как ?
Если что, база 18 гигов в ДБФ, среднее время проведения 1 документа <1 секунда на ТА и чуть больше в заднем числе.

29. Ёпрст 1065 25.04.11 10:34 Сейчас в теме

+28 ну и построение нестандартного индекса ну никак не приводит к ускорению ЗАПИСИ..

Получение останков с использованием своего индекса, да, ускорит, а вот запись - нет.

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. Ёпрст 1065 25.04.11 12:20 Сейчас в теме

(30) у меня обычная дбф база.
Попробуй "обгони" на скуле..
:)

Комплексная, 2 плана счетов, добавлены ресурсы для упр учета во все регистры.
База крутится 24 часа в сутки, рег. работы в воскресенье.
Перепровод - сутки - 1 год.
Что я делаю не так ?

32. Ёпрст 1065 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 444 27.04.11 16:13 Сейчас в теме

(49)
Да. Есть такой способ.
Это работает во всех задачах ввода/вывода.
Сделайте, пару раз, копию файла на локальном диске.
Копирование второй раз будет в 10 раз быстрее... ;-)
Вроде, я об этом и написал в сообщениях #2 и #42 данной темы.
И ЧТО мы обсуждаем? :-( :-( :-( ...

55. al_zzz 303 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. Ёпрст 1065 25.04.11 12:21 Сейчас в теме

+32 юзверей, 60-70.

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 444 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 444 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 444 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 303 13.05.11 06:18 Сейчас в теме

Подскажите, как создать файл .ddx? Ато везде написано, как его использовать, а как создавать - нигде не нашел....

59. sanfoto 502 01.06.12 09:34 Сейчас в теме

(57) al_zzz,
файл .ddx - формат с примером внутри файлов на скачивание.

58. awk 745 06.04.12 08:32 Сейчас в теме

(0) Оформи статью пожалуйста. За такое оформление минус, без относительно содержания.

60. sanfoto 502 01.06.12 09:39 Сейчас в теме

(58) awk,
Оформить немного в лом)).
Тема лично для меня уже неактуальна.ИМХО полностью перешел на платформу 8.2.
Но если подскажите что не нравится - поправлю.

61. MICK77 15 08.06.12 13:02 Сейчас в теме

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

62. MICK77 15 08.06.12 14:21 Сейчас в теме

написал ddx как в примере ток с регистрами из комплексной - при загрузке выдает ошибку в строке
строки из dds
#Доп. индекс Регистр (Дв.) ОстаткиТМЦ
I=FASTACT | |0 |DATE_TIME_IDDOC,SP4062,SP408,SP418 |0

вот на вторую строку ругается :( Что не так? Подскажите!

63. MICK77 15 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 не понадобилась.