新聞中心
一:背景
1. 講故事
前些天看到一個奇怪的 Function 函數,調用的是 C# 鏈接庫中的一個 UserLogin 方法,參考代碼如下:

CREATE FUNCTION dbo.clr_UserLogin
(
@name AS NVARCHAR(100),
@password AS NVARCHAR(100)
)
RETURNS INT
AS
EXTERNAL NAME asmXXX.[xxx.CLRFunctions].UserLogin;
GO
這就讓我產生了很大的興趣,眾所周知 SQLSERVER 是 C++ 寫的,那這里的 C++ 怎么和 C# 打通呢?而且 C# 是一門托管語言,需要 JIT 將其 native 化,這個 JIT 又在哪里呢?帶著這些疑問一起研究下吧。
二:互通原理研究
1. 一個簡單的例子
首先寫一段簡單的 C# 代碼,然后把它編譯成 dll。
namespace AQMN.Bussiness
{
public class UserFunctions
{
public static string UserLogin(string username, string password)
{
var random = new Random();
var isSuccess = random.Next() % 2 == 0;
return isSuccess ? "登錄成功" : "登錄失敗";
}
}
}
接下來需要做的就是數據庫參數配置,開啟 CLR 支持,并且指定某個數據庫支持 unsafe 模式。
EXEC sp_configure 'clr enabled', 1;
RECONFIGURE;
GO
ALTER DATABASE MyTestDB SET TRUSTWORTHY ON;
GO
為了能夠調到 C# 的 UserLogin 方法,需要 SQLSERVER 先導入這個程序集,然后再以 Function 映射其中方法即可,參考代碼如下:
CREATE ASSEMBLY clr_AQMN_Bussiness
FROM 'D:\net6\SQLCrawl\AQMN.Bussiness\bin\Debug\AQMN.Bussiness.dll'
WITH PERMISSION_SET = UNSAFE;
GO
CREATE FUNCTION dbo.clr_UserLogin
(
@username AS NVARCHAR(100),
@password AS NVARCHAR(100)
)
RETURNS NVARCHAR(100)
AS
EXTERNAL NAME clr_AQMN_Bussiness.[AQMN.Bussiness.UserFunctions].UserLogin;
GO
創(chuàng)建完了之后,可以觀察 assembly 開頭的幾個系統(tǒng)視圖。
SELECT * FROM sys.assemblies
SELECT * FROM sys.assembly_files;
SELECT * FROM sys.assembly_modules;
看起來沒啥問題,接下來調用一下剛才創(chuàng)建的 clr_UserLogin 函數。
SELECT dbo.clr_UserLogin(N'jack',N'123456') AS 'State'
GO 10
從圖中看登錄結果是隨機的,說明 C# 的 Random 函數起到了作用,非常有意思。
2. WinDbg 觀察
從案例的運行結果看,推測在 SQLSERVER 中應該承載了一個 CLR 運行環(huán)境,那是不是這樣呢?可以用 WinDbg 附加到 ??sqlservr.exe?? 進程,用 lm 觀察下模塊加載情況。
0:092> lm
start end module name
...
00007ff8`d3960000 00007ff8`d3aaf000 clrjit (deferred)
00007ff8`de040000 00007ff8`deb02000 clr (deferred)
...
0:092> !eeversion
4.8.4300.0 free
Server mode with 12 gc heaps
SOS Version: 4.8.4300.0 retail build
從輸出看果然加載了 clr 和 clrjit 動態(tài)鏈接庫,當前還是 gc server 模式,哈。
接下來再驗證一個問題,既然 clr_UserLogin 函數會顯示 登錄成功/登錄失敗,那必然會調用 C# 的 UserLogin 方法,可以在 WinDbg 中對 UserLogin 方法下一個斷點觀察一下這個調用過程。
0:090> !name2ee AQMN.Bussiness!AQMN.Bussiness.UserFunctions.UserLogin
Module: 00007ff87ee37988
Assembly: AQMN.Bussiness, Versinotallow=1.0.0.0, Culture=neutral, PublicKeyToken=null
Token: 0000000006000001
MethodDesc: 00007ff87ee38020
Name: AQMN.Bussiness.UserFunctions.UserLogin(System.String, System.String)
JITTED Code Address: 00007ff87ec560d0
0:090> bp 00007ff87ec560d0
0:090> g
從輸出信息看 UserLogin 方法已經被 JIT 過了,用 bp 下完斷點之后,繼續(xù) g,然后在 SSMS 上再次執(zhí)行查詢就可以成功命中啦。
0:090> k
# Child-SP RetAddr Call Site
00 000000df`1557ae48 00007ff8`7ee500b6 0x00007ff8`7ec560d0
01 000000df`1557ae50 00007ff8`7ec55ef1 0x00007ff8`7ee500b6
02 000000df`1557aeb0 00007ff8`de04222e 0x00007ff8`7ec55ef1
03 000000df`1557af00 00007ff8`a2b79ff3 clr!UMThunkStub+0x6e
04 000000df`1557af90 00007ff8`a2b741bd sqllang!CallProtectorImpl::CallWithSEHconst >+0x23
05 000000df`1557afc0 00007ff8`a2b6bfc4 sqllang!CallProtectorImpl::CallExternalFullconst >+0x2dd
06 000000df`1557b130 00007ff8`a2bda602 sqllang!CAppDomain::InvokeClrFn+0xd4
07 000000df`1557b1d0 00007ff8`aef51ee7 sqllang!UDFInvokeExternalImpl+0xb72
08 000000df`1557b7e0 00007ff8`9de52e24 sqlTsEs!CEsExec::GeneralEval4+0xe7
09 000000df`1557b8b0 00007ff8`9de52d64 sqlmin!CQScanProjectNew::EvalExprs+0x18f
0a 000000df`1557b920 00007ff8`9ddd8759 sqlmin!CQScanProjectNew::GetRow+0x98
0b 000000df`1557b970 00007ff8`9ddc73de sqlmin!CQScanLightProfileNew::GetRow+0x19
0c 000000df`1557b9a0 00007ff8`a25e51d7 sqlmin!CQueryScan::GetRow+0x80
0d 000000df`1557b9d0 00007ff8`a32a78b2 sqllang!CXStmtQuery::ErsqExecuteQuery+0x3d8
0e 000000df`1557bb40 00007ff8`a2bc2451 sqllang!CXStmtSelect::XretDoExecute+0x342
0f 000000df`1557bc10 00007ff8`a2b733d3 sqllang!UM_LoopbackForStatementExecution+0x191
10 000000df`1557bd00 00007ff8`de48e940 sqllang!AppDomainCallback>+0x23
11 000000df`1557bd40 00007ff8`de48e193 clr!ExecuteInAppDomainHelper+0x40
12 000000df`1557bd80 00007ff8`a2b79f39 clr!CorHost2::ExecuteInAppDomain+0x3a0
13 000000df`1557c0a0 00007ff8`a2b73a86 sqllang!CallProtectorImpl::CallWithSEH>+0x29
14 000000df`1557c0d0 00007ff8`a2b6c2d0 sqllang!CallProtectorImpl::CallExternalFull>+0x186
15 000000df`1557c170 00007ff8`a32a72f4 sqllang!CAppDomain::LoopbackForStatementExecution+0x180
16 000000df`1557c230 00007ff8`a32a79ad sqllang!CXStmtQuery::XretCLRExecute+0x104
17 000000df`1557c2a0 00007ff8`a25e4a65 sqllang!CXStmtSelect::XretExecute+0x4a
18 000000df`1557c370 00007ff8`a25e44a8 sqllang!CMsqlExecContext::ExecuteStmts<1,1>+0x8f2
19 000000df`1557cf10 00007ff8`a25e3a2c sqllang!CMsqlExecContext::FExecute+0x936
1a 000000df`1557def0 00007ff8`a25ee67b sqllang!CSQLSource::Execute+0xc5c
1b 000000df`1557e3d0 00007ff8`a25ed815 sqllang!process_request+0xca6
1c 000000df`1557ead0 00007ff8`a25ed5ef sqllang!process_commands_internal+0x4b7
1d 000000df`1557ec00 00007ff8`b1e46523 sqllang!process_messages+0x1d6
1e 000000df`1557ede0 00007ff8`b1e46e6d sqldk!SOS_Task::Param::Execute+0x232
1f 000000df`1557f3e0 00007ff8`b1e46c75 sqldk!SOS_Scheduler::RunTask+0xa5
20 000000df`1557f450 00007ff8`b1e6b160 sqldk!SOS_Scheduler::ProcessTasks+0x39d
21 000000df`1557f570 00007ff8`b1e6aa5b sqldk!SchedulerManager::WorkerEntryPoint+0x2a1
22 000000df`1557f640 00007ff8`b1e6afa4 sqldk!SystemThreadDispatcher::ProcessWorker+0x3ed
23 000000df`1557f940 00007ff8`f6d86fd4 sqldk!SchedulerManager::ThreadEntryPoint+0x3b5
24 000000df`1557fa30 00007ff8`f865cec1 KERNEL32!BaseThreadInitThunk+0x14
25 000000df`1557fa60 00000000`00000000 ntdll!RtlUserThreadStart+0x21
果然是一個 request 請求,然后達到了托管方法 UserLogin,頂部的三行線程??梢杂?nbsp;!clrstack 具意下。
0:090> !clrstack
OS Thread Id: 0x6df4 (90)
Child SP IP Call Site
000000df1557ae48 00007ff87ec560d0 AQMN.Bussiness.UserFunctions.UserLogin(System.String, System.String)
000000df1557ae50 00007ff87ee500b6 DynamicClass.SQLCLR_Eval(IntPtr, IntPtr, IntPtr)
000000df1557aeb0 00007ff87ec55ef1 DomainBoundILStubClass.IL_STUB_ReversePInvoke(Int64, Int64, Int64)
000000df1557bf18 00007ff8de04222e [ContextTransitionFrame: 000000df1557bf18]
三:總結
SQLSERVER 內嵌了 CLR,讓 sqlservr 進程成了一種托管和非托管的混合環(huán)境,不知道是好事還是壞事,在我的分析旅程中這種混合環(huán)境下看過太多的堆破壞問題,但不管怎么說,托管的 C#,VB,F# 可以助 SQLSERVER 更加強大。
網站標題:SQLServer居然也能調C#代碼?
標題路徑:http://www.dlmjj.cn/article/dpdpcde.html


咨詢
建站咨詢
