изменение уровня изоляции на время загрузки может ускорить запись большого количества данных средствами платформы?

(0) загрузка из dt - нет

(0) Пишите прямыми запросами )))

(1)загрузка из xml

(2)мне сказали что прямые нафик тратить время на одноразовый перенос

теперь тратим время на наблюдение за загрузкой )))

(4) Время оплачивается?

(0) большое количество данных пишется в базу кусками по 100-500 объектов

+(6) в транзакции

(5)да
(6)по 1000 пишу
хочу быстрее

огласите субд и с какого на какой хотите изменить
уравень изоляции.

(0)ms sql 2008r2
а про уровни я у вас хотел спросить

(10)в(9)

уровень изоляции не пренебрежительно мало влияет на скорость записи.

2(0) Если монопольно грузишь, то в общем-то даже не могу себе представить предпосылок почему это может привести к ускорению...

Куда загружаешь? Справочник, регистр?

что значит уровень изоляции? в SQL? так тогда с как-то с темой заголовка не вяжется. Если речь идет про SQL - то никак не повлияет, если про управляемые блокировки 1С - то замедлит.

если используете 1с серверный вариант - пишите в несколько потоков.

(16)спасибо но хотелось бы чтобы запись в базу шла быстрее

(17)
ну вот. я вам предлогаю в (16) экстенсивный вариант, вместо интерсивного.

всегда сначала нужно использовать экстенсивные варианты.

в (18)
 интерсивного =  интенсивного

сказали что прямые нафик, тратить время на одноразовый перенос
сказали что прямые, нафик тратить время на одноразовый перенос
(4) Почти классика

прямые запросы - нельзя
менять уровень изоляции - можно ?

не верю.

(16)  А как это технически реализуется?

скорее всего
монопенисуально SQL ю будет на несколько потоков.

(23)  а 1С-ному серверу?

(4) Че значит "тратим время"?

Идите пишите кот, загрузку поставьте на ночь, отлаживайте на небольших объемах.

(23)ну не прямая зависимость но несколько сессий можно поставить (хыксымель уже разбит при выгрузке)
(22)несколько сессий
(21) а насчет это я не спрашивал разрешения )))

(24) Тоже.

Не могу понять проблему автора.

2(23) почему? Если будет не один шпиндель, а много, то очереди будут короче и быстрее обрабатываться. Но в общем да, немного не МС СКЛ проблема

(25)открой правила тис в ут11 и опупиней от использования кода расчета статистики например, так что момент в которы й код нужно переписывать ещё нужно отловить
а то получится ушел и всё свалилось

(30) Все равно не понял.

(30) Переход с Тис на УТ11?

(0)  а при переносе что больше всего напрягается? СКЛный сервак?

(33) Сказано же - из xml. Тут очевидна нагрузка в первую очередь нагрузка на клиента, где разворачивается файл

(31)(32)выгрузка валится на наших объемах, самое веселое в типовых правилах что когда выгружается договор рассчитывается статистика для всех договоров а потом отбирается нужное по этому договору, в нашей базе источнике это сразу валит по памяти семерку

(33)как раз таки я и хочу его напрячь чтобы запись бысрее была

(36) Зачем быстрее?

Объясни, что мешает поставить на ночь медленно и печально?

(35) измени логику выгрузки...

(38) Вошебное слово xml, котоьрое вылетает на 2Г...

(34)  ну не скажи. Я гружу из Экселя табличку около 100'000 строк в ТЧ формы, потом она уходит на сервер для анализа и загрузки. Так вот чтение файла тратит меньше минуты. А вот создание всяких новых элементов - процесс доооолгий

(41) а причём тут ексель?

(40) А причем тут скорость записи?

(39)уже )))

(42)  дабы показать, что время жрет не чтение, а запись

(43) при формировании файла данных :-)

ну вот всем всё понятно
как заставить скуль писаться быстрее?

Мне не понятно

(47) Переставь его на более другую машину.... Кроме того, смотри, что там делается при записи (вдруг ты документы проводишь при загрузке...)

