最近把 shopunt 網站重啟的Log加上，發現網站有兩次時無預警的重啟
但是沒有exception log, 於是去看系統的 Event log, 發現出現以下的錯誤

應用程式: w3wp.exe

Framework 版本: v4.0.30319

描述: 處理序已終止，因為有未處理的例外狀況。

例外狀況資訊: System.Exception

堆疊:

於 UW.SQL.DTFromSQL(System.String, System.String)

於 UW.SQL.DTFromSQL(System.String, System.Data.SqlClient.SqlConnection ByRef, Boolean)

於 SHOPUNT.DB.Product.RebuildNotStopProducDT()

於 System.Threading.ExecutionContext.runTryCode(System.Object)

於 System.Runtime.CompilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode, CleanupCode, System.Object)

於 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)

於 System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object)

於 System.Threading.ThreadHelper.ThreadStart()



---------------------------------------------------------------------------------------------------------------------------------------



失敗的應用程式名稱: w3wp.exe，版本: 7.5.7601.17514，時間戳記: 0x4ce7afa2

失敗的模組名稱: KERNELBASE.dll，版本: 6.1.7601.18229，時間戳記: 0x51fb1677

例外狀況碼: 0xe0434352

錯誤位移: 0x000000000000940d

失敗的處理程序識別碼: 0x57c4

失敗的應用程式開始時間: 0x01d012faf33398f8

失敗的應用程式路徑: c:\windows\system32\inetsrv\w3wp.exe

失敗的模組路徑: C:\Windows\system32\KERNELBASE.dll

報告識別碼: 90ad2f4d-7f89-11e4-8ad2-e41f13b7d81e

原因是另開 Thread 以非同步取得非停售產品的資料時 產生 sql timeout，這時網站就整個 Crash 
約兩分鐘後才重新啟動，我想雙11網站一直Crash應該跟這個有關

改善方式:
1. RebuildNotStopProducDT 要 Try Catch 不要丟 exception 直接寄 mail 就好
2. 資料庫取得 "非停售產品" 有點沒有效率，不忙時至少要跑 4 秒，資料庫一忙就會Timeout，所以應該要把確定下架且不會販售的產品設定為停售 (Is_StopSell = 'Y')，這樣至少少了2000件產品的查詢，可以秒殺

另外 .NET 4.0 有新的物件叫做 Task 可以用來處理非同步程式，也可以處理 exception 狀況，有時間的話再來改看看
 

半夜被老闆 Line，跟我說網頁發生錯誤，他無法看統計報表，會出現作業逾時的錯誤 我查了一下網頁程式，發現是這筆SQL指令跑太久

 Select Id, (IsNull(Total, 0) - IsNull(CouponDiscount, 0) + IsNull(CouponAdd, 0)) as Total, Buyer_Email, EN_Packing_List_Status, EN_Order_Source, En_Stock_Status, Create_Date

From V_Order_main With(Nolock)

Where Id in (select Order_Id from Ad_Trace With(NoLock) where (Parameter_Id = 14278))

AND Create_Date >= '2014/10/3' And Create_Date < '2014/10/12' 

--> 跑了50秒~ 1分鐘

 Select Id, (IsNull(Total, 0) - IsNull(CouponDiscount, 0) + IsNull(CouponAdd, 0)) as Total, Buyer_Email, EN_Packing_List_Status, EN_Order_Source, En_Stock_Status, Create_Date

From V_Order_main With(Nolock)

Where Id in (select Order_Id from Ad_Trace With(NoLock) where (Parameter_Id = 14278))

--> 拿掉日期限制 > 秒殺，  結果跑出 47 筆資料

跑一下執行計畫 原來子查詢的 Ad_Trace 沒有建立Index造成


加上 Index 之後，再跑第一支SQL --> 秒殺

奇怪的地方:
明明訂單日期欄位(Create_Date) 跟 Ad_Trace 沒有多大關係，但是加上日期限制之後，居然會引發 Ad_Trace 搜尋過久的現象
他好像是先依照訂單日期找出所有訂單，然後再從子查詢 Ad_Trace 裡面搜尋有無符合的條件訂單
而不是先跑子查詢找出 Ad_Trace 所有的 Order_Id，再去找符合 Create_Date 的訂單

SQL內部運作的機制真是有點讓人想不透，幸好有評估計畫可以看出問題在哪裡
這讓我想起以前學SQL時的一句話 => 盡量用Join來取代子查詢
使用子查詢真的是效能殺手啊

------繼續補充--------------------------------------

上面的SQL在雙11活動後，由於當日訂單過多，一樣造成SQL timeout 的現象，研判還是子查詢造成的問題

Select Id, (IsNull(Total, 0) - IsNull(CouponDiscount, 0) + IsNull(CouponAdd, 0)) as Total, Buyer_Email, EN_Packing_List_Status, EN_Order_Source, En_Stock_Status, Create_Date

From V_Order_main With(Nolock)

Where Id in (select Order_Id from Ad_Trace With(NoLock) where (Parameter_Id = 14720))

And Create_Date > '2014-11-10' And Create_Date < '2014-11-11'

--> 跑了51秒

所以先將子查詢拿出來跑出一串字串 865828,865890,865901,865903,865928,865955,865990,865993,866005,866035.....
(共1452筆)
再把他拼入sql跑   --> 7秒
 

SELECT s.name

FROM sys.schemas s

WHERE s.principal_id = USER_ID('YourUserID');



ALTER AUTHORIZATION ON SCHEMA::YourSchemaName TO dbo;

參考：http://blog.sqlauthority.com/2011/12/26/sql-server-fix-error-15138-the-database-principal-owns-a-schema-in-the-database-and-cannot-be-dropped/

例子:
select 
SUM(case when is_deleted='Y' then price else 0 end) as total_of_deleted_item_price,
SUM(case when is_deleted='N' then price else 0 end) as total_of_item_price,
cust_id
from order group by cust_id

在 SQL 2008 可以用以下的 SQL

DECLARE @DBName VARCHAR(64) = 'CHIComp01'

 

DECLARE @ErrorLog AS TABLE([LogDate] CHAR(24), [ProcessInfo] VARCHAR(64), [TEXT] VARCHAR(MAX))

 

INSERT INTO @ErrorLog

EXEC sys.xp_readerrorlog 0, 1, 'Recovery of database', @DBName

 

SELECT TOP 5

     [LogDate]

    ,SUBSTRING([TEXT], CHARINDEX(') is ', [TEXT]) + 4,CHARINDEX(' complete (', [TEXT]) - CHARINDEX(') is ', [TEXT]) - 4) AS PercentComplete

    ,CAST(SUBSTRING([TEXT], CHARINDEX('approximately', [TEXT]) + 13,CHARINDEX(' seconds remain', [TEXT]) - CHARINDEX('approximately', [TEXT]) - 13) AS FLOAT)/60.0 AS MinutesRemaining

    ,CAST(SUBSTRING([TEXT], CHARINDEX('approximately', [TEXT]) + 13,CHARINDEX(' seconds remain', [TEXT]) - CHARINDEX('approximately', [TEXT]) - 13) AS FLOAT)/60.0/60.0 AS HoursRemaining

    ,[TEXT]

 

FROM @ErrorLog ORDER BY [LogDate] DESC

在 SQL 2012 可以用以下的 SQL:

DECLARE @DBName VARCHAR(64) = 'databasename'



DECLARE @ErrorLog AS TABLE([LogDate] CHAR(24), [ProcessInfo] VARCHAR(64), [TEXT] VARCHAR(MAX))



INSERT INTO @ErrorLog

EXEC master..sp_readerrorlog 0, 1, 'Recovery of database', @DBName



SELECT TOP 5

[LogDate]

,SUBSTRING([TEXT], CHARINDEX(') is ', [TEXT]) + 4,CHARINDEX(' complete (', [TEXT]) - CHARINDEX(') is ', [TEXT]) - 4) AS PercentComplete

,CAST(SUBSTRING([TEXT], CHARINDEX('approximately', [TEXT]) + 13,CHARINDEX(' seconds remain', [TEXT]) - CHARINDEX('approximately', [TEXT]) - 13) AS FLOAT)/60.0 AS MinutesRemaining

,CAST(SUBSTRING([TEXT], CHARINDEX('approximately', [TEXT]) + 13,CHARINDEX(' seconds remain', [TEXT]) - CHARINDEX('approximately', [TEXT]) - 13) AS FLOAT)/60.0/60.0 AS HoursRemaining

,[TEXT]



FROM @ErrorLog ORDER BY [LogDate] DESC

結果如下:
 


資料來源:
http://timlaqua.com/2009/09/determining-how-long-a-database-will-be-in-recovery-sql-server-2008/
 

這之前就知道的東西，但今天發現一個新寫法與各位分享

最常用寫法

INSERT INTO table (name) VALUES('bob');

SELECT SCOPE_IDENTITY()

新發現的寫法

INSERT INTO table (name)

OUTPUT Inserted.ID

VALUES('bob');

在 valuse 前面加上 Inserted.Id
這個有個優點 如果是GUID產生的 Id 也可以取得

一開始我用的是先傳 : CONVERT(varchar(10), Create_Date, 111) 的結果到VB 
後還Bike 教我可在SQL就先轉成 "weekday" : Datepart(dw,Create_Date) 但是效率還是有點慢
後來發現加在一起可以變更快 : Datepart(dw,CONVERT(varchar(10), Create_Date, 111))
可能是因為先變成比較好判斷的長度  實驗幾次後真的會比較快一點 
varchar(10)  可以取到需要的位數就好 varchar(10)  似乎會比 varchar(100) 再快一點 雖然測試機差異不大

參考來源：http://seasuwang.blogspot.tw/2009/09/sql-server-log.html

SQL Server 2008 Transcation log 檔案太大，導致SQL Server無法運作
將SQL Server的執行程序停止，手動刪除log實體檔案，再次啟動SQL Server的程序，資料庫沒辦法work

參考 Seasu Wang 說明把資料庫給救回來，步驟如下：
假設資料庫名稱為OhMyGod
1. 停止SQL Server, 將原mdf檔移走
2. 開啟SQL Server, 建立新的OhMyGod資料庫.
3. 停止SQL Server
4. 將損壞的mdf覆蓋回新建的mdf檔,並刪除新建的log檔
5. 開啟SQL Server
3. 設定OhMyGod資料庫狀態為EMERGENCY:
ALTER DATABASE OhMyGod SET EMERGENCY
4. 設定OhMyGod資料庫模式為"單一使用者":
sp_dboption 'OhMyGod', 'single user', 'true'
5. 檢查指定資料庫中所有物件的配置、結構和邏輯完整性:
DBCC CHECKDB (OhMyGod, REPAIR_ALLOW_DATA_LOSS)
6. 還原OhMyGod資料庫模式:
sp_dboption 'OhMyGod', 'single user', 'false'
7. 設定OhMyGod資料庫狀態為
ONLINE:ALTER DATABASE OhMyGod SET ONLINE
 

建置


想使用 SQL Server的全文檢索功能，先去[控制台][系統管理工具][服務]看以下兩項服務是否有啟動：
1. SQL Full-Text Filter Daemon Launcher(MSSQLSERVER)：建立 fdhost.exe處理序的服務，這是主控處理全文檢索索引之文字資料的斷詞工具與篩選的必要項目。
2. SQL Server Agent(MSSQLSERVER)：透過 SQL Server Agent作業的排程，啟動全文檢索－索引母體的擴展，累加資料表母體擴展。

如果沒有啟動第一項服務(SQL Full-Text...)，直接進行 Select全文查詢，會出現錯誤訊息如下：
SQL Server在與全文篩選器的後台程序宿主(FDHOST)的進程通信時遇到錯誤0x80070218。
請確保 FDHOST進程正在運行。若要重新啟動FDHOST進程，請運行 sp_fulltext_service 'restart_all_fdhosts' 的命令或重新啟動 SQL Server實例。

參考網址：
http://blog.xuite.net/sugopili/computerblog/76684376-SQL+Server%E5%85%A8%E6%96%87%E6%AA%A2%E7%B4%A2%E5%B0%8F%E6%8A%80%E5%B7%A7

使用 & 設定
設定
看網址
使用

設定全文檢索並以建立索引後，就可以透過條件 WHERE CONTAINS(欄位,搜尋的字)的方式，
來做全文檢索的查詢方式，下面範例程式碼， 依序介紹平常使用Like及全文檢索下CONTAINS用法。

參考網址：
http://www.dotblogs.com.tw/dotjum/archive/2009/08/01/9796.aspx

Question :  update sql 若有簡體字. 會出現? 
Sol :   '  '   在加字串第一個的 ' (單引號)  前 加上 N  (大寫)
資料庫型態須定義為 ntext 或是 nchar , nvarchar
若定義成一般習慣前面未加 'N' 使用 Big-5