gifts2017

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

Опубликовал Александр Милютин (sanfoto) в раздел Администрирование - Оптимизация БД (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  

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

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

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

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

См. также

Подписаться Добавить вознаграждение

Комментарии

0. Александр Милютин (sanfoto) 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) 22.04.11 18:25
Вот низачто не поверю что в типовой 1С изменений индекса ускорит запись документа в 10 раз и после этого он станет писаться в 5 раз быстрее чем дбф (чтения у скуля и так быстрее, чем у дбф, а вот запись всегда хромала)
2. Владимир (hogik) 22.04.11 22:13
(0)
Сделайте замеры во всех режимах с перезагрузкой системы.
Т.е. исключите влияние системного и СУБД-шного кэширования.
3. Владислав Чинючин (vcv) 23.04.11 10:07
(2) Проведение документа вряд ли сильно ускорит. Например, регистр остатков в ТиС. Измерения Фирма/Склад/Номенклатура. По ним троим есть комплексный индекс. Все трое известны при проведении документа. Индекс достаточно оптимален. Вот для отчетов добавление своих индексов может кардинально ускорить быстродействие.
4. Владислав Чинючин (vcv) 23.04.11 10:09
(0)
3.3)SQL БД + добавление простых Индексов по Одному полю (таблицы три- четыре менял: Журнал доков, Регистр ОстаткиТМЦ...)

А разве простые индексы по одному полю не добавляются установкой галочек "Отбор движений" и "Отбор итогов" ?
5. Александр Милютин (sanfoto) 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 мс " и возможно даже быстрей ибо всего Два поля в индексе а не три)) размер то меньше однако!
6. Александр Милютин (sanfoto) 23.04.11 12:23
(1) запись при добавлении доп.Индексов - согласен замедлится, это логично писать надо будет и в таблицу и + в доп индексы.
Но вся проблема в том что НАПРИМЕР "расчет итогов регистров" при проведении не на ТА занимает от 60 до 85 % времени проведения.
7. Александр Милютин (sanfoto) 23.04.11 12:42
vcv пишет:

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


а Связь Регистра с Таблицей ЖурналаДокументов и Справочников - вы уверены что все индексы будут использоваться ОПТИМАЛЬНО? ))
8. Александр Милютин (sanfoto) 23.04.11 12:51
(1) про запись я и не писал)) я написал что общее время ПРОВЕДЕНИЯ ускорилось в 10 раз по сравнению с БД на SQl(стандарт) и в 5 раз быстрей DBF БД(стандарт)
9. nicolas eliseev (nicxxx) 23.04.11 14:58
так ведь это боян тыщелетней давности, еще кажется на итлэнде проскакивал этот ddx
10. Александр Милютин (sanfoto) 23.04.11 15:21
(9) да плагин оттуда. Плагин нужен только для обмана 1С что у нее все в порядке с индексами и левых типо нету))
11. Александр Милютин (sanfoto) 23.04.11 15:44
(2) Уважаемый Владимир - ваши разработки насчет СУБД для DBF(ну или почти DBF), я пробовал/тестировал, но таки там без изменения КОДА 1С ускорения не достигнуть))
Тесты более подробные - наверное закину после выходных, как буду на работе.
12. Владимир (hogik) 23.04.11 16:43
(11)
Я не вижу связи между Вашей публикацией и моими разработками.
А посмотреть результаты (замеры) тестов будет интересно.
Думаю, имеет смысл их обнародовать в "моих" темах форума.
Но, только с учетом моего замечания из #2 сообщения данной темы.
13. Александр Милютин (sanfoto) 23.04.11 16:43
А вообще...
Народ прошу помощи как АВТОМАТИЗИРОВАТЬ создание Оптимальных Индексов, догадываюсь что сбором ТРАСС в SQL Server Profiler и потом прогонять в Database Engine Tuning Advisor, т.е. на выходе получить готовый скрипт с созданием индексов!
MS SQL 2008
14. Александр Милютин (sanfoto) 23.04.11 16:45
(12) Связь одна есть)) УСКОРИТЬ работу 1с 7.7
притом изменяя как можно меньше кода))
15. Владимир (hogik) 23.04.11 18:29
(14)
"УСКОРИТЬ работу 1с 7.7"(с)
Интересная разработка: http://www.wirth.ru/publ/test_1_v7dbnet/1-1-0-1
16. Алексей (Alav) 23.04.11 19:53
(6) А что тогда понимается в статье под "время проведения 1 документа"? Разве сюда не включается запись? Или это чисто теоритическое время получения итогов в вакууме?
17. Алексей (Alav) 23.04.11 19:54
(8) "общее время ПРОВЕДЕНИЯ" - что сюда включается? Разве это не получение итогов + расчет/контроль + запись (!)?
18. Александр Милютин (sanfoto) 23.04.11 21:52
(16)(17) уважаемый Alav прочитайте пожалуйста сообщение (6), время записи у меня в SQL базе НИЧТОЖНО малО ! ))
19. Алексей (Alav) 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 Ответить 1
20. Александр Милютин (sanfoto) 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) 24.04.11 10:14
(20) Я все еще пытаюсь понять откуда 3 сек. Но пока что не могу понять

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

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

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

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

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

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

