Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Ускорить определение наличия блокировок на таблицах  [new]
Bone serpent
Member

Откуда:
Сообщений: 168
Использую в базе 1С7.7 нестандартные блокировки и определение, заблокированы ли нужные таблицы, или нет.
Для определения заблокированности работают запросы типа:
SELECT rsc_objid FROM master.dbo.syslockinfo
	WHERE rsc_indid=0 and rsc_objid!=0 and req_spid!=@@SPID
	and (req_mode=5 /*-X-*/ or req_mode=8 /*-IX-*/)
	and (
		rsc_objid = OBJECT_ID('RG4314') OR 
		rsc_objid = OBJECT_ID('RG3549') OR 
		rsc_objid = OBJECT_ID('RG328') OR 
		rsc_objid = OBJECT_ID('_1SBKTTL') OR 
		rsc_objid = OBJECT_ID('_1SBKTTLC'))

И кажется, что запрос работает медленно. По крайней мере в Activity Monitor в колонке Average Duration он в первой десятке.

Действительно ли он медленно работает, или это только кажется?
Если медленно, то как его ускорить?

К сообщению приложен файл. Размер - 51Kb
23 окт 14, 13:36    [16748175]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
Bone serpent
Member

Откуда:
Сообщений: 168
Так выглядит план запроса
+
<ShowPlanXML xmlns="http://schemas.microsoft.com/sqlserver/2004/07/showplan" Version="1.2" Build="11.0.2100.60">
  <BatchSequence>
    <Batch>
      <Statements>
        <StmtSimple StatementText="SELECT rsc_objid FROM master.dbo.syslockinfo&#xD;&#xA;	WHERE rsc_indid=0 and rsc_objid!=0 and req_spid!=@@SPID&#xD;&#xA;	and (req_mode=5 /*-X-*/ or req_mode=8 /*-IX-*/)&#xD;&#xA;	and (&#xD;&#xA;		rsc_objid = OBJECT_ID('RG4314') OR &#xD;&#xA;		rsc_objid = OBJECT_ID('RG3549') OR &#xD;&#xA;		rsc_objid = OBJECT_ID('RG328') OR &#xD;&#xA;		rsc_objid = OBJECT_ID('_1SBKTTL') OR &#xD;&#xA;		rsc_objid = OBJECT_ID('_1SBKTTLC'))" StatementId="1" StatementCompId="2" StatementType="SELECT" RetrievedFromCache="true" StatementSubTreeCost="0.604401" StatementEstRows="66.8261" StatementOptmLevel="FULL" QueryHash="0xCF0F799ECABFF6DE" QueryPlanHash="0x21C2A06D79A09644" StatementOptmEarlyAbortReason="GoodEnoughPlanFound">
          <StatementSetOptions QUOTED_IDENTIFIER="true" ARITHABORT="false" CONCAT_NULL_YIELDS_NULL="true" ANSI_NULLS="true" ANSI_PADDING="true" ANSI_WARNINGS="true" NUMERIC_ROUNDABORT="false" />
          <QueryPlan NonParallelPlanReason="MaxDOPSetToOne" CachedPlanSize="24" CompileTime="2" CompileCPU="2" CompileMemory="288">
            <MemoryGrantInfo SerialRequiredMemory="0" SerialDesiredMemory="0" />
            <OptimizerHardwareDependentProperties EstimatedAvailableMemoryGrant="401066" EstimatedPagesCached="601600" EstimatedAvailableDegreeOfParallelism="1" />
            <RelOp NodeId="0" PhysicalOp="Filter" LogicalOp="Filter" EstimateRows="66.8261" EstimateIO="0" EstimateCPU="0.46949" AvgRowSize="11" EstimatedTotalSubtreeCost="0.604401" Parallel="0" EstimateRebinds="0" EstimateRewinds="0" EstimatedExecutionMode="Row">
              <OutputList>
                <ColumnReference Table="[SYSLOCKINFO]" Column="rsc_objid" />
              </OutputList>
              <Filter StartupExpression="0">
                <RelOp NodeId="1" PhysicalOp="Table-valued function" LogicalOp="Table-valued function" EstimateRows="134911" EstimateIO="0" EstimateCPU="0.134911" AvgRowSize="18" EstimatedTotalSubtreeCost="0.134911" Parallel="0" EstimateRebinds="0" EstimateRewinds="0" EstimatedExecutionMode="Row">
                  <OutputList>
                    <ColumnReference Table="[SYSLOCKINFO]" Column="rsc_indid" />
                    <ColumnReference Table="[SYSLOCKINFO]" Column="rsc_objid" />
                    <ColumnReference Table="[SYSLOCKINFO]" Column="req_mode" />
                    <ColumnReference Table="[SYSLOCKINFO]" Column="req_spid" />
                  </OutputList>
                  <TableValuedFunction>
                    <DefinedValues>
                      <DefinedValue>
                        <ColumnReference Table="[SYSLOCKINFO]" Column="rsc_indid" />
                      </DefinedValue>
                      <DefinedValue>
                        <ColumnReference Table="[SYSLOCKINFO]" Column="rsc_objid" />
                      </DefinedValue>
                      <DefinedValue>
                        <ColumnReference Table="[SYSLOCKINFO]" Column="req_mode" />
                      </DefinedValue>
                      <DefinedValue>
                        <ColumnReference Table="[SYSLOCKINFO]" Column="req_spid" />
                      </DefinedValue>
                    </DefinedValues>
                    <Object Table="[SYSLOCKINFO]" />
                  </TableValuedFunction>
                </RelOp>
                <Predicate>
                  <ScalarOperator ScalarString="SYSLOCKINFO.[req_spid]&lt;&gt;CONVERT_IMPLICIT(int,@@spid,0) AND (SYSLOCKINFO.[rsc_objid]=object_id(N'RG4314') OR SYSLOCKINFO.[rsc_objid]=object_id(N'RG3549') OR SYSLOCKINFO.[rsc_objid]=object_id(N'RG328') OR SYSLOCKINFO.[rsc_objid]=object_id(N'_1SBKTTL') OR SYSLOCKINFO.[rsc_objid]=object_id(N'_1SBKTTLC')) AND SYSLOCKINFO.[rsc_indid]=(0) AND SYSLOCKINFO.[rsc_objid]&lt;&gt;(0) AND (SYSLOCKINFO.[req_mode]=(5) OR SYSLOCKINFO.[req_mode]=(8))">
                    <Logical Operation="AND">
                      <ScalarOperator>
                        <Compare CompareOp="NE">
                          <ScalarOperator>
                            <Identifier>
                              <ColumnReference Table="[SYSLOCKINFO]" Column="req_spid" />
                            </Identifier>
                          </ScalarOperator>
                          <ScalarOperator>
                            <Identifier>
                              <ColumnReference Column="ConstExpr1000">
                                <ScalarOperator>
                                  <Convert DataType="int" Style="0" Implicit="1">
                                    <ScalarOperator>
                                      <Intrinsic FunctionName="@@spid" />
                                    </ScalarOperator>
                                  </Convert>
                                </ScalarOperator>
                              </ColumnReference>
                            </Identifier>
                          </ScalarOperator>
                        </Compare>
                      </ScalarOperator>
                      <ScalarOperator>
                        <Logical Operation="OR">
                          <ScalarOperator>
                            <Compare CompareOp="EQ">
                              <ScalarOperator>
                                <Identifier>
                                  <ColumnReference Table="[SYSLOCKINFO]" Column="rsc_objid" />
                                </Identifier>
                              </ScalarOperator>
                              <ScalarOperator>
                                <Identifier>
                                  <ColumnReference Column="ConstExpr1001">
                                    <ScalarOperator>
                                      <Intrinsic FunctionName="object_id">
                                        <ScalarOperator>
                                          <Const ConstValue="N'RG4314'" />
                                        </ScalarOperator>
                                        <ScalarOperator>
                                          <Const ConstValue="" />
                                        </ScalarOperator>
                                      </Intrinsic>
                                    </ScalarOperator>
                                  </ColumnReference>
                                </Identifier>
                              </ScalarOperator>
                            </Compare>
                          </ScalarOperator>
                          <ScalarOperator>
                            <Compare CompareOp="EQ">
                              <ScalarOperator>
                                <Identifier>
                                  <ColumnReference Table="[SYSLOCKINFO]" Column="rsc_objid" />
                                </Identifier>
                              </ScalarOperator>
                              <ScalarOperator>
                                <Identifier>
                                  <ColumnReference Column="ConstExpr1002">
                                    <ScalarOperator>
                                      <Intrinsic FunctionName="object_id">
                                        <ScalarOperator>
                                          <Const ConstValue="N'RG3549'" />
                                        </ScalarOperator>
                                        <ScalarOperator>
                                          <Const ConstValue="" />
                                        </ScalarOperator>
                                      </Intrinsic>
                                    </ScalarOperator>
                                  </ColumnReference>
                                </Identifier>
                              </ScalarOperator>
                            </Compare>
                          </ScalarOperator>
                          <ScalarOperator>
                            <Compare CompareOp="EQ">
                              <ScalarOperator>
                                <Identifier>
                                  <ColumnReference Table="[SYSLOCKINFO]" Column="rsc_objid" />
                                </Identifier>
                              </ScalarOperator>
                              <ScalarOperator>
                                <Identifier>
                                  <ColumnReference Column="ConstExpr1003">
                                    <ScalarOperator>
                                      <Intrinsic FunctionName="object_id">
                                        <ScalarOperator>
                                          <Const ConstValue="N'RG328'" />
                                        </ScalarOperator>
                                        <ScalarOperator>
                                          <Const ConstValue="" />
                                        </ScalarOperator>
                                      </Intrinsic>
                                    </ScalarOperator>
                                  </ColumnReference>
                                </Identifier>
                              </ScalarOperator>
                            </Compare>
                          </ScalarOperator>
                          <ScalarOperator>
                            <Compare CompareOp="EQ">
                              <ScalarOperator>
                                <Identifier>
                                  <ColumnReference Table="[SYSLOCKINFO]" Column="rsc_objid" />
                                </Identifier>
                              </ScalarOperator>
                              <ScalarOperator>
                                <Identifier>
                                  <ColumnReference Column="ConstExpr1004">
                                    <ScalarOperator>
                                      <Intrinsic FunctionName="object_id">
                                        <ScalarOperator>
                                          <Const ConstValue="N'_1SBKTTL'" />
                                        </ScalarOperator>
                                        <ScalarOperator>
                                          <Const ConstValue="" />
                                        </ScalarOperator>
                                      </Intrinsic>
                                    </ScalarOperator>
                                  </ColumnReference>
                                </Identifier>
                              </ScalarOperator>
                            </Compare>
                          </ScalarOperator>
                          <ScalarOperator>
                            <Compare CompareOp="EQ">
                              <ScalarOperator>
                                <Identifier>
                                  <ColumnReference Table="[SYSLOCKINFO]" Column="rsc_objid" />
                                </Identifier>
                              </ScalarOperator>
                              <ScalarOperator>
                                <Identifier>
                                  <ColumnReference Column="ConstExpr1005">
                                    <ScalarOperator>
                                      <Intrinsic FunctionName="object_id">
                                        <ScalarOperator>
                                          <Const ConstValue="N'_1SBKTTLC'" />
                                        </ScalarOperator>
                                        <ScalarOperator>
                                          <Const ConstValue="" />
                                        </ScalarOperator>
                                      </Intrinsic>
                                    </ScalarOperator>
                                  </ColumnReference>
                                </Identifier>
                              </ScalarOperator>
                            </Compare>
                          </ScalarOperator>
                        </Logical>
                      </ScalarOperator>
                      <ScalarOperator>
                        <Compare CompareOp="EQ">
                          <ScalarOperator>
                            <Identifier>
                              <ColumnReference Table="[SYSLOCKINFO]" Column="rsc_indid" />
                            </Identifier>
                          </ScalarOperator>
                          <ScalarOperator>
                            <Const ConstValue="(0)" />
                          </ScalarOperator>
                        </Compare>
                      </ScalarOperator>
                      <ScalarOperator>
                        <Compare CompareOp="NE">
                          <ScalarOperator>
                            <Identifier>
                              <ColumnReference Table="[SYSLOCKINFO]" Column="rsc_objid" />
                            </Identifier>
                          </ScalarOperator>
                          <ScalarOperator>
                            <Const ConstValue="(0)" />
                          </ScalarOperator>
                        </Compare>
                      </ScalarOperator>
                      <ScalarOperator>
                        <Logical Operation="OR">
                          <ScalarOperator>
                            <Compare CompareOp="EQ">
                              <ScalarOperator>
                                <Identifier>
                                  <ColumnReference Table="[SYSLOCKINFO]" Column="req_mode" />
                                </Identifier>
                              </ScalarOperator>
                              <ScalarOperator>
                                <Const ConstValue="(5)" />
                              </ScalarOperator>
                            </Compare>
                          </ScalarOperator>
                          <ScalarOperator>
                            <Compare CompareOp="EQ">
                              <ScalarOperator>
                                <Identifier>
                                  <ColumnReference Table="[SYSLOCKINFO]" Column="req_mode" />
                                </Identifier>
                              </ScalarOperator>
                              <ScalarOperator>
                                <Const ConstValue="(8)" />
                              </ScalarOperator>
                            </Compare>
                          </ScalarOperator>
                        </Logical>
                      </ScalarOperator>
                    </Logical>
                  </ScalarOperator>
                </Predicate>
              </Filter>
            </RelOp>
          </QueryPlan>
        </StmtSimple>
      </Statements>
    </Batch>
  </BatchSequence>
</ShowPlanXML>


Модератор: Убирайте разрывающие монитор простыни в тег spoiler, пожалуйста.


К сообщению приложен файл. Размер - 9Kb


Сообщение было отредактировано: 23 окт 14, 14:10
23 окт 14, 13:38    [16748192]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
Glory
Member

Откуда:
Сообщений: 104760
Bone serpent
Действительно ли он медленно работает, или это только кажется?

396 ms - это для вас долго ?
23 окт 14, 13:39    [16748202]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
Bone serpent
Member

Откуда:
Сообщений: 168
Glory
396 ms - это для вас долго ?

Смотря для чего. 396 ms это же 0.4 секунды. Почти что полсекунды. Если столько выбираются, например, остатки по складу при проведении документа, то нормально. А если эти полсекунды добавляются к времени проведения документа просто как процесс ожидания освобождения таблиц, тогда долговато. Те документы, которые проводились полсекунды (если, конечно, не возникало ожидание блокировки) будут проводиться секунду. В два раза дольше фактически. В такой ситуации полсекунды как-то совсем много.
23 окт 14, 14:04    [16748434]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
Glory
Member

Откуда:
Сообщений: 104760
Bone serpent
Смотря для чего

Ну так все смотрят по-разному

Bone serpent
В такой ситуации полсекунды как-то совсем много.

Для этого конкрентного запроса для вас лично это много или мало ?
23 окт 14, 14:12    [16748506]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
Причем тут проводки? 0.4 секунды для анализа разве это много?
23 окт 14, 14:31    [16748686]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
Bone serpent
Member

Откуда:
Сообщений: 168
Владислав Колосов
Причем тут проводки? 0.4 секунды для анализа разве это много?

Для получения <10 записей из довольно таки небольшой таблицы syslockinfo - по моему таки много.

Вопрос всё же не в том, много или мало эти 0.4 секунды. Бывают случаи, когда и 10ms очень много.
Вопрос в том, можно ли ускорить определение факта наличия/отсутствия блокировки на определенных таблицах.
Использовать applock, даже если это и быстрее, я не могу.
23 окт 14, 15:26    [16749184]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
Glory
Member

Откуда:
Сообщений: 104760
Bone serpent
Для получения <10 записей из довольно таки небольшой таблицы syslockinfo - по моему таки много.

Вы считаете, что в исходных данных меньше 10 записей ?

Bone serpent
Вопрос в том, можно ли ускорить определение факта наличия/отсутствия блокировки на определенных таблицах.

Ускорить выброку из системного представления ?
Которое не является даже физической таблицей ?
23 окт 14, 15:30    [16749220]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
Bone serpent
Member

Откуда:
Сообщений: 168
Glory
Вы считаете, что в исходных данных меньше 10 записей ?

SELECT count(rsc_objid) FROM master.dbo.syslockinfo
даёт менее трёхсот на боевом сервере. На сервере с 1Снами базами много и быть не может. Она, зараза, однопоточно с базой работает.
Glory
Ускорить выброку из системного представления ?
Которое не является даже физической таблицей ?

Надеюсь, что быстрый метод таки есть. Может не выборка, а что-то иное. Иначе, спрашивается, как сервер работает? Он же при любой операции должен проверять блокировки. Не с такими тормозами он же это делает.
23 окт 14, 15:44    [16749346]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
Glory
Member

Откуда:
Сообщений: 104760
Bone serpent
Может не выборка, а что-то иное.

секретный код ?

Bone serpent
Иначе, спрашивается, как сервер работает? Он же при любой операции должен проверять блокировки. Не с такими тормозами он же это делает.

Вы думете, что движок пишет сам себе ваш запрос ? И сам от себя ждет ответа ?
23 окт 14, 15:49    [16749392]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
Bone serpent
Member

Откуда:
Сообщений: 168
Glory
Вы думете, что движок пишет сам себе ваш запрос ? И сам от себя ждет ответа ?

Я, конечно, ценю вашу активность в моей ветке, но вы занимаетесь болтологией. Давно бы сказали "да, можно вот так-то" или "нет, нельзя" и шли по своим делам.
Как я понимаю, ваше мнение "нет". Спасибо за участие.
23 окт 14, 16:14    [16749573]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
Glory
Member

Откуда:
Сообщений: 104760
Bone serpent
но вы занимаетесь болтологией.

Ну так поддерживаю ваш стиль. Чтобы, так сказать, быть на уровне
23 окт 14, 16:16    [16749593]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
Владислав Колосов
Member

Откуда:
Сообщений: 7868
Glory, кто знает, может у автора кибермозг и время его реакции на события 10E-6 сек.
Т.е. пол-секунды для него - бесконечно медленно.
23 окт 14, 17:01    [16749927]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
invm
Member

Откуда: Москва
Сообщений: 9405
Bone serpent
Надеюсь, что быстрый метод таки есть. Может не выборка, а что-то иное.
set lock_timeout 0;

declare @some_variable...;

begin try
 select top (0) @some_variable = some_field from some_table with (tablockx);
end try
begin catch
 ...
end catch;
23 окт 14, 17:42    [16750229]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
МуМу
Member

Откуда:
Сообщений: 1134
(0)Не хотелось бы учить но именно этот подход в корне не верен. Кроме тех случаев если вы не создаете средства мониторинга.
23 окт 14, 18:30    [16750471]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
Bone serpent
Member

Откуда:
Сообщений: 168
Glory, кто знает, может у автора кибермозг и время его реакции на события 10E-6 сек.
Т.е. пол-секунды для него - бесконечно медленно.

Из миллисекунд складываются вполне конкретные секунды.
set lock_timeout 0;

Спасибо за идею, нужно проверить
Не хотелось бы учить но именно этот подход в корне не верен. Кроме тех случаев если вы не создаете средства мониторинга.

Может быть подскажите другой подход. Хотя, с учетом того, что я пытаюсь родить что-то в стиле "гибких блокировок" софтпоинта, вас спрашивать даже как-то страшно :)
У меня 1С7.7. Отраслевое решение собственного производства. Что-то напоминающее сильно мутировавшую комплексную. Пытаюсь избавиться от нескольких вещей:
1. Блокировка справочников. У меня жесткий партионный учет. Партий много и двигаются почти любым документом. Плюс распределенная база. Значит когда с обменом приходит куча изменений в справочнике партий, возникает почти непрерывная блокировка справочника и проблемы с проведением документов. Вроде как хорошо и без последствий решилось убиранием TABLOCK со справочников. Зачем 1С сделала TABLOCK на справочники я никак понять не могу. Может вы со своим опытом "отрывания" от 1С блокировок это понимаете.
2. Достаточно длинная транзакция при проведении документов, начинающаяся с блокирования общего журнала. Что не даёт непроведенный документ просто записать. Тут я пытаюсь сделать смешанный вариант, оставляя TABLOCK только на таблицах с регистрами и бухгалтерскими итогами и блокируя их самостоятельно непосредственно перед расчетом итогов по регистрам. Остальное, вроде как, успешно работает с ROWLOCK, хотя на гарантированное отсутствие проблем замахиваться не буду. Пока мониторю, как оно получается.
3. Когда 1С хочет штатным способом монопольно заблокировать таблицу (например, регистр), она вызывает хранимую процедуру с текстом типа "select @i=1 from RA639 WITH (TABLOCK, HOLDLOCK) where 0=1". Если таблица уже заблокирована, 1С "замораживается", не реагирует на действия пользователя и даже не перерисовывает своё окошко. Полная иллюзия зависания. При этом еще любит со 100% загрузкой ядра ждать ответа SQL. Вот ради избавления от этого я пытаюсь проверить наличие блокировок, что бы ждать в цикле с паузой, без тупой загрузки процессора.
23 окт 14, 20:42    [16750927]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
Bone serpent
Member

Откуда:
Сообщений: 168
МуМу, У меня не те объёмы и обороты данных, что бы покупать услуги/решение софтпоинт. Ну и кризис, однако :) Удовлетворюсь убиранием проблемы "не могу записать номенклатуру, потому что кто-то проводит документ" и отсутствием "зависания" 1С при ожидании блокировки базы данных.
23 окт 14, 20:48    [16750949]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
Павел-П
Member

Откуда:
Сообщений: 234
Может быть blocked process report вам чем нибудь поможет. Есть такая штука и в profiler-е (SQL trace) также.
http://msdn.microsoft.com/en-us/library/ms191168(v=sql.110).aspx
23 окт 14, 21:45    [16751138]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
Mind
Member

Откуда: Лучший город на Земле
Сообщений: 2322
Bone serpent
Использую в базе 1С7.7 нестандартные блокировки и определение, заблокированы ли нужные таблицы, или нет.
Решение, мягко говоря, фиговое.
Вызывать системную функцию, которая просканирует всю память выделенную под блокировки, потом чего-то отфильтрует, только для того чтобы определить заблокирована одна таблица или нет? При этом не накладывая своей блокировки в процессе. Т.е. за 396мс, таблица может уже заблокироваться кем то.
Вот кстати соседний топик, там было сделано такое же гениальное решение. Разница выполнения запроса в различных средах

Если уж очень хочется придумывать свои блокировки, то делайте это хотя бы через sp_getapplock
24 окт 14, 20:00    [16756085]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
Bone serpent
Member

Откуда:
Сообщений: 168
Mind
Bone serpent
Использую в базе 1С7.7 нестандартные блокировки и определение, заблокированы ли нужные таблицы, или нет.
Решение, мягко говоря, фиговое.

Возможно, возможно. Хорошим бы решением было делать свою "прокладку" между 1С и SQL-сервером, как сделал SoftPoint http://www.softpoint.ru/products_id2.htm , но такое не потяну.

Но основной вопрос не в этом. Почему SQL так долго выбирает копеечные данные?
SELECT count(rsc_objid) FROM master.dbo.syslockinfo даёт менее трёхсот на боевом сервере.
Можно ли ускорить этот процесс или каким-либо другим способом определить наличие блокировок на указанном списке таблиц.

Или немного другой вопрос: как мне наложить и тут же снять (если успешно наложилась) блокировку? Не будет ли это быстрее?

