存儲過程7年後隨機停止工作

Question

我爲一家對衝基金工作，我們的數據庫系統最近開始行動起來。我做了一些調查，實施錯誤代碼以及每個過程之間的消息框。我終於找到問題所在：它似乎在SQL中的存儲過程中。

我們在Windows XP SP3上使用VB 2005，Access for SQL表視圖和Microsoft Server Management Studio Express。

其他每個過程都在起作用。以下是它的工作原理：

我們從bloomberg填寫創建.csv文件的事務。這個.csv文件被放入一個名爲BBGT_Transactions的SQL表中。這是一個直接複製。這個過程很完美。每次運行過程（每30分鐘），交易就在那裏。接下來，相同的過程將BBGT_Transactions中的事務處理並將其複製到事務中。從VB調用看起來像：

Public Sub CopyNewEMSTransactions() 

     Log.Info("Copying new transactions from BBGTransactions to Transactions") 
     DAL.sqlcmd("CopyNewEMSTransactions") 

End Sub 

CopyNewEMSTransactions是一個存儲過程，它看起來像：

USE [IPAS] 
GO 
/****** Object: StoredProcedure [dbo].[CopyNewEMSTransactions] Script Date: 10/28/2013 13:34:15 ******/ 
SET ANSI_NULLS ON 
GO 
SET QUOTED_IDENTIFIER ON 
GO 
-- ============================================= 
-- Author:  Name 
-- Create date: 
-- Description: 
-- ============================================= 
ALTER PROCEDURE [dbo].[CopyNewEMSTransactions] 
    -- Add the parameters for the stored procedure here 
AS 
BEGIN 
    -- SET NOCOUNT ON added to prevent extra result sets from 
    -- interfering with SELECT statements. 
    SET NOCOUNT ON; 

    -- Insert statements for procedure here 

--New Code: Accounts for option trades through bloomberg terminal 
INSERT INTO Transactions (Account, TDate, [Time], SDate, Class, 
           [Type], Ticker, Quantity, Price, SEDOL, 
           CUSIP, Comments, OrderNumber, ISIN) 
    SELECT TranAccount AS Account, 
      (SELECT CAST(FLOOR(CAST(ExecDate AS float)) AS datetime)) AS TDate, 
      ExecDate + ExecTime - '1899-12-30' AS [Time], 
      ExecDate + 3 AS SDate, CASE EMS.Broker 
            WHEN 'CIBC' THEN 'Equity' 
            WHEN 'CIBO' THEN 'Option' END AS Class, 
      CASE Side 
      WHEN 'SS' THEN 'SHORT' 
      WHEN 'B' THEN 'BUY' 
      WHEN 'S' THEN 'SELL' 
      WHEN 'BS' THEN 'BUY' 
      ELSE 'UNKNOWN' 
      END AS Type, EMS.Ticker, 
      CASE Side 
      WHEN 'SS' THEN -1 
      WHEN 'S' THEN -1 
      WHEN 'B' THEN 1 
      WHEN 'BS' THEN 1 
      END * FillAmount AS Quantity, 
      AveragePrice AS Price, 
      SEDOL, CUSIP, 
      Comments = 'Bloomberg data', 
      LatestRows.OrderNumber, ISIN 
    FROM  
     (SELECT Ticker, OrderNumber, MAX(ExecSeqNumber) AS LastExecSeqNumber 
     FROM BBGTransactions 
     WHERE OrderNumber NOT IN (SELECT OrderNumber FROM Transactions 
            WHERE Comments = 'Bloomberg data') 

     GROUP BY OrderNumber, Ticker) LatestRows 
    LEFT JOIN 
     --Changed from "SELECT * From BBGTransactions" to add the ' Equity' 
     (SELECT BBG_ID, ExecDate, ExecTime, TranAccount, 
      CASE Broker 
       WHEN 'CIBC' THEN Ticker 
       WHEN 'CIBO' THEN Ticker + ' Equity' END AS Ticker, 
     --With option trades, SEDOL is not used anywhere. It used to be used for the Reconciliation report 
     --but that report has been changed to look at option ticker instead. 
     CASE Broker 
      WHEN 'CIBC' THEN SEDOL 
      WHEN 'CIBO' THEN NULL END AS SEDOL, 
     CUSIP, OrderNumber, Side, FillAmount, AveragePrice, ExecLastFillPX, Broker, Currency, OrderType, 
     LimitPrice, DayFillAmount, DayAvgPrice, ISIN, Amount, ExecType, ExecSeqNumber, ExecPrevSeqNumber FROM BBGTransactions) EMS 
    ON LatestRows.LastExecSeqNUmber = EMS.ExecSeqNumber 
     AND LatestRows.OrderNumber = EMS.OrderNumber 
    WHERE LatestRows.OrderNumber NOT IN (SELECT OrderNumber FROM Transactions 
           WHERE Comments = 'Bloomberg data') 

END 

它不返回任何錯誤，並顯示「複製BBGT到事務表」，然後選擇「完成」，但沒有按不要複製！它工作了7年，大約3周前停止工作。