sanfoto пишет:
Ускорение доступа по таблицам SQL для 1с: Регистров, Документов и справочников -- также ускорит работу с ОБЪЕКТАМИ 1С в самих программных модулях языка 1С.
ldma1979; +1 Ответить
25. Александр Милютин (sanfoto) 24.04.11 13:32
http://www.sql.ru/articles/mssql/03120104BuildRightIndex.shtml
я кажется понял почему помогло даже тупое) добавление Простых Индексов по каждому полю больших таблиц!!
Любое поле, используемое в агрегирующей функции (сумма, агрегат и т.д.), которая содержит предложения GROUP BY или ORDER BY и используется в JOIN, должно рассматриваться как кандидат на индекс. Дело в том, что движок базы данных для этих операций использует индексы.
26. Алексей (Alav) 24.04.11 13:39
Все равно не согласен с методикой сравнения. Сравнивать, теплое с мягким, и на основании этого делать вывод, что красное лучше зеленого.
27. Александр Милютин (sanfoto) 24.04.11 13:50
Alav,
Каждому свое))
Но название статьи "Ускорение 1С 7.7 SQL в 10 раз и более - Созданием Нестандартных ИНДЕКСОВ",
а не сравнение DBF с SQL
28. Епрст (Ёпрст) 25.04.11 10:32
3.2)DBF БД- стандартная
Среднее время проведения 1 документа(19 строк) 15 сек - приведено просто до кучи))) DBF без СУБД прошу не обсуждать в КОММЕНТАРИЯХ СТАТЬИ, буду игнорировать!

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

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

Получение останков с использованием своего индекса, да, ускорит, а вот запись - нет.
30. Александр Милютин (sanfoto) 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. Епрст (Ёпрст) 25.04.11 12:20
(30) у меня обычная дбф база.
Попробуй "обгони" на скуле..
:)

Комплексная, 2 плана счетов, добавлены ресурсы для упр учета во все регистры.
База крутится 24 часа в сутки, рег. работы в воскресенье.
Перепровод - сутки - 1 год.
Что я делаю не так ?
32. Епрст (Ёпрст) 25.04.11 12:21
(31) единственный минус - реиндекс, на новом сервере, 15-20 минут, на старом 30-40.
33. Епрст (Ёпрст) 25.04.11 12:21
34. Александр Милютин (sanfoto) 25.04.11 13:17
Ёпрст, хорош флудить)), статья про 1с 7.7 SQL, а не сравнение с DBF

вот это по делу)))
Ёпрст пишет:
Получение останков с использованием своего индекса, да, ускорит, а вот запись - нет.
35. Алексей (Alav) 25.04.11 13:21
Я не уперся, я просто хочу посмотреть на тот скуль, который при прочих равных условиях рвет дбф в 5 раз по скорости записи (проведение реализации)
36. Александр Милютин (sanfoto) 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) 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) 25.04.11 16:45
Чем больше база тем быстрее проводиться? Я же непротив что при определенных условиях правильно настроенный скуль (в том числе и индексы) будет быстрее чем типовой.
Я просто хочу понять, как у тебя без прямой записи в скуль время проведения в 5 раз меньше, чем в дбф
39. Алексей (Alav) 25.04.11 16:48
Если бы ты написал, что время проведения в дбф - 1,5 сек. А в скуль, при правильных индексах - 3 сек, я бы и слово не сказал бы. В это я охотно поверю. Но 15 сек VS 3 сек на скуле средствами 1С - для меня выглядит, мягко говоря, невероятно
40. Алексей (Alav) 25.04.11 16:49
Ладно проехали. Ждем нормальное тестирование на сопоставимых данных
41. Алексей (Alav) 25.04.11 16:49
Ладно проехали. Ждем нормальное тестирование на сопоставимых данных
42. Владимир (hogik) 25.04.11 23:37
(0)
... ... (sanfoto)
При создании индекса просматриваются все записи таблицы.
И "умные" СУБД оставляют данные в оперативной памяти.
А "глупые" СУБД - не оставляют, но это за них делает операционная система.
После этого система по чтению работает быстрее, чем до создания индекса.
Но после перезагрузки сервера (железа) скорость чтения возвращается к первоначальному состоянию. А запись начинает работать, естественно, медленнее из-за лишних индексов.
Присоединяюсь к сообщению #41:
"Ждем нормальное тестирование на сопоставимых данных"(с)
43. Александр Милютин (sanfoto) 26.04.11 07:36
(39) конфа не типовая у меня.
Нормальное(т.е. перезагрузка и т.п.) тестирование на рабочих серверах никто не даст мне сделать.
Буду раскачивать виртуальную тачку... как раскидаюсь с делами на работе))
44. Александр Милютин (sanfoto) 26.04.11 18:10
(42) да похоже дело было в случае SQL в КЭШИРОВАНИИ

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


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

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