Mind
Вызывать системную функцию, которая просканирует всю память выделенную под блокировки, потом чего-то отфильтрует, только для того чтобы определить заблокирована одна таблица или нет? При этом не накладывая своей блокировки в процессе. Т.е. за 396мс, таблица может уже заблокироваться кем то.

Если за это время кто-то заблокирует, я просто получу неуправляемую паузу на этапе, когда буду блокировать.
Мои извращения истекают из того, что 1С7.7, пока ждёт ответа SQL-сервера, изображает из себя дохлого скунса - не реагирует на пользователя и не перерисовывает своего окна. Фактически выглядит 100% зависшим приложением. Если я скормлю серверу установки всех нужных блокировок в одном запросе, рискую получить такую "зависшую" 1С на несколько минут. Если пытаться устанавливать блокировки понемногу, то при тормознутости выполнения кода 1С я сильно рискую регулярно получать дедлоки, когда другой пользователь будет блокировать нужные себе ресурсы.

Mind
Если уж очень хочется придумывать свои блокировки, то делайте это хотя бы через sp_getapplock

Пока не придумал как. Дело в том, что с базой фактически работает два приложения: 1С:Предприятие, которое обеспечивает пользовательский интерфейс и бизнес-логику, и 1С:Конфигуратор, которое делает обмен в распределённой базе данных. И если с первым я могу сделать многое, в том числе перевести его на applock, то со вторым сделать ничего нельзя. Вдобавок 1С регулярно приводит хранимые процедуры в "заводское" состояние и делать решение, которое не работоспособно при дефолтных хранимках, я не могу (вдруг какое-нибудь задание в планировщике, которое переделывает нужным мне образом хранимки, не отработает).
26 окт 14, 11:00    [16760097]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
МуМу
Member

Откуда:
Сообщений: 1134
(Bone serpent )Да ради, бога. Я готов и бесплатно помочь, был бы толк.(к тому же гибкие блокировки это уже прошлое:))
Самый главный вопрос - а что вам даст информация о наличии блокировок? Вам же как конечная цель нужно максимально расспаралеллить процессы - отсюда вывод , сначала добейтесь того что бы в системе было меньше блокировок. Добавлением же подобных конструкций вы увеличиваете время транзакций и соответственно блокировок.
26 окт 14, 18:54    [16761132]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
МуМу
Member

Откуда:
Сообщений: 1134
А вот избавиться от 100% загрузки процессора в момент ожидание можно и попроще. Накладывайте перед транзакциями свою блокировку. Соответственно процессы будут ожидать друг друга на скульной блокировке и не будет доп. нагрузки на терминальный сервер.
26 окт 14, 18:56    [16761140]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
Bone serpent
Member

Откуда:
Сообщений: 168
(кажется ветку пора переносить в 1С, она далеко от первоначального вопроса ушла)
МуМу,
Я готов и бесплатно помочь, был бы толк

От помощи бы не отказался, но, к сожалению, не знаю, какого совета спросить. Пока только для оптимизации блокировок есть одна идея реализации и, вроде как, вполне успешно реализуется. Вопрос оптимизации алгоритмов/кодов/запросов и всего прочего, естественно, никуда не девается. Но одно место оптимизировать такими методами нельзя - штатный обмен распределенной базы. А вот тут у меня приличной гипотезы нет, почему этот обмен то более-менее быстро отрабатывает, а то сотню элементов справочников грузит минуту. За исключением блокировок. Поэтому и начал с убирания TABLOCK на справочники.
к тому же гибкие блокировки это уже прошлое:))

У кого прошлое, а у кого и двести гигов распределенной базы 7.7 в эксплуатации
Самый главный вопрос - а что вам даст информация о наличии блокировок?

Чисто пользовательскую фигню - отсутствия "зависания" 1С. Эта информация позволяет мне ждать возможности наложить блокировку не ставя в ступор 1С и пользователя.
Вам же как конечная цель нужно максимально расспаралеллить процессы - отсюда вывод , сначала добейтесь того что бы в системе было меньше блокировок. Добавлением же подобных конструкций вы увеличиваете время транзакций и соответственно блокировок.

