Как понять, чем занят скуль? #315510

Начал обрезать базу скриптами, трассировщика сразу не запустил... Теперь все процы загружены на 100 процентов, реакции в трассировщике никакой, занимаемая память процессом растет, но очень медленно... В данный момент режется журнал документов, предполагаю там порядка 2 миллионов записей... Однако процесс идет уже 20 часов... Есть ли еще какие способы заглянуть в процессы скуля помимо трассера?

еще один...

и чё? по теме есть что сказать?

пользую щас 1с++... и как на грех, монопольно в базу зашел :(

Так трассировщика никогда не поздно запустить

дык, пока скуль инструкцию не выполнит - в трассировщике никаких сведений...

год назад резал, база была 26 гиг, щас 53... видно мало взял два дня...

sp_lock ??

Скрипт покажи...

попробую... это первый, пометка на удаление в журнале... UPDATE _1sjourn SET IsMark = 1, Closed = 6 WHERE IDDOC NOT IN (    SELECT IDDOC FROM $Регистр.ОстаткиТоваров WHERE Date_Time_IDDOC > :ДатаОбрезания~      UNION    SELECT RIGHT($RR.ПоСчету, 9) FROM $РегистрИтоги.РезервыТоваров AS RR WHERE RR.Period > CAST(:ДатаОбрезания AS DATETIME)        UNION    SELECT IDDOC FROM $Регистр.РезервыТоваров WHERE Date_Time_IDDOC > :ДатаОбрезания~    UNION    SELECT RIGHT($RP.ПрихДокумент, 9) from $РегистрИтоги.ПартииТоваров AS RP WHERE RP.Period > CAST(:ДатаОбрезания AS DATETIME)        UNION        SELECT IDDOC FROM $Регистр.ПартииТоваров WHERE Date_Time_IDDOC > :ДатаОбрезания~        UNION        SELECT RIGHT($RW.КредДокумент, 9) from $РегистрИтоги.ВзаиморасчетыПокупателей AS RW WHERE RW.Period > CAST(:ДатаОбрезания AS DATETIME)        UNION        SELECT IDDOC FROM $Регистр.ВзаиморасчетыПокупателей WHERE Date_Time_IDDOC > :ДатаОбрезания~        UNION    SELECT RIGHT($RW1.КредДокумент, 9) from $РегистрИтоги.ВзаиморасчетыПоставщиков AS RW1 WHERE RW1.Period > CAST(:ДатаОбрезания AS DATETIME)        UNION       SELECT IDDOC FROM $Регистр.ВзаиморасчетыПоставщиков WHERE Date_Time_IDDOC > :ДатаОбрезания~       UNION    SELECT RIGHT($RN.ПрихДокумент, 9) from $РегистрИтоги.СобранныеНаборы AS RN WHERE RN.Period > CAST(:ДатаОбрезания AS DATETIME)       UNION       SELECT IDDOC FROM $Регистр.СобранныеНаборы WHERE Date_Time_IDDOC > :ДатаОбрезания~       UNION    SELECT RIGHT($RT1.Запрос, 9) from $РегистрИтоги.Транзиты AS RT1 WHERE RT1.Period > CAST(:ДатаОбрезания AS DATETIME)       UNION       SELECT IDDOC FROM $Регистр.Транзиты WHERE Date_Time_IDDOC > :ДатаОбрезания~       UNION    SELECT RIGHT($RT.Заказ, 9) from $РегистрИтоги.ТоварыКПеремещению AS RT WHERE RT.Period > CAST(:ДатаОбрезания AS DATETIME)       UNION       SELECT IDDOC FROM $Регистр.ТоварыКПеремещению WHERE Date_Time_IDDOC > :ДатаОбрезания~   ) AND Date_Time_IDDOC <= :ДатаОбрезания~

помогла процедура sp_who, по крайней мере видно, что выполняется апдэйт...

DBCC INPUTBUFFER(spid)

как только начнешь произносить SQL правильно, так и получишь правильный ответ.

понадеялся на 1с++... приведенный мною скрипт не срабатывал, вешал на 100% сервак... сейчас перенес текст скрипта на чистый скуль - время отработки 12 минут, обработано 1300000 записей...

вы все в какой хабзайке учились? сходите что-ли на курсы 1С. только пэтэушники SQL обзывают "скуль" (чуть не проблювалдся, пока писал).

по что за зря на 1С++ поклеп наводишь?

Сказал А говори и Б давай текст SQL чистого посмотрим чем отличается от написанного на 1С++ а вообще-то я еще что хотел сказать.. 1) Данный скрипт просто ставит пометку в журнале документов; 2) А кто будет очищать ДВИЖЕНИЯ этих документов в регистрах и бухгалтерских итогах? 3) какой смысл в условии NOT IN - у тебя же стоит условие "Date_Time_IDDOC <= :ДатаОбрезания~" для журнала документов, то есть документы, у которых "Date_Time_IDDOC > :ДатаОбрезания~" и так не попадут в эту выборку. ИМХО лишний фильтр.