hogik,
Alav,
Ёпрст,
vcv,
спасибо за участие в обсуждении... ибо в споре рождается истина))
45. Владимир (hogik) 26.04.11 19:09
(44)
"время проведения в SQL БД(тестовой) 27 секунд"(с)
И это очень медленно для документа в 19 строк на таком железе.
Есть над чем работать...
46. Александр Милютин (sanfoto) 26.04.11 20:50
(45) на движке v7dbnet
тот же док 19 строк
1)время проведения без установки ТА на документ 5 сек
2)с установкой ТА на док 0,5 сек
47. Владимир (hogik) 26.04.11 21:25
(46)
Я не призываю использовать альтернативные "движки" в части повышения скорости.
Думаю, прежде всего надо пересматривать концепцию самой 1С.
Т.к., по моему опыту, без такого пересмотра - смена "движка" не очень помогает.
Признаюсь, я уже "не понимаю" таких слов как: "без установки ТА/с установкой ТА".
У нас нет никаких ТА уже больше десяти лет... ;-)
48. Александр Милютин (sanfoto) 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) 27.04.11 12:08
(48) загружает БД в Память SQL сервера))
эффект КЭШИРОВАНИЯ достигнут!!!!! ))
50. Владимир (hogik) 27.04.11 16:13
(49)
Да. Есть такой способ.
Это работает во всех задачах ввода/вывода.
Сделайте, пару раз, копию файла на локальном диске.
Копирование второй раз будет в 10 раз быстрее... ;-)
Вроде, я об этом и написал в сообщениях #2 и #42 данной темы.
И ЧТО мы обсуждаем? :-( :-( :-( ...
51. Кирилл Иконников (spock) 27.04.11 19:23
странно, почему никто не минуснул за:
- перепост;
- абсурдные выводы;
52. Александр Милютин (sanfoto) 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) 27.04.11 20:03
спасибо, кэп. Ну тогда плюс поставлю :)
54. Дмитрий Лазарев (ldma1979) 04.05.11 16:05
Если вот уж совсем быть флудером, то мне вообще непонятно желание сделать индексы по ВСЕМ полям таблиц... чем-то мне это напоминает поиск наиболее вкусного яблока путем перенадкусывания всех яблок :)
55. Al (al_zzz) 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) 12.05.11 19:52
(55) Да не нужно делать никакого кеширования вообще.
не получите от этого никакого выигрыша.минимум не станет хуже.
sql сервер гораздо лучше знает
что ему надо а что не надо кешировать.

простой пример предположим у Вас есть очень большой документ Счет ( по размеру sql таблицы)
и Вам надо провести 10 000 расходных накладных. Загнав все счета в кеш Вы съедите
у sql сервера память(буферную) ( со временем конечно все сбалансируется но на время балансировки
памяти будет меньше у sql сервера да и на то чтобы снова все сбалансировать (выпихивать счета)
тоже понадобиться ресурсы sql)
57. Al (al_zzz) 13.05.11 06:18
Подскажите, как создать файл .ddx? Ато везде написано, как его использовать, а как создавать - нигде не нашел....
58. Василий Казьмин (awk) 06.04.12 08:32
(0) Оформи статью пожалуйста. За такое оформление минус, без относительно содержания.
59. Александр Милютин (sanfoto) 01.06.12 09:34
(57) al_zzz,
файл .ddx - формат с примером внутри файлов на скачивание.
60. Александр Милютин (sanfoto) 01.06.12 09:39
(58) awk,
Оформить немного в лом)).
Тема лично для меня уже неактуальна.ИМХО полностью перешел на платформу 8.2.
Но если подскажите что не нравится - поправлю.
61. MICK77 Владислав (MICK77) 08.06.12 13:02
Выложи пожалуйста свой ddx для комплексной базы. а то чет туплю с его написанием
можно прямо тут текстом
62. MICK77 Владислав (MICK77) 08.06.12 14:21
написал ddx как в примере ток с регистрами из комплексной - при загрузке выдает ошибку в строке
строки из dds
#Доп. индекс Регистр (Дв.) ОстаткиТМЦ
I=FASTACT | |0 |DATE_TIME_IDDOC,SP4062,SP408,SP418 |0

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


чет это ни где не было описано, и в скачанных файлах примерчик ddx неправильный
64. Александр Милютин (sanfoto) 23.06.12 13:26
(63) MICK77,
это из-за различия названия полей в SQL БД - скорей всего..
В моей базе в dbo._1SJOURN у меня есть таблица DATE_TIME_IDDOC
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа