我的應用程序使用了設置模式和不合格的表，我從 snapdyn_sql 得到了令人困惑的數字

更多的是一個發現，而不是一個問題，我會在一分鐘內添加一個答案。

前幾天，我偶然發現了一個應用程序，它使用了多個具有相同名稱但在不同模式中的表。例子：

create table s1.parent (x int not null primary key);
create table s1.child (y int not null primary key, x int not null references s1.parent(x));

create table s2.parent (x int not null primary key);
create table s2.child (y int not null primary key, x int not null references s2.parent(x));

該應用程序使用以下模式：

set schema s1;
select * from parent x join child y on ...

儘管該問題已針對多個模式執行，但只有一行：

select num_executions, rows_read, stmt_text
from sysibmadm.snapdyn_sql
where stmt_text like '....%'

並且這些數字似乎對所有模式都是累積的。為什麼會這樣，我如何找出不同模式的指標？

更現代的表格功能：

select EXECUTABLE_ID, STMT_TEXT, num_executions 
from TABLE(MON_GET_PKG_CACHE_STMT('D', NULL, NULL, -2)) as T 
where stmt_text like 'select *%'"

返回不同模式的各個指標。

仍然需要進一步檢查才能找出屬於每個模式的 executable_id，所以我更喜歡查詢中的限定表名而不是set schema模式。

如果表未按模式限定，則可以通過以下方式檢測模式：

select EXECUTABLE_ID, VALUE as SCHEMA, STMT_TEXT, num_executions
from TABLE(MON_GET_PKG_CACHE_STMT('D', NULL, NULL, -2)) as T 
CROSS JOIN TABLE(COMPILATION_ENV(T.COMP_ENV_DESC)) S 
where stmt_text like 'select *%' 
 and name = 'SCHEMA'

有關 COMPILATION_ENV 的更多詳細資訊可以在Mark Ba​​rinstein提供的答案中找到

這是預期的行為。對此有一個內部技術說明。

COMPILATION_ENV 表函式有助於設置current schema每個 executable_id。

引用自：https://dba.stackexchange.com/questions/228422