Не совсем так. Время транзакции дейстительно увеличивается. Но время эксклюзивной блокировки базы я уменьшаю.
Основная проблема 7.7, это общай журнал. Когда, например, записывается непроведенный документ, общий журнал блокируется и другой документ записываться не может. Хотя мог бы. В общем журнале у него своя запись, в таблицах шапок и табличных частей документов у каждого документа свои записи. С проведенными документами хуже. Они должны читать и записывать итоги по регистрам. Если движения регистров еще можно писать без блокирования таблицы, у каждого документа свои записи в таблице движений, то к итогам штатный механизм расчета итогов без TABLOCK допускать нельзя. То же касается и разновсяческих бухгалтерских итогов и отборов. Поэтому я отменяю TABLOCK на таблицах общего журнала, шапок и табличных частях документов, а на регистрах и бухгалтерских таблицах оставляю TABLOCK. Получается, что блокировка таблиц накладывается при проведении документов непосредственно перед тем, как регистры начнут читаться или записываться. А вот подготовительные действия, выполняемые при проведении, делаются без блокировки базы. Теоретически, если бы не бухгалтерские итоги, документы, отражающиеся по разным регистрам, могли бы проводиться параллельно.
Главная проблема всё же в обмене посредством Конфигуратора. При его работе возникает много блокировок, на которые я никак не могу повлиять. Не только документов, но и справочников. Притом раз в месяц, когда филиалы закрывают месяц, длительность отдельных сеансов обмена может длиться и более получаса. Это получается полчаса фактически монопольной блокировки базы. Один только ROWLOCK на справочники заметно снял остроту проблемы.
А вот избавиться от 100% загрузки процессора в момент ожидание можно и попроще. Накладывайте перед транзакциями свою блокировку. Соответственно процессы будут ожидать друг друга на скульной блокировке и не будет доп. нагрузки на терминальный сервер.

А как наложить эту свою блокировку? Воспользоваться applock я не могу, в работу обмена Конфигуратора не вмешаешься. Вызывать что-то типа "select @i=1 from RA639 WITH (TABLOCK, HOLDLOCK) where 0=1" значит опять получить "зависшую" 1С, когда она будет ждать ответа от SQL.
Может быть сделать "set lock_timeout 0;" и накладывать блокировки по одной в цикле, каждый раз дёргая SQL из 1С? Боюсь, с учетом тормознутости языка 1С, блокировка на пять-десять таблиц будет накладываться слишком неспешно и будут регулярно возникать дедлоки. По крайней мере, у меня в голове пока не сложилась идея, как тут построить нормальное решение. Возможно просто туплю.
26 окт 14, 19:58    [16761354]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
invm
Member

Откуда: Москва
Сообщений: 9405
Bone serpent
Может быть сделать "set lock_timeout 0;" и накладывать блокировки по одной в цикле, каждый раз дёргая SQL из 1С? Боюсь, с учетом тормознутости языка 1С, блокировка на пять-десять таблиц будет накладываться слишком неспешно и будут регулярно возникать дедлоки. По крайней мере, у меня в голове пока не сложилась идея, как тут построить нормальное решение. Возможно просто туплю.
set lock_timeout 0;

declare @c int;

begin try
 select top (0)
  @c = count(*)
 from
  table1 with (tablockx),
  table2 with (tablockx),
  table3 with (tablockx),
  ...
  tableN with (tablockx);
end try
begin catch
 ...
end catch;

set lock_timeout -1;
26 окт 14, 20:16    [16761393]     Ответить | Цитировать Сообщить модератору
 Re: Ускорить определение наличия блокировок на таблицах  [new]
Bone serpent
Member

Откуда:
Сообщений: 168
invm, А эта операция атомарна? Не может получиться, если table2 заблокировано другм клиентом, что на table1 поставится tablock и останется до конца транзакции? Или, может быть, подскажешь, как снять блокировку с таблицы, не дожидаясь конца транзакции?
27 окт 14, 05:28    [16762040]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить