前文中，我們簡單介紹了數(shù)據(jù)庫安全審計(jì)技術(shù)中難點(diǎn)之一：參數(shù)化語句的審計(jì)。SQL語句的句柄維護(hù)和參數(shù)還原是數(shù)據(jù)庫審計(jì)中兩個(gè)技術(shù)關(guān)鍵點(diǎn)。在實(shí)際審計(jì)中，即使簡單的SQL語句，也可能出現(xiàn)漏審，而對(duì)于更為復(fù)雜的批量參數(shù)綁定的語句，數(shù)據(jù)庫安全審計(jì)產(chǎn)品的語句解析能力能夠則明顯顯現(xiàn)。

批量參數(shù)綁定是DBMS提供商為了提供更為高效的數(shù)據(jù)操作速度，而提供的一批參數(shù)發(fā)送，語句多次執(zhí)行；該方式通過更少的網(wǎng)絡(luò)通訊次數(shù)、更少的SQL層的語境切換等大幅度提高編程效率。這種執(zhí)行方式在一般的編程中很少使用，但在類似于電信運(yùn)營商的計(jì)費(fèi)系統(tǒng)這樣的環(huán)境，對(duì)性能的要求很高，往往需要每秒接近上萬條的插入或更新，則是一種較為常見的使用方式；因此對(duì)于運(yùn)行商、證券金融、互聯(lián)網(wǎng)這樣的瞬時(shí)交易量非常大，需要采用最為高效的數(shù)據(jù)處理方式的應(yīng)用環(huán)境需要對(duì)這種參數(shù)綁定方式兼容。

下面是一個(gè)批量插入的示例，僅僅是為了檢驗(yàn)審計(jì)產(chǎn)品是否支持該功能：

PreparedStatement statement = connection.prepareStatement("INSERT INTO Tbl1 VALUES(?, ?)");

//記錄1

statement.setInt(1, 1);

statement.setString(2, "Cujo");

statement.addBatch();

//記錄2

statement.setInt(1, 2);

statement.setString(2, "Fred");

statement.addBatch();

//記錄3

statement.setInt(1, 3);

statement.setString(2, "Mark");

statement.addBatch();

//批量執(zhí)行上面3條語句.

int [] counts = statement.executeBatch(); 

在上面實(shí)例中，我們需要考察所使用的數(shù)據(jù)庫審計(jì)產(chǎn)品，能否準(zhǔn)確地審計(jì)下3條插入語句并且每條語句都能準(zhǔn)確地匹配上相應(yīng)的參數(shù)；或者審計(jì)為1條插入語句，3組參數(shù)。

這只是批量插入中一個(gè)不算困難的挑戰(zhàn)，更為復(fù)雜的是更大批量的情況，Oracle和SQL Server這樣的考慮更為精細(xì)的產(chǎn)品，會(huì)對(duì)數(shù)據(jù)采用壓縮的處理方式，比如對(duì)重復(fù)值的表達(dá)，對(duì)Null值的表達(dá)等；數(shù)據(jù)庫審計(jì)產(chǎn)品是否能有效地還原每個(gè)批量成員的值，將會(huì)是一個(gè)挑戰(zhàn)。

當(dāng)前我們所見到的絕大多數(shù)數(shù)據(jù)庫審計(jì)產(chǎn)品在批量參數(shù)綁定的執(zhí)行語句的情況下，都無法準(zhǔn)確審計(jì)下批量查詢中所執(zhí)行的語句和對(duì)應(yīng)的參數(shù)。正是基于多年的數(shù)據(jù)庫內(nèi)核研發(fā)經(jīng)驗(yàn)，918搏天堂的技術(shù)團(tuán)隊(duì)擁有對(duì)復(fù)雜SQL語句的理解和分析能力，對(duì)于類似上面的復(fù)雜語句形式，918搏天堂的數(shù)據(jù)庫安全審計(jì)產(chǎn)品依然能夠準(zhǔn)確解析并審計(jì)記錄。