Вход на сайт
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 ты не слышал
------
А ты им управлять из СКЛ можешь? Нет?!! - тогда нахрен тебе об нем знать... вот про локи-дедлоки - надо, но это как раз нормально.
NEW 28.07.11 14:25
вижу
ну хозяин барин
такой подход к работе ?
те девелоперы которых знаю я таки смотрят в планы выполнения и wait events, там "либо выполнилось либо нет" не канает.
будет, надо только один раз вникнуть в то как работает тот или инной продукт. Иначе потом появляются вопросы как у ТС. Плюс обиды что советуют "не по теме".
По мнению не безизвестного тома кайта грош цена девелоперу для которого база blackbox.
wait event'ами нельзя управлять. wait events это индикатор того что происходит с запросом и с базой в целом. На них надо реагировать, а не управлять.
в ответ Murr 28.07.11 14:05
В ответ на:
А Я - неграмотный.
А Я - неграмотный.
вижу

В ответ на:
Где и как - совершенно не волнует.
Где и как - совершенно не волнует.
ну хозяин барин
В ответ на:
Волнует - транзакция либо выполнится, либо не выполнится. На этом - все.
Волнует - транзакция либо выполнится, либо не выполнится. На этом - все.
такой подход к работе ?

В ответ на:
Если начнет волновать куда и что пишет сиквел - не будет времени делать задачу.
Если начнет волновать куда и что пишет сиквел - не будет времени делать задачу.
будет, надо только один раз вникнуть в то как работает тот или инной продукт. Иначе потом появляются вопросы как у ТС. Плюс обиды что советуют "не по теме".
По мнению не безизвестного тома кайта грош цена девелоперу для которого база blackbox.
В ответ на:
А ты им управлять из СКЛ можешь? Нет?!!
А ты им управлять из СКЛ можешь? Нет?!!
wait event'ами нельзя управлять. wait events это индикатор того что происходит с запросом и с базой в целом. На них надо реагировать, а не управлять.
0001, 0010, 0011, 0100, 0101, вышел зайчег погулядь
NEW 28.07.11 17:01
в ответ BSDLamer 28.07.11 14:25
девелоперы которых знаю я таки смотрят в
------
Днями шеф принес лог трассировки доступа к сайту... 170 однвременных аплоудов (не довнладов) - потолок.
Спашивает - Что можешь сделать? - отвечаю - Смотрел поверхностно, могу улучшить примерно в два раза.
Больше - не уверен, надо смотреть детали, но туда надо лезть после вот этого и вот этого. - гворит он мне
- Ладно, делай что считаешь нужным, потом еще раз потестим и подумаем.
За полдня Я поднял производительность примерно в 5 раз. Никаких планов запросов и тому подобной
чепухи - прямой анализ того, что лишнего делает система и урезание узких мест - там были ненужные
перезапросы. Производительность, на сегодня, устраивает. Можно повысить еще раза в три... для этого
надо всего лишь переработать... базовый код примерно 300 сайтов.
не канает.
------
Канает. Я бы просто выгнал прикладника, который полез бы базу, вместо грамотного использования
предоставленного интерфейса.
Но в тоже время - вигрыз бы мозги ДБА если бы интерфейс не покрывал требования задачи...
По мнению не безизвестного тома
------
...а кто такой этот Пикасо?
На них надо реагировать
------
Неа... У меня вот сейчас аналог этого эвента... с задержкой на 20-25 часов... Шеф, когда Я обяснил что
и зачем там делается, просто кипятком писает - полная асинхроника там, где до этого юзери по 10-15
минут ждали синхронного ответа системы... А работа - хоть по шедуллеру, хоть по идлу, хоть по внешнему
запросу... и пофиг на то, сколько там ждать - она отработает вовремя и гарантированно.
------
Днями шеф принес лог трассировки доступа к сайту... 170 однвременных аплоудов (не довнладов) - потолок.
Спашивает - Что можешь сделать? - отвечаю - Смотрел поверхностно, могу улучшить примерно в два раза.
Больше - не уверен, надо смотреть детали, но туда надо лезть после вот этого и вот этого. - гворит он мне
- Ладно, делай что считаешь нужным, потом еще раз потестим и подумаем.
За полдня Я поднял производительность примерно в 5 раз. Никаких планов запросов и тому подобной
чепухи - прямой анализ того, что лишнего делает система и урезание узких мест - там были ненужные
перезапросы. Производительность, на сегодня, устраивает. Можно повысить еще раза в три... для этого
надо всего лишь переработать... базовый код примерно 300 сайтов.
не канает.
------
Канает. Я бы просто выгнал прикладника, который полез бы базу, вместо грамотного использования
предоставленного интерфейса.
Но в тоже время - вигрыз бы мозги ДБА если бы интерфейс не покрывал требования задачи...