от перестановки слагаемых сумма не изменяется... хз, сам не думал - однако столкнулся... причем на тестовой базе все прошло на ура... "чистый" текст update _1sjourn set ismark = 1, closed = 6 where iddoc not in ( select right(sp622, 9) from rg620 where period >= cast('20071001' as datetime) union select iddoc from ra620 where left(date_time_iddoc, 8) >= '20071001' union select iddoc from ra99 where left(date_time_iddoc, 8) >= '20071001' union select right(sp1132, 9) from rg1130 where period >= cast('20071001' as datetime) union select iddoc from ra1130 where left(date_time_iddoc, 8) >= '20071001' union select right(sp405, 9) from rg169 where period >= cast('20071001' as datetime) union select iddoc from ra169 where left(date_time_iddoc, 8) >= '20071001' union select right(sp935, 9) from rg933 where period >= cast('20071001' as datetime) union select iddoc from ra933 where left(date_time_iddoc, 8) >= '20071001' union select right(sp3674, 9) from rg3604 where period >= cast('20071001' as datetime) union select iddoc from ra3604 where left(date_time_iddoc, 8) >= '20071001' union select right(sp5301, 9) from rg5298 where period >= cast('20071001' as datetime) union select iddoc from ra5298 where left(date_time_iddoc, 8) >= '20071001' ) 17.1 именно 17.2 второй скрипт чистит регистры + бух таблицы, третий скрипт чистит таблицы документов, ссылок и журнал 17.3 обрати внимание, что вложенный селект выбирает все ИД документов, на которые есть ссылки в остатках или движениях после даты обрезания, нах удалять эти документы? дабы потом иметь либо битую либо пустую ссылку?

(13, 15) не парь мозг: есть что сказать по делу - говори, нет - номер 2

текущий прогресс: без удаленных ссылок документов, журнала, периодики, без реиндексации база с 56 гиг уменьшилась до 14,5...

неправильно посылать его читать правила. Правильно послать его в шопу.

Меня, к примеру, тошнит, когда я вижу слово "Бармолей"... Даже пэтэушники знают как оно правильно пишется...

я как Бендер - чту правила, в шопу - это против правила №1 :))

"Бармолей" пишется через "о". "Бармолей" пишется через "а"! умник мля!

копипаст блин. праваильно так: "Бармолей" пишется через "о". "Бармалей" пишется через "а"! умник мля!

кстати, SnarkHunter правильно писать SnorkGunter

мальчик, не ругайся в Рождество, а то не вырастешь

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

а ты что думаешь по поводу высказывания Гюнтера?

чего?

ну

транзакции использовал?

приедется повторить восстановив базу из бэкапа )

какие? посмотрю пока, тестирование заняло порядка часа - еще будет время )

какие-нибудь

явно нет, скуль сам их оформляет