事情要記住：

• 在過去的一個月，我們有很時斷時續的互聯網
• 我懷疑Windows更新中運行，並沒有更新的Windows此之前〜3年以上。上次檢查時有70次更新，現在沒有更新。
• 回到幽靈是我的最後手段，因爲這將需要大量的工作在我的最終實施
• 沒有代碼改變了！
• 我試過只運行存儲過程，它沒有做任何事情，因爲懷疑。

編輯 得到了示蹤劑日誌，只運行的程序。它雖然沒有返回錯誤？

SELECT SYSTEM_USER 
go 
SET ROWCOUNT 0 SET TEXTSIZE 2147483647 SET NOCOUNT OFF SET CONCAT_NULL_YIELDS_NULL ON SET ARITHABORT ON SET LOCK_TIMEOUT -1 SET QUERY_GOVERNOR_COST_LIMIT 0 SET DEADLOCK_PRIORITY NORMAL SET TRANSACTION ISOLATION LEVEL READ COMMITTED SET ANSI_NULLS ON SET ANSI_NULL_DFLT_ON ON SET ANSI_PADDING ON SET ANSI_WARNINGS ON SET CURSOR_CLOSE_ON_COMMIT OFF SET IMPLICIT_TRANSACTIONS OFF SET QUOTED_IDENTIFIER ON 
go 
select @@spid select SERVERPROPERTY('ProductLevel') 
go 
USE [IPAS] 

go 

DECLARE @return_value int 

EXEC @return_value = [dbo].[CopyNewEMSTransactions] 

SELECT 'Return Value' = @return_value 


go 
exec sp_execute 18,5930,5924,5925,5926,5927,5928,5929,5923,5921,5922 
go 
exec sp_execute 16,59826,59827,59756,59757,59758,59716,59715,59700,59701,59702 
go 

而且，相應的Excel表格：

鏈接，櫃面很難看：

http://i.stack.imgur.com/iJFRo.png

---

Select語句＃1（似乎正在工作）：

SELECT Ticker, OrderNumber, MAX(ExecSeqNumber) AS LastExecSeqNumber 
FROM BBGTransactions 
WHERE OrderNumber NOT IN (SELECT OrderNumber FROM Transactions 
          WHERE Comments = 'Bloomberg data') 
GROUP BY OrderNumber, Ticker 

返回：

鏈接：http://imgur.com/3A8E1JR

選擇2：

CODE：

SELECT BBG_ID, ExecDate, ExecTime, TranAccount, 
    CASE Broker 
     WHEN 'CIBC' THEN Ticker 
     WHEN 'CIBO' THEN Ticker + ' Equity' END AS Ticker, 
    --With option trades, SEDOL is not used anywhere. It used to be used for the Reconciliation report 
    --but that report has been changed to look at option ticker instead. 
    CASE Broker 
     WHEN 'CIBC' THEN SEDOL 
     WHEN 'CIBO' THEN NULL END AS SEDOL, 
    CUSIP, OrderNumber, Side, FillAmount, AveragePrice, ExecLastFillPX, Broker, Currency, OrderType, 
    LimitPrice, DayFillAmount, DayAvgPrice, ISIN, Amount, ExecType, ExecSeqNumber, ExecPrevSeqNumber 
    FROM BBGTransactions 
    WHERE LatestRows.OrderNumber NOT IN (SELECT OrderNumber FROM Transactions 
             WHERE Comments = 'Bloomberg data') 

錯誤 服務器：消息4104，級別16，狀態1， 1號線 多 - 部分標識符「LatestRows.OrderNumber」不能被綁定。

Answer 1

-I have tried running ONLY the stored procedure and it does nothing. 

你期望它返回什麼？它是否顯示任何受影響的行？

NO CODE WAS CHANGED EVER 

您確定架構沒有更改嗎？您是否嘗試運行查詢並親自查看它是否有效？ （在沒有來自SP的插入命令的情況下運行選擇）

確定您使用的是正確的數據庫嗎？這可能也會改變..

你確定你的VB代碼實際上完成了嗎？我會嘗試在SP執行後打印日誌，這裏可能會出現一個我們沒有看到的異常。

Answer 2

您爲對衝基金工作，獲得標準許可證並且不使用免費贈品。

它看起來不像你發佈的實際存儲過程，而是一個「清理」版本，以顯示它的工作原理。這實際上是一種障礙，而不是一種幫助。

很難說在這個刪除，但我會說你有一個數據問題（查詢運行完全一樣，因爲它總是有，但你擁有的數據不會返回任何結果），或者你終於超出了快速版本中的限制。

忘掉運行SP，提取查詢並直接運行它們，感受一下數據的實際外觀。如果選擇有效但不是插入，則可能超出快速版本的限制。如果select沒有返回預期的行，那麼你有一個數據問題。

Answer 3

電腦不做「隨機」.. 有些事情已經改變，這是導致意想不到的結果。單步執行代碼是唯一可以確定的方法。