Интересно, а в файловую на рам-диске не быстрее грузить будет? )

(50)потом эта файловая не влезет в скуль по причине даты в каком-нибудь регистре )))

(48)  ну смори. Думаешь ты, сто с обменом все окей, запускаешь на ночь, а он вываливается через 5 минут с ошибкой. Исправляешь и опять на ночь. И снова косяк. Так проходит месяц... А если б быстро писалось, подождал чутка и ошибку увидел

(51)  ну ошибки обмена по-любому отработаешь

2(51) сделай чтобы такого не было

(52)насчет выгрузки уже понятно как её распараллелить
и вычислить траблы

а вот только оказалось что тормозить и дибильная запись в скуль средствами 1С и загрузка тоже  занимает время

(54) а может ну его нафик?

(55) Дибильная, дибильная.

Это дибильная запись спасла не одну тыщу баз.

(56)  ТиС фарэва ) не надо переходить на УТ

А скуль строит индексы после фиксирования транзакции?

1) Перенести запись на сервер. Полностью.
2) Поставить отдельный комп с 16 гигами ОЗУ, сервер SQL, 1С туда на него.
3) Вынести tempDB, mdf, ldf на RAM диск, временные сервера 1С туда же.

(60) Перенести запись на сервер. Полностью.  - имеется ввиду
#ЕСЛИ СЕРВЕР

Отключить ИТОГИ, АГрегаты у РН.

Хотя не уверен, насчет Итогов, могут и понадобиться, перенос с такого древнего наследия мамонтов не смотрел.

(60)ну комп, точнее виртуалка уже такая есть
рамдиск завтра поюзаю

(64) **faceplam

Никаких виртуалок.

Руки надо отрывать за использование виртуалок.

(67)мне чтобы это выбить пришлось доказывать по замерам времени, так что не до жиру
"одноразовая операция" )))

(0)если один в базе то поровну как.
Если кто-то еще работает, то управляемые блокировки и быстрее и правильнее.

(68) Поставь на рабочем компе лучше.

2(67) не надо.

(71) Я про данный конкретный случай.

(71) Это, блеать, мне напоминает 1998 год и дискетту, сжатую до 60 мегабайт драйвспэйсом, ага.

а

виртуалки? Под скуль? Вам, что, не жалко себя, любимых?

(75) тсссс.

Одноразовая операция.

мама, это только для фото.

2(75) почему должно быть?

(77) ну, если вы поклонники BDSM, тогда ладно, разрешаю...

2(78) странные, ничем не мотивированные сравнения и эпитеты. Пусть останутся лежать на твоей совести коричневым пятном.

(79) на моей совести ничего не останется, она кристально чиста, с неё всё сползает, не оставляя следов.

равно как и с СКЛ в Виртуалке ваши голословные утверждения.

боюсь сказать глупость
а что будет если отключить все индексы ?

(82) Не знаю.

2(82) м.... предпосылки конечно есть, но нужно пробовать... Единственное что - их же потом опять включать.

ну может не все. Оставить те которые используются в механизмах автонумерации справочников. И те которые используются в алгоритме загрузки
ну и итоги ненужные тоже поотключать конечно

(84) Реструктуризация же есть

(85) Оставить надо индексы на ключевые поля.

(87)  ключевые поля вроде же индексируются в любом случае?

Вот я смотрю на ключ к UID документа и к нему же вижу кластреный индекс.

тут надо смотреть ещё на алгоритм загрузки. Какие то же запросы на чтение там выполняются

часть явно и дофига неявно

(90)  ну оно ж и без индекса прочитается, дольше просто

перед загрузкой отключить

1. регламентные задания
2. расчет остатков по регистрам
3. отключить регистрацию в планах обмена и последовательностях

при загрузке
1. монопольный режим
2. ОбменДанными.загрузка = истина
3. транзакции по 500 элементов

в принцепе эти простые действия дают ускорения примерно в 6 - 10 раз

(92)спасибо