|
|
|
1cv77_27 SQL 2008 периодические реквизиты
|
|||
|---|---|---|---|
|
#18+
При переносе базы с 2000 SQL на 2008 SQL (Detach - Copy -Attach ) столкнулись с проблемой зависания при отмене проведения документа, в котором были записи периодических реквизитов, тормоз полный c блокировкой таблицы _1SConst помогает только убиение процесса. Индексы для таблицы _1SConst пересчитали, завис идет - на exec sp_executesql N'Delete from _1SCONST where DOCID=@P1',N'@P1 varchar(9)',' 1YWPP ' самое грустное что "висят" не все документы, а какая-то из частей старых (зависимость найти не можем) есть подозрение, что что-то с индексами, но как их "правильно" подправить не знаем :( Где копать? может кто сталкивался? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2010, 12:16 |
|
||
|
1cv77_27 SQL 2008 периодические реквизиты
|
|||
|---|---|---|---|
|
#18+
По идее нужно было сделать бекап в 2000, а в 2008 грузить из бекапа. Ну и понятно что реиндексация перед бекапом будет далеко не лишней. Ну а так у вас кривые индексы в базе и если честно то ХЗ поможет переиндексация или нет. Одним местом чую что непоможет, но с 1С всегда возможны варианты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2010, 13:23 |
|
||
|
1cv77_27 SQL 2008 периодические реквизиты
|
|||
|---|---|---|---|
|
#18+
08+77 эспериментаторы однака ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.04.2010, 14:45 |
|
||
|
1cv77_27 SQL 2008 периодические реквизиты
|
|||
|---|---|---|---|
|
#18+
Вообще, первое, что нужно сделать на сервере БД при переходе с 2000 на 2008, это обновить статистики. В контексте своей базы в менеджмент студии попробуйте Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2010, 07:30 |
|
||
|
1cv77_27 SQL 2008 периодические реквизиты
|
|||
|---|---|---|---|
|
#18+
Может к радости может к сожалению, но периодически реквизиты тут оказались ни причем! Как раз с ними все Ок, в профайлере это была последняя отработанная строка, следующая должна была быть выборка из регистра (в моем случае взаиморасчеты), после долгих размышлений в поиске причины и различных экспериментов (на базе в 20 гБ они длятся около 6 часов) проблема была локализована. Сейчас ее окончательно проверяем, пока предварительно - вина в периоде сохранения остатков у нас она стоит 5 дней, после перевода на месяц - все Ок, документы прошлых периодов стали проводиться. Сейчас поставили пересчет снова на 5 дней - хотим убедиться в этом ли дело или все-таки что-то было с индексами внутри регистра, которые ушли после пересчета. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2010, 11:22 |
|
||
|
1cv77_27 SQL 2008 периодические реквизиты
|
|||
|---|---|---|---|
|
#18+
davikМожет к радости может к сожалению, но периодически реквизиты тут оказались ни причем! Как раз с ними все Ок, в профайлере это была последняя отработанная строка, следующая должна была быть выборка из регистра (в моем случае взаиморасчеты), после долгих размышлений в поиске причины и различных экспериментов (на базе в 20 гБ они длятся около 6 часов) проблема была локализована. Сейчас ее окончательно проверяем, пока предварительно - вина в периоде сохранения остатков у нас она стоит 5 дней, после перевода на месяц - все Ок, документы прошлых периодов стали проводиться. Сейчас поставили пересчет снова на 5 дней - хотим убедиться в этом ли дело или все-таки что-то было с индексами внутри регистра, которые ушли после пересчета. Статистику все таки обнови как tpg посоветовал, после детач\атач на новую версию сервера - делать надо первым делом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2010, 13:12 |
|
||
|
1cv77_27 SQL 2008 периодические реквизиты
|
|||
|---|---|---|---|
|
#18+
Да не братцы статистика тут ни причем! Теперь с полной уверенностью могу сказать, что проблема с неверной работой 2008 SQL с периодом итогов по регистру. В моем варианте стояло 5 дней, старые документы не подлежали снятию с проведения, происходил полный завис при попытке удаления записей из такого регистра. В виде эксперимента был изменен период итогов на "Месяц", конкретный документ снялся с проведения, потом снова вернули период итогов на 5 дней, тот же документ - полный завис :( Я конечно только могу предполагать но похоже что-то изменилось и 1С в связке с SQl2008 не может правильно определить дату периода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2010, 18:44 |
|
||
|
1cv77_27 SQL 2008 периодические реквизиты
|
|||
|---|---|---|---|
|
#18+
davikДа не братцы статистика тут ни причем! Теперь с полной уверенностью могу сказать, что проблема с неверной работой 2008 SQL с периодом итогов по регистру. В моем варианте стояло 5 дней, старые документы не подлежали снятию с проведения, происходил полный завис при попытке удаления записей из такого регистра. В виде эксперимента был изменен период итогов на "Месяц", конкретный документ снялся с проведения, потом снова вернули период итогов на 5 дней, тот же документ - полный завис :( Я конечно только могу предполагать но похоже что-то изменилось и 1С в связке с SQl2008 не может правильно определить дату периода. Так ты статистику обновлял или нет? Если не обновлял, обнови сначала, а потом уже иследуй. У тебя ж планы запросов не оптимально строятся, при не обновленной статистике. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.04.2010, 21:17 |
|
||
|
1cv77_27 SQL 2008 периодические реквизиты
|
|||
|---|---|---|---|
|
#18+
Обновил статистику - без толку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2010, 00:17 |
|
||
|
1cv77_27 SQL 2008 периодические реквизиты
|
|||
|---|---|---|---|
|
#18+
davikОбновил статистику - без толку. Тогда посоветую сходить на 1CSQL.ru и задать этот вопрос там, в частности там для этого есть две ветки в категории "Разработка в 1С SQL", там тебе помогут с большей вероятностью чем здесь. Я в свое время на 2005 семерочную базу переводить не рискнул, хотя практически все было на прямых запросах. По этому можно сказать, что не в теме. При переводе восьмерочных, и не 1С ных баз на 2005 сервер, базы начинали оптимально работать только после обновления статистики (с семерочными базами должно быть тоже самое), поэтому такие советы и даю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2010, 10:40 |
|
||
|
1cv77_27 SQL 2008 периодические реквизиты
|
|||
|---|---|---|---|
|
#18+
Есть подозрение что вся беда вот тут: exec _1sp_RA267_ClearRecalcDocActs ' 2080A ','2010-04-12 00:00:00','2010-04-11 00:00:00',1,0,1 это банальный регистр взаиморасчетов вот хранимая процедура, что может быть в ней не так, не знаю SET ANSI_NULLS ON GO SET QUOTED_IDENTIFIER ON GO ALTER procedure [dbo].[_1sp_RA267_ClearRecalcDocActs](@IdDoc CHAR(9), @DocDate DATETIME, @CurPeriod DATETIME, @RepeatToTM INTEGER, @SaveTurnsWithMonth INTEGER, @Direct INTEGER) AS SET NOCOUNT ON DECLARE @PeriodTA datetime, @Period datetime, @SnapShotPeriod char, @DebetCredit BIT DECLARE @p0 CHAR(9), @p1 CHAR(9), @f0 NUMERIC(18, 2), @f1 NUMERIC(18, 5) SELECT @PeriodTA=CURDATE, @SnapShotPeriod=SNAPSHPER FROM _1SSYSTEM DECLARE Cur_RA267 CURSOR FOR SELECT DEBKRED, SP1472, SP268, SP270, SP271 FROM RA267 WHERE IDDOC=@IdDoc OPEN Cur_RA267 FETCH NEXT FROM Cur_RA267 INTO @DebetCredit, @p0, @p1, @f0, @f1 WHILE @@FETCH_STATUS=0 BEGIN IF @DebetCredit<>@Direct SELECT @f0=-@f0, @f1=-@f1 IF @RepeatToTM=1 BEGIN SELECT @Period=@CurPeriod WHILE @Period<=@PeriodTA BEGIN EXECUTE _1sp_RG267_Change @Period, @p0, @p1, @f0, @f1 EXECUTE _1sp_GetNextPeriod @Period, @SnapShotPeriod, @Period OUTPUT END END ELSE EXECUTE _1sp_RG267_Change @CurPeriod, @p0, @p1, @f0, @f1 IF @SaveTurnsWithMonth=1 BEGIN EXECUTE _1sp_GetBeginOfPeriod @DocDate, 'M', @Period OUTPUT EXECUTE _1sp_RG267_Change @Period, @p0, @p1, @f0, @f1 END FETCH NEXT FROM Cur_RA267 INTO @DebetCredit, @p0, @p1, @f0, @f1 END CLOSE Cur_RA267 DEALLOCATE Cur_RA267 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.04.2010, 19:27 |
|
||
|
|

start [/forum/topic.php?fid=28&msg=36578254&tid=1522454]: |
0ms |
get settings: |
7ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
171ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
| others: | 204ms |
| total: | 477ms |

| 0 / 0 |
