用以下指令可以對 Ms-SQL Server 查出所有正在執行的 SQL 指令，並且依 執行總時間 反向排序

SELECT      r.scheduler_id as 排程器識別碼,

            status         as 要求的狀態,

            r.session_id   as SPID,

            r.blocking_session_id as BlkBy,

            substring(

                ltrim(q.text),

                r.statement_start_offset/2+1,

                (CASE

                 WHEN r.statement_end_offset = -1

                 THEN LEN(CONVERT(nvarchar(MAX), q.text)) * 2

                 ELSE r.statement_end_offset

                 END - r.statement_start_offset)/2)

                 AS [正在執行的 T-SQL 命令],

            r.cpu_time      as [CPU Time(ms)],

            r.start_time    as [開始時間],

            r.total_elapsed_time as [執行總時間],

            r.reads              as [讀取數],

            r.writes             as [寫入數],

            r.logical_reads      as [邏輯讀取數],

            -- q.text, /* 完整的 T-SQL 指令碼 */

            d.name               as [資料庫名稱]

FROM        sys.dm_exec_requests r 

            CROSS APPLY sys.dm_exec_sql_text(sql_handle) AS q

            LEFT JOIN sys.databases d ON (r.database_id=d.database_id)

WHERE       r.session_id <> @@SPID

ORDER BY    r.total_elapsed_time desc

最近剛好發生跟 MS SQL 有關的狀況，所以就記錄一下

1. where 字串欄位要不要加 N''  (unicode)
    範例: Select * from OrderDetail where OrderDetailId= N'20220923084533'
    基本上，欄位是 char、varchar 就不需要。nvarchar nchar 就要加 N
    這好像是廢話，但往往寫程式會沒注意，甚至是會覺得通通加 N 比較沒問題
    但如果欄位牽涉到 index 就會影響搜尋 ，所以寫程式當下要注意

-- 假設 OrderDetailId 是 varchar(20)

-- OrderDetail 有千萬筆資料



Select * from OrderDetail where OrderDetailId= N'20220923084533'

-- 結果跑超級久 (未使用 PK 找，掃整個 table)

Select * from OrderDetail where OrderDetailId= '20220923084533'

-- 結果一下就出來 (使用 PK 找)

-- **資料庫設計最好以數值來當 key 比較好

    
2.  當欄位有 null 值，where [clumnName] not in ('A')  也會排除 null 的狀況
     直覺上，只要下 not in (..)  那會其他項目都會抓出，但是實際上，該欄位是 null的資料也會被排除
     因為資料庫一旦你對某欄位下條件，他就會排除 null 的欄位，除非你指定  [clumnName] is null 才會有資料
 

比較方式: 對相同的資料表讀取 1000 次，來比較速度。
資料庫為 MS SQL

這裡做了 4 個 Case:

Case 1: 
使用 Entity Framework，DbContext 為每次 new 一個。

Case 2:
使用 Entity Framework，使用同一個 DbContext。

Case 3:
用 DAO，轉為 Data Table 的格式 (使用 DtFromSql)。

Case 4:
使用 Dapper。

專案啟動時的記憶體使用量約為:  123 MB



測試一:
第一次讀取
Case 1, 時間: 3673.0303 ms, 記憶體: 566 MB

Case 2, 時間:  3889.9379 ms, 記憶體: 304 MB  (這個時間有時會測試到 3000 ms)

Case 3, 時間:  1665.7748 ms, 記憶體: 205 MB

Case 4, 時間:  1639.7211 ms, 記憶體: 193 MB

讀取五次
Case 1, 時間: 1984.6395, 記憶體: 544MB (有發生 GC)


Case 2, 時間:  2367.9792 ms, 記憶體: 627 MB (沒有發生 GC)


Case 3, 時間:  1395.1132 ms, 記憶體: 280 MB (有發生 GC)



Case 4, 時間:  1531.3555 ms, 記憶體: 271 MB


結果: Dapper 看來完勝，速度上和直接使用 DAO 轉進 Data Table 的速度相近。但 Dapper 傳回的結果已經轉換為物件 List， 操作上會更為方便。

Entity Framework 一如預期的較慢，且花費較多的記憶體。但和想像中最大的差異是，使用同一個 DbContext 比 new 1000 個 DbContext  的速度還要慢， 花費的記憶體在 GC 之後，差異不大。

所以不一定要用 DI 注入 DbContext, 在各 function 中一直傳遞 DbContext. 在 Static 的 function 中，可以安心的 new 一個 DbContext 出來使用吧，只是要記得用 using 哦，否則可能會有 connection 沒有關閉的問題。


 

已經有資料的資料庫無法更改。

開啟 sqlplus
用 sys 登入 XPEDB1 指定為SYSDBA 的身份

--sqlplus SYS/password@localhost/XEPDB1 as SYSDBA

sqlplus / as SYSDBA

--修改 NLS_CHARACTERSET to ZHT16MSWIN950
shutdown immediate;
STARTUP MOUNT;
ALTER SESSION SET SQL_TRACE=TRUE;
ALTER SYSTEM ENABLE RESTRICTED SESSION;
ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0;
ALTER SYSTEM SET AQ_TM_PROCESSES=0;
ALTER DATABASE OPEN;
ALTER DATABASE CHARACTER SET INTERNAL_USE ZHT16MSWIN950;
ALTER SESSION SET SQL_TRACE=FALSE;
shutdown immediate;
STARTUP;

查詢 nvarchar 的欄位
select owner, table_name, column_name
from dba_tab_columns
where (data_type = 'NCHAR' or
data_type = 'NVARCHAR2' or
data_type = 'NCLOB') and
owner != 'SYS' and
owner != 'SYSTEM';

要 truncate 兩個 table:
truncate table SYS.RADM_FPTM_LOB$;
truncate table SYS.RADM_FPTM$ ;

執行以下指令

修改 System 的 NLS_NCHAR_CHARACTERSET:
shutdown immediate;
STARTUP MOUNT;
ALTER SYSTEM ENABLE RESTRICTED SESSION;
ALTER SYSTEM SET JOB_QUEUE_PROCESSES=0 SCOPE = MEMORY;
ALTER SYSTEM SET AQ_TM_PROCESSES=0 SCOPE = MEMORY;
ALTER DATABASE OPEN;
ALTER DATABASE NATIONAL CHARACTER SET UTF8;
SHUTDOWN IMMEDIATE;
STARTUP;

要修特定  PDB 的 NLS_NCHAR_CHARACTERSET:
alter session set container=cdb$root;
show pdbs;
alter pluggable database XEPDB1  close immediate;
alter pluggable database XEPDB1 open read write restricted;
alter session set container=XEPDB1;
truncate table SYS.RADM_FPTM_LOB$;
truncate table SYS.RADM_FPTM$;
ALTER DATABASE NATIONAL CHARACTER SET UTF8;
ALTER PLUGGABLE DATABASE XEPDB1 CLOSE IMMEDIATE;
ALTER PLUGGABLE DATABASE XEPDB1 OPEN;
select * from database_properties where PROPERTY_NAME in ('NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET');

由於 CDN 模式下，網站在判別 client ip 是透過 X-Forwarded-For 來判別來源IP
但因為 X-Forwarded-For 是可以偽裝的 header value，所以 hacker 會在裡面帶入特殊的IP，例如 127.0.0.1

這在正常 CDN 模式下，基本上應該沒有問題，因為程式上抓到的 X-Forwarded-For 會是最後一組IP
但萬一 client 端 不走CDN直連主機，開發者抓 client IP 是先抓 X-Forwarded-For，而不判斷網站是不是在 CDN 模式下
就會誤判來源IP。

解決方式可分為兩方面
1. 抓 X-Forworded-For 的 function 要判別內網IP (包括127.0.0.1)，剔除掉
2. 網站程式判別白名單時，要用 Reuest.UserHostAddress 來判別內部IP
    使用 ClientIP_After_CDN 只能用來判別外部IP 
    * 如果允許IP清單寫在系統參數或資料庫，但內容是 (內網IP + 外網IP)混用，最好是分開來

另外有一個防火牆的設定有關，也是建置網站很重要的設定
也就是設定 policy 時 wan -> virtual ip ，要記得把 NAT 關掉，
不然網站抓到的 UserHostAddress 都會是 190.168.x.254 之類的IP，這樣問題就大了。

    
    
 

從A主機DB直接讀取B主機的DB，使用圖形介面一直無法設定成功，改用SQL語法一下就搞定了。

操作界面： 



T-SQL:

 USE [master]

GO

EXEC master.dbo.sp_addlinkedserver

     @server = N'連線名稱',

     @srvproduct=N'SQLNCLI',

     @provider=N'SQLOLEDB',

     @datasrc=N'192.168.8.198\SQL2008'

GO



USE [master]

GO

EXEC master.dbo.sp_addlinkedsrvlogin

    @rmtsrvname = N'連線名稱',

    @locallogin = NULL ,

    @useself = N'False',

    @rmtuser = N'資料庫登入帳號',

    @rmtpassword = N'資料庫連線密碼'

GO

 

今天因為一個客戶的專案, 試了一下用 Entity Framework 把 Store Procedure 包成一個 function. 被卡了一下, 發現要先 Compile  才會看到新增的 function,  記錄一下, 希望看到的人能省點時間 .....

1. 從資料庫更新模型


2. 選擇要匯入的 Store Procedure


3. 完成匯入匯入後, function 並不會生出來. 
 
 4. Compile 之後, 才會看到這個 function.
 
 


 

https://dotblogs.com.tw/jerrywang0109/2017/04/16/164223

SQL恢復[正在還原]資料庫

-- 切換資料庫的狀態為：ONLINE。

RESTORE DATABASE [資料庫名稱]
WITH RECOVERY
GO

UW -> DB 物件產生器會產生兩個function
GetAllDataFromBaseTableWithCache(string OrderFields = "_Default", bool IsCopy = true )
以及
Get物件名稱FromCachedDT(string Key)
-----------------------------------------------------------
設計上是希望將所有資料Cache在記憶體，然後前端直接抓出資料，不須到資料庫抓資料
理論上網頁速度應該比較佳，實際上卻發現是效能殺手

原因在於 GetAllDataFromBaseTableWithCache 是抓出整個table的資料放到 Cache
然後又做了一件事，當有人要資料時，會把整個 DataTable 做 Copy() 再 return
也就是說，當DataTable有數千筆資料列時
每叫用一次 "Get物件名稱FromCachedDT(string Key)" 就會把數千筆資料整個複製一次
再從複製出來的DataTable Select 出一列 return
------------------------------------------------------------
解決方法:
Get物件名稱FromCachedDT(string Key)  --> 改成一筆一筆資料做 Cache，這樣 Copy() 只會Copy一筆
實測上，原本頁面要跑1.8秒，調整後可以 0.4 秒就完成
-----------------------------------------------------------
結論:
PG產生器就把 GetAllDataFromBaseTableWithCache 拿掉吧

使用 SQL Server 管理介面設定欄位權限時要很小心陷井. 如下圖,
1. Col2 和 Id 欄位沒有被授予也沒有被拒絕.
2. 若是設定 Col2 欄位為授予, Id 欄位沒有做任何的修改.
3. 存檔後, Id 欄位會被拒絶存取.

 
以上的情況是用以下 SQL 生成:

GRANT SELECT ON OBJECT::S3..test TO webuser;
Deny SELECT ON OBJECT::S3..test(Col1) TO webuser;