По мнению не безизвестного тома
------
...а кто такой этот Пикасо?
На них надо реагировать
------
Неа... У меня вот сейчас аналог этого эвента... с задержкой на 20-25 часов... Шеф, когда Я обяснил что
и зачем там делается, просто кипятком писает - полная асинхроника там, где до этого юзери по 10-15
минут ждали синхронного ответа системы... А работа - хоть по шедуллеру, хоть по идлу, хоть по внешнему
запросу... и пофиг на то, сколько там ждать - она отработает вовремя и гарантированно.
NEW 28.07.11 17:16
смотреть статистику которую тебе дает база и есть грамотное ее использование девелопером.
пожалуй самый знаменитый эксперт по базам (в особенности оракловым)
дальше можешь не рассказывать, все ясно короче :)
в ответ Murr 28.07.11 17:01
В ответ на:
Я бы просто выгнал прикладника, который полез бы базу, вместо грамотного использования
предоставленного интерфейса.
Я бы просто выгнал прикладника, который полез бы базу, вместо грамотного использования
предоставленного интерфейса.
смотреть статистику которую тебе дает база и есть грамотное ее использование девелопером.
В ответ на:
...а кто такой этот Пикасо?
...а кто такой этот Пикасо?
пожалуй самый знаменитый эксперт по базам (в особенности оракловым)
В ответ на:
Никаких планов запросов и тому подобной
чепухи
Никаких планов запросов и тому подобной
чепухи
дальше можешь не рассказывать, все ясно короче :)
0001, 0010, 0011, 0100, 0101, вышел зайчег погулядь
NEW 28.07.11 18:01
в ответ BSDLamer 28.07.11 17:16
смотреть статистику
------
Для ДБА. Прикладнику там делать нефиг...
самый знаменитый
------
А... ну бог с ним... Помнится, надо было что-то починить... мелочевка какая-то... ну да только разработчики смогли разобраться что да как...
Про экспертов - это отдельная пеСТня... Скоро оно будет классифицироваться как ругательство... по крайней мере в известной с(т)ране...
все ясно
-----
Так оно и до начала было ясно...
------
Для ДБА. Прикладнику там делать нефиг...
самый знаменитый
------
А... ну бог с ним... Помнится, надо было что-то починить... мелочевка какая-то... ну да только разработчики смогли разобраться что да как...
Про экспертов - это отдельная пеСТня... Скоро оно будет классифицироваться как ругательство... по крайней мере в известной с(т)ране...
все ясно
-----
Так оно и до начала было ясно...

NEW 31.07.11 19:12
в ответ rimqpp0 27.07.11 11:40
Такое поведение говорит о том, что база битая.
Иногда помогает прибить индекс и заново его создать.
По правильному в зависимости от нагрузки должны отрабатывать Maintenance Plans. Например ночью часа в 3.
Если Maintenance проваливается дальше Repair без разрешения исправлений и потом по результатам с разрешением.
Естественно не забывать про бакап, который должен быть по расписанию. Обрезание также по расписанию.
Иногда помогает прибить индекс и заново его создать.
По правильному в зависимости от нагрузки должны отрабатывать Maintenance Plans. Например ночью часа в 3.
Если Maintenance проваливается дальше Repair без разрешения исправлений и потом по результатам с разрешением.
Естественно не забывать про бакап, который должен быть по расписанию. Обрезание также по расписанию.
NEW 03.08.11 15:29
в ответ Nucleas 31.07.11 19:12
меня на sql.ru облили с ног до головы за то что я обрезаю log а потом делаю shrinkdatabase.
посмотрел в нете, помоему закономерная последовательность. но похоже все равно что то не так.
могут быть какие то проблемы если так сделать?
backup log @db_name with no_log
dbcc shrinkfile (2,0)
backup режется в процедуре до и после выполнения update's ночью.. днем работает приложение, вечером в 10 backup. в 3 ночи updates.
так работает все несколько лет. в одной из баз наблюдаю выше описанное. таблицы создаются тоже в процедуре, потом к ним добавляются индексы, все отрабытывается, таблицы удаляются.
саму процедуру разбил на шаги.. по 200-300 datensätze..всего околко 10 тыс.
раз процедура отрабытывает за 2 часа, второй раз виснет в одном из запросов (место не фиксировано). меняю шаг, опять все отрабытывется.. не пойму че за хрень..
посмотрел в нете, помоему закономерная последовательность. но похоже все равно что то не так.
могут быть какие то проблемы если так сделать?
backup log @db_name with no_log
dbcc shrinkfile (2,0)
backup режется в процедуре до и после выполнения update's ночью.. днем работает приложение, вечером в 10 backup. в 3 ночи updates.
так работает все несколько лет. в одной из баз наблюдаю выше описанное. таблицы создаются тоже в процедуре, потом к ним добавляются индексы, все отрабытывается, таблицы удаляются.
саму процедуру разбил на шаги.. по 200-300 datensätze..всего околко 10 тыс.
раз процедура отрабытывает за 2 часа, второй раз виснет в одном из запросов (место не фиксировано). меняю шаг, опять все отрабытывется.. не пойму че за хрень..
NEW 03.08.11 19:52
в ответ rimqpp0 03.08.11 15:29
Форум sql.ru на самом деле полезный.
Лог файл - это файл в котором выполняются транзакции, он и называется Transaction Log. Если к базе никто не обращается, то его можно сжать, если модель не FULL(не требуется хранить транзакции), а потом делать бакап(просто места меньше, если бакап не инкрементальный). Естественно он растет в момент выполнения процедуры, и если прервать транзакцию, то все должно вернуться назад. Естественно после выполнения процедуры его сжимать не надо.
DBCC CHECKDB - проверяет целостность базы если у Вас целостность в порядке, то дело в процедуре.
Может быть все, что угодно вплоть до распределенных транзакций (которые выплняются на двух или более серверах).
Да и выполнение процедуры 1 час -- не радует изначально. Для чистки лучше 60 раз по секунде(это не опечатка), кстати и лог расти не будет.
Лог файл - это файл в котором выполняются транзакции, он и называется Transaction Log. Если к базе никто не обращается, то его можно сжать, если модель не FULL(не требуется хранить транзакции), а потом делать бакап(просто места меньше, если бакап не инкрементальный). Естественно он растет в момент выполнения процедуры, и если прервать транзакцию, то все должно вернуться назад. Естественно после выполнения процедуры его сжимать не надо.
DBCC CHECKDB - проверяет целостность базы если у Вас целостность в порядке, то дело в процедуре.
Может быть все, что угодно вплоть до распределенных транзакций (которые выплняются на двух или более серверах).
Да и выполнение процедуры 1 час -- не радует изначально. Для чистки лучше 60 раз по секунде(это не опечатка), кстати и лог расти не будет.
NEW 03.08.11 20:39
ошибку дает
The In-row data USED page count for object "Liz_Avail_Lizenz_Mandant", index ID 2, partition ID 603070911152128, alloc unit ID 603070911152128 (type In-row data) is incorrect. Run DBCC UPDATEUSAGE.
после DBCC UPDATEUSAGE Job отработал без ошибок ночью. спасибо за инфо.
The In-row data USED page count for object "Liz_Avail_Lizenz_Mandant", index ID 2, partition ID 603070911152128, alloc unit ID 603070911152128 (type In-row data) is incorrect. Run DBCC UPDATEUSAGE.
после DBCC UPDATEUSAGE Job отработал без ошибок ночью. спасибо за инфо.