статья Ускоряем регисты v77 для базы MS SQL

Основная мысль
Таблицы rg.. самые изменяемые таблицы 1с базы и любое улучшение работы с этими таблицами
обязательно улучшает общую производительность sql базы.
Для всех таблиц  rg...  меняем для поля PERIOD тип с datetime на тип smalldatetime.
Вообщем то это главная идея этой статьи.
Далее описывается как это сделать и что из этого получилось

Описание из dds
#==TABLE no 160    : Регистр ОстаткиТМЦ
# Name    |Descr                         |SQLTableNam|RecordLock
T=RG405   |Регистр ОстаткиТМЦ            |RG405      |         
#-----Fields-------
# Name                  |Descr               |Type|Length|Precision
F=PERIOD                |Period Registr      |D   |0     |0       
F=SP4062                |(P)Фирма            |C   |9     |0       
F=SP408                 |(P)Номенклатура     |C   |9     |0       
F=SP418                 |(P)Склад            |C   |9     |0       
F=SP3117                |(P)ЦенаПрод         |N   |14    |2       
F=SP411                 |(P)Количество       |N   |14    |5       
#----Indexes------
# Name                           |Descr         |Unique|Indexed fields                                              |Type      
I=PK_RG405                       |PERIOD+PROP   |1     |PERIOD,SP4062,SP408,SP418,SP3117                            |1         
I=VIA408                         |VIA408        |0     |PERIOD,SP408                                                |0         
#

Т.е. в таблице  RG405 есть Кластерный индекс PK_RG405
и индекс VIA408 ( Ускоряет отбор итогов по номенклатуре )
В терминах sql RG405 это

CREATE TABLE [RG405] (
	[PERIOD] [datetime] NOT NULL ,
	[SP4062] [char] (9) COLLATE Cyrillic_General_CI_AS NOT NULL ,
	[SP408] [char] (9) COLLATE Cyrillic_General_CI_AS NOT NULL ,
	[SP418] [char] (9) COLLATE Cyrillic_General_CI_AS NOT NULL ,
	[SP3117] [numeric](14, 2) NOT NULL ,
	[SP411] [numeric](14, 5) NOT NULL ,
	CONSTRAINT [PK_RG405] PRIMARY KEY  CLUSTERED
	(
		[PERIOD],
		[SP4062],
		[SP408],
		[SP418],
		[SP3117]
	)  ON [PRIMARY]
) ON [PRIMARY]
 

Повторюсь еще раз наша цель заменить
     [PERIOD] [datetime] NOT NULL ,
на
     [PERIOD] [smalldatetime] NOT NULL ,

После  имеем
Таблицы rg занимает меньше памяти а значит все операции (insert update delete ) выполняются быстрее и
при этом меньше расходуется буферный пул.
Т.к поле PERIOD входит в кластерный индекс то операции с индексами(со всеми индексами по rg),
то  операции над индексами ( scan table, scan index, seek index) выполняются быстрее
Также т.к длина одной записи rg стала меньше , то информация об rg ,
которая пишется в журнал транзакций, стала короче, поэтому запись в журнал транзакций об rg пишется быстрее.

Аналогично можно написать и для итогов. таблиц по бухгалтерии.

Если Вы применили все что написано выше и эфект 0 то скорее всего у Вас проблемы с дисковой системой
sql сервера. Скорее всего файлы данных и журнала транзакций расположенны на медленных дисковых массивах
и/или эти файлы сильно повержены внешней  физической фрагментации ( файловая фрагментация)
и/или внутренней (логической) фрагментации данных.


Пожелания комментарии замечания критика предложения приветствуются.

Эпилог
Надеюсь ,вышеизложенное, улучшит  работу Ваших пользователей с программой 1с77 для базы ms sql

berezdetsky писал(а) 08. Декабря 2010 :: 07:22:

Я не знаю как это измерить.
(единственно что можно сделать на тестовой ТС9 посмотреть сколько было и сколько стало чтений страниц )
по субъективным ощущениям  5%-10% при проведении.

Как это сказалось при рассчетах вне проведения не знаю.
но не зря же ms sql понизил экскалацию блокировок.
получается при тех же ресурсах(железо тоже) и при той же внешней нагрузке ms sql обрабатывает больше данных (rg) за то же самое время.

можно еще одно заклинание применить: заменить у всех ссылочных полей кодировку (collate) например на Cyrillic_General_BIN (ну или Latin1_General_BIN) - теоретически сравнение символьных полей с такой кодировкой должно ускориться.

Z1 писал(а) 08. Декабря 2010 :: 06:16:

А ты это у себя внедрил? Или это пока из разряда экспериментального исследования?

ps: статья-то где, что-то ссылки не вижу?

spock писал(а) 10. Января 2011 :: 17:59:

Смотри пост 1
То что описано далее реально работает на высоконагруженной 1с77 ms sql базе
Работает ( с сентября 2010 ) и обратно переходить не собираюсь.
Статья ( она короткая ) в самих постах с 1 по 8

Я может предложу банальность, но ты не пробовал измерение Номенклатура двинуть на первое место?

Я вот тоже задавался проблемой, как бы ускорить 1с-sql: http://infostart.ru/public/74613/
Но так, чтобы не патчить родные dll'ки и реструктуризация не страдала. Смысл сего, показывать 1с-ине, что родные таблицы не изменены, но на самом деле обращаться к своим таблицам/представлениям.

spock писал(а) 11. Января 2011 :: 16:08:

у меня так и сделано. В моей конфигурации на первом месте товар
(селективность выше)

В статье описываются не мои регистры
а регистр  для конфигурации Торговля и Склад версия 9.2 (см пост 3)
чтобы легче было читать понять и сопоставить.

Satans Claws писал(а) 12. Января 2011 :: 04:11:


Она не грогает ее а просто создает новую таблицу и из старой перекачивает данные и после удаляет старую

zaki писал(а) 12. Января 2011 :: 05:07:

Когда писал статью придумал и другие способы как все можно  добиться subj и по другому

способ а
1.удалить все индексы 2 изменить тип столбца PERIOD 3 восстановить индексы.
способ б  
1.Удалить  (drop table rg) таблицу rg 2.Создать таблицу rg с нужным типом PERIOD и со всеми индексами 3.Пересчитать итоги по rg

Каким из способов делать не очень принципиально.  В итоге каким способом не делать результат будет одинаковым.

Satans Claws писал(а) 12. Января 2011 :: 08:46:

Создал новый справочник Тест ( длина кода 5 длина наименования 25 колво уровней 1)  добавил реквизит ЗНач1 строка длина 10.
Зашел в 1с завел несколько элементов. Все работает
В sql  этому справочнику соответсвует таблица sc7911

добавил колонку  в sql таблицу sc7911

alter table sc7911
add  x1 char(10)

Захожу 1с первый раз. При верификации данных обнаружено несоответсвие. 1с останавливается.

удаляю колонку x1 из таблицы  sc7911
alter table sc7911
drop column  x1


Захожу 1с первый раз. Верификация успешно проходит.
Все данные в справочнике есть ( ни одна строка не удалена)

команда sql
select * from sc7911
возвращает также все строки таблицы.

Если хотите это обсудить то лучше наверное завести новую тему.

Z1 писал(а) 12. Января 2011 :: 10:01:


А каким методом делаешь ты?

Z1 писал(а) 15. Января 2011 :: 17:48:

То ли лыжи не едут...

Я спрашивал, что если метод проверки корректности данных в таблицах RG "пересчитать по RA, что должно быть, и сравнить с тем, что есть в RG" - не единственный, то какой еще существует?

И в "с 1 по 8" я не вижу ничего, касающегося проверки корректности данных...

"период хранения остатков" - это период между приходом и списанием?

А что смущает в необходимости итогов с точностью до секунды?

---

или ты имеешь в виду разницу между соседними значениями Period в таблицах RG?
Для регистров остатков 1Ска не дает такой настройки.
Если же ручками поддерживать актуальность этой таблицы... То в любом случае - это означает, что движения должны идти с точностью до долей секунды.
У меня, конечно, давно ходит идея - попробовать ручками поменять в Date_Time_IDdoc время на некратное секунде и попробовать провести такой документ - но все никак не соберусь.

lustin писал(а) 22. Февраля 2011 :: 04:11:


Для такой задачи
а) движения должны делаться с точностью до долей секунды
б) этих движений в пределах секунды должно быть столько, чтоб затраты на получение остатка на какой-то момент от ближайшей минуты превышали затраты на хранение.

В общем - имх#ется мне, что для такой задачи надо смотреть не в сторону 1Ски как платформы.

Цитата:

А что так сложно то:
Можно ведь так сделать

if exists (select * from dbo.sysindexes where name = N'VIA408 ' and id = object_id(N'[dbo].[RG405]'))
drop index [dbo].[RG405].[VIA408 ]
GO
ALTER TABLE [dbo].[RG405] DROP CONSTRAINT [PK_RG405]
GO
ALTER TABLE [dbo].[RG405] ALTER COLUMN PERIOD SMALLDATETIME NOT NULL
GO
ALTER TABLE [dbo].[RG405] ADD CONSTRAINT [PK_RG405] PRIMARY KEY CLUSTERED
     ([PERIOD],
      [SP4062],
      [SP408],
      [SP418],
      [SP3117]
     )  ON [PRIMARY]
GO

CREATE  INDEX [VIA408 ] ON [dbo].[RG405]([PERIOD], [SP408]) ON [PRIMARY]
GO

и вся автоматизация