Вход на сайт
MS SQL Server : "Зависает Query после обрезания Log-файла"
27.07.11 11:40
Последний раз изменено 27.07.11 11:44 (rimqpp0)
Есть проблема с MSSQL : Есть процедура которая выполняется один раз за час, после чего обрезаю лог-файл. Потом запускаю ее еще раз и все крутится сутками и не завершается
Запрос идет бесконечно, похоже что запрос просто "висит" и ждет чтоб ему "дать пинка". В профайлере никакой реакции на прсходящее.
трудно описать словами, приведу некоторые куски кода.
есть таблица типа
CREATE TABLE [dbo].[_tmp2](
[ID] [int] IDENTITY(1,1) NOT NULL,
[Film_ID] [int] NULL,
[Liz_Gebiet_ID] [int] NULL,
[Liz_Art_ID] [int] NULL,
.........
) ON [PRIMARY]
В ней групповой Index na все ID's кроме IDENTITY
В самой процедуре есть с десяток запросов типа
DELETE FROM _tmp2 WHERE ID IN (
SELECT t.ID
FROM _tmp2 t
INNER JOIN _tmp2 t2 ON T2.VK = t.VK AND t2.Film_ID = t.Film_ID AND t2.Liz_Gebiet_ID = t.Liz_Gebiet_ID AND t2.Liz_Art_ID = t.Liz_Art_ID
Вручную запросы отрабативаются за несколъко минут
Как рисовал выше запускаю процедуру 1 раз, все отрабатывается корректно за час. обрезаю протокол, запускаю еще раз все "виснет". потом вдруг после очередного зауска начинает опять все отрабатыватся зяа час.
Что может так "виснуть" в MS SQL? Есть какие то установы на процедуру типа
CREATE PROCEDURE [dbo].[proc_Name] WITH EXECUTE AS SELF
которые "форсируют" запросы ? (приведенный не помогает)
Запрос идет бесконечно, похоже что запрос просто "висит" и ждет чтоб ему "дать пинка". В профайлере никакой реакции на прсходящее.
трудно описать словами, приведу некоторые куски кода.
есть таблица типа
CREATE TABLE [dbo].[_tmp2](
[ID] [int] IDENTITY(1,1) NOT NULL,
[Film_ID] [int] NULL,
[Liz_Gebiet_ID] [int] NULL,
[Liz_Art_ID] [int] NULL,
.........
) ON [PRIMARY]
В ней групповой Index na все ID's кроме IDENTITY
В самой процедуре есть с десяток запросов типа
DELETE FROM _tmp2 WHERE ID IN (
SELECT t.ID
FROM _tmp2 t
INNER JOIN _tmp2 t2 ON T2.VK = t.VK AND t2.Film_ID = t.Film_ID AND t2.Liz_Gebiet_ID = t.Liz_Gebiet_ID AND t2.Liz_Art_ID = t.Liz_Art_ID
Вручную запросы отрабативаются за несколъко минут
Как рисовал выше запускаю процедуру 1 раз, все отрабатывается корректно за час. обрезаю протокол, запускаю еще раз все "виснет". потом вдруг после очередного зауска начинает опять все отрабатыватся зяа час.
Что может так "виснуть" в MS SQL? Есть какие то установы на процедуру типа
CREATE PROCEDURE [dbo].[proc_Name] WITH EXECUTE AS SELF
которые "форсируют" запросы ? (приведенный не помогает)
NEW 27.07.11 14:50
в ответ rimqpp0 27.07.11 11:40
http://www.sql.ru/forum/actualthread.aspx?bid=1&tid=869126&pg=1 

0001, 0010, 0011, 0100, 0101, вышел зайчег погулядь
NEW 27.07.11 17:06
ну да как полагается именно пнуть .. но иногда удается докопатся до чего то полезного
если докопаюсь изложу истину
хотя вопросы иногда достают.. типа какая стратегия backup.. написал вроде .. не пойму чего хотят
если докопаюсь изложу истину
хотя вопросы иногда достают.. типа какая стратегия backup.. написал вроде .. не пойму чего хотят
NEW 27.07.11 17:31
я не спец в MS SQL (а точнее я его ни разу в жизни не видел), но сдается мне что ты делаешь чет фундаментально не правильно.
Спросили про стратегию бекапа потому что redo/undo для восстановления как сам понимаешь очень важны и может перед тем как давать тебе дальнейшие советы людям надо знать какая стратегия бекапа иначе в один прекрасный день можно и не восстановить базу.
Спросили про стратегию бекапа потому что redo/undo для восстановления как сам понимаешь очень важны и может перед тем как давать тебе дальнейшие советы людям надо знать какая стратегия бекапа иначе в один прекрасный день можно и не восстановить базу.
0001, 0010, 0011, 0100, 0101, вышел зайчег погулядь
NEW 27.07.11 18:13
в ответ BSDLamer 27.07.11 17:31
фундаментально не правильно.
-----
На то оно и сиквел - транзакция либо выполнится, либо откатися - никаких вариантов...
и не восстановить базу.
------
Только в одном случае - когда нет полного бекапа. Остальное - выше..
И ето не влияет на время выполнения процедур - тут только локи, инцременты и т.п... сиквел, в общем...
-----
На то оно и сиквел - транзакция либо выполнится, либо откатися - никаких вариантов...
и не восстановить базу.
------
Только в одном случае - когда нет полного бекапа. Остальное - выше..
И ето не влияет на время выполнения процедур - тут только локи, инцременты и т.п... сиквел, в общем...
NEW 27.07.11 18:20
в ответ BSDLamer 27.07.11 17:31
да чушь. там просто надо докопат'ся до пустого места. на 20 дурацких ответов может найдется что то правильное.. уже пару полезных строк я нашел.
народу вкайф посмаковать что я меняю тип базы с спростого на полный и обрезаю LOG промежутке.
я так уже пару лет делаю с новым 2008 и нет проблем.
ну нашим надо обхаять не имея представления о чем речь. ето нормально на русских порталах.
народу вкайф посмаковать что я меняю тип базы с спростого на полный и обрезаю LOG промежутке.
я так уже пару лет делаю с новым 2008 и нет проблем.
ну нашим надо обхаять не имея представления о чем речь. ето нормально на русских порталах.
NEW 27.07.11 18:43
в ответ Murr 27.07.11 18:13
то что это прямого отношения к проблеме не имеет понятно, читай выше.
данные пишутся в MS SQL сразу на диск ?
на полный бекап надо еще кой чего накатывать для того чтоб появились изменения случившиеся после полного бекапа.
садись, два :) время выполнения зависит от гораздо большего количества ожиданий
В ответ на:
На то оно и сиквел - транзакция либо выполнится, либо откатися - никаких вариантов...
На то оно и сиквел - транзакция либо выполнится, либо откатися - никаких вариантов...
данные пишутся в MS SQL сразу на диск ?
В ответ на:
Только в одном случае - когда нет полного бекапа. Остальное - выше..
Только в одном случае - когда нет полного бекапа. Остальное - выше..
на полный бекап надо еще кой чего накатывать для того чтоб появились изменения случившиеся после полного бекапа.
В ответ на:
И ето не влияет на время выполнения процедур - тут только локи, инцременты и т.п... сиквел, в общем...
И ето не влияет на время выполнения процедур - тут только локи, инцременты и т.п... сиквел, в общем...
садись, два :) время выполнения зависит от гораздо большего количества ожиданий
0001, 0010, 0011, 0100, 0101, вышел зайчег погулядь
NEW 27.07.11 18:48
я думаю что там почти всем пох какой у тебя тип базы. Просто иногда люди не понимающие что делают стреляют себе в ногу, но замечают это только тогда когда база рухнула и ее надо восстанавливать, а накатить изменения после полного бекапа уже неоткуда.
не буду утверждать, я даже в принципе не знаю как работает redo/undo в MS SQL.
в ответ rimqpp0 27.07.11 18:20
В ответ на:
народу вкайф посмаковать что я меняю тип базы с спростого на полный и обрезаю LOG промежутке.
народу вкайф посмаковать что я меняю тип базы с спростого на полный и обрезаю LOG промежутке.
я думаю что там почти всем пох какой у тебя тип базы. Просто иногда люди не понимающие что делают стреляют себе в ногу, но замечают это только тогда когда база рухнула и ее надо восстанавливать, а накатить изменения после полного бекапа уже неоткуда.
не буду утверждать, я даже в принципе не знаю как работает redo/undo в MS SQL.
0001, 0010, 0011, 0100, 0101, вышел зайчег погулядь
NEW 27.07.11 23:23
в ответ BSDLamer 27.07.11 18:43
данные пишутся в MS SQL сразу на диск ?
------
А кого оно волнует - незавершенка откатится при рестарте...
В остальном - сиквел - версионка - напишет сколько ему надо для комплишена.
надо еще кой чего
------
Да, надо. Правда Я имел в виду другое - базу из частичных бекапов не собрать...
время выполнения
------
Это функция числа систем в кластере.
------
А кого оно волнует - незавершенка откатится при рестарте...
В остальном - сиквел - версионка - напишет сколько ему надо для комплишена.
надо еще кой чего
------
Да, надо. Правда Я имел в виду другое - базу из частичных бекапов не собрать...
время выполнения
------
Это функция числа систем в кластере.
NEW 28.07.11 07:50
обычно это волнует грамотных девелоперов и dba. Информация о транзакциях была она закоммичена или нет тожет должна где-то держаться, и то что накатывать или откатывать тоже надо кудато класть.
ясно, о wait events ты не слышал :)
в ответ Murr 27.07.11 23:23
В ответ на:
А кого оно волнует - незавершенка откатится при рестарте...
В остальном - сиквел - версионка - напишет сколько ему надо для комплишена.
А кого оно волнует - незавершенка откатится при рестарте...
В остальном - сиквел - версионка - напишет сколько ему надо для комплишена.
обычно это волнует грамотных девелоперов и dba. Информация о транзакциях была она закоммичена или нет тожет должна где-то держаться, и то что накатывать или откатывать тоже надо кудато класть.
В ответ на:
Это функция числа систем в кластере.
Это функция числа систем в кластере.
ясно, о wait events ты не слышал :)
0001, 0010, 0011, 0100, 0101, вышел зайчег погулядь
NEW 28.07.11 14:05
в ответ BSDLamer 28.07.11 07:50
обычно это волнует грамотных девелоперов и dba.
------
А Я - неграмотный. У меня сперли удостоверение об владении языком известной с(т)раны и теперь - сАвсем неграмотный...
тожет должна где-то держаться
------
Где и как - совершенно не волнует. Волнует - транзакция либо выполнится, либо не выполнится. На этом - все.
Если начнет волновать куда и что пишет сиквел - не будет времени делать задачу. Собственно, его и родили
от необходимости изолировать эти детали от разработчика.
о wait events ты не слышал
------
А ты им управлять из СКЛ можешь? Нет?!! - тогда нахрен тебе об нем знать... вот про локи-дедлоки - надо, но это как раз нормально.
------
А Я - неграмотный. У меня сперли удостоверение об владении языком известной с(т)раны и теперь - сАвсем неграмотный...
тожет должна где-то держаться
------
Где и как - совершенно не волнует. Волнует - транзакция либо выполнится, либо не выполнится. На этом - все.
Если начнет волновать куда и что пишет сиквел - не будет времени делать задачу. Собственно, его и родили
от необходимости изолировать эти детали от разработчика.
о wait events ты не слышал
------
А ты им управлять из СКЛ можешь? Нет?!! - тогда нахрен тебе об нем знать... вот про локи-дедлоки - надо, но это как раз нормально.