статья Ускоряем регисты 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: статья-то где, что-то ссылки не вижу?