SQL Server 2008 - хранимая процедура застревает при вызове из службы WPF с помощью SqlDataAdapter - PullRequest
Новая
       8

SQL Server 2008 - хранимая процедура застревает при вызове из службы WPF с помощью SqlDataAdapter

1 голос
/ 13 августа 2010

Это заставляет меня вырывать волосы. У нас есть рабочий процесс, размещенный как служба WCF, которая выполняет вызов другой службы WCF, которая затем вызывает хранимую процедуру. Процедура сохранения вызывает слияние, затем перебирает курсор, вызывающий другое sproc. Количество курсоров совпадает с количеством источников в слиянии. Если количество источников велико (~ 120k), sproc никогда не возвращается. Активность диска и загрузка процессора равны нулю, а память не облагается налогом. Если я затем вызываю sproc из SSMS, это завершается примерно через час.

Мы используем SQLDataAdapter для фактического вызова. Получает ли SDA какие-либо обновления на каждой итерации курсора, а затем дает сбой, вызывая остановку SQL во время ожидания? Или что-то еще происходит?

Я поднимаю SDA, потому что я провел первую часть недели, отслеживая причину сбоя рабочего процесса, и оказалось, что это было повторное предупреждающее сообщение ANSI, которое возвращалось в SDA и вызывало исключение нехватки памяти. Что заставляет меня задуматься, не происходит ли здесь что-то еще, что вызывает проблему.

Ответы [ 3 ]

1 голос
/ 13 августа 2010

Я серьезно сомневаюсь, что хост WCF является подходящей средой для удержания вызова базы данных в течение одного часа ... Я рекомендую вам взглянуть на Асинхронное выполнение процедуры , которая позволяет выполнять длинные вызовы базыи ASP / WCF обрабатывают надежным способом, и вызов позволяет HTTP-вызову вернуться обратно к вызывающей стороне.

0 голосов
/ 18 августа 2010

Оказывается, это был очень плохой случай перехвата параметров. Очень, очень плохой случай ...

0 голосов
/ 13 августа 2010

Трудно сказать, что на самом деле делает ваш код, но вы упоминаете, что ваш хранимый процесс использует курсоры и что ваш хранимый процесс работает медленно. Я пишу свои хранимые процедуры для использования временных таблиц и перебираю временные таблицы, как показано в следующем примере. Это заставляло мои проки запускаться от нескольких секунд до нескольких минут, когда они использовались от нескольких минут до нескольких часов, когда я использовал курсоры. Если вы используете курсоры, а профилирование указывает, что код курсора в вашем хранимом процессе медленный, попробуйте временные таблицы.

Вы никогда не вернетесь к курсорам. 

-- create a temporary table
DECLARE @FrontDeskRows table (
    id int,
    Arrival datetime,
    Departure datetime,
    CheckedIn int,
    OwnerID varchar(50),
    GuestID varchar(50),
    [LName] varchar (256),
    [FName] varchar (256),
    [Address] varchar (256),
    [City] varchar (256),
    [State] varchar (256),
    [Zip] varchar (256),
    [phone] varchar (256),
    [Status] int )

-- load your temporary table
INSERT INTO @FrontDeskRows
  SELECT  id,
      Arrival,
      Departure,
      CheckedIn,
      OwnerID,
      GuestID,
      [LName],
      [FName],
      [Address],
      [City],
      [State],
      [Zip],
      [phone],
      [Status]
  FROM FrontDesk
  ORDER BY Id ASC

DECLARE @arrival as DateTime
DECLARE @departure as DateTime
DECLARE @id as int

-- loop over the temprary table
SELECT @id = (SELECT MIN(id) FROM @FrontDeskRows)
SELECT @arrival = Arrival FROM @FrontDeskRows Where id = @id
SELECT @departure = Departure FROM @FrontDeskRows Where id = @id
  WHILE @id IS NOT NULL
   BEGIN

    -- PROCESS EACH ROW HERE

    -- get the next item in the temporary table
    SELECT @id = (SELECT MIN(id) FROM @FrontDeskRows WHERE id > @id)
    SELECT @arrival = Arrival FROM @FrontDeskRows Where id = @id
    SELECT @departure = Departure FROM @FrontDeskRows Where id = @id

   END
...