oracle 11g logminer字段USERNAME 为unknown的处理

郑全

Column USERNAME And SESSION_INFO Are UNKNOWN Or NULL In V$LOGMNR_CONTENTS (文档 ID 110301.1)

登录/注册后可看大图 转到底部

登录/注册后可看大图

---

                               
登录/注册后可看大图

Applies to:  Oracle Database - Enterprise Edition - Version 8.1.7.0 and later Information in this document applies to any platform. ***Checked for relevance on 29-Jul-2013*** SymptomsYou have just built the LogMiner dictionary and started the LogMiner session. You query V$LOGMNR_CONTENTS expecting to see the USERNAME and SESSION_INFO for some particular redo or undo operation. However, the USERNAME field is NULL. This is NOT a recursive operation, and the USERNAME column is expected to contain a non-null value. Cause If supplemental logging was not active at the time when the redo records were created, then LogMiner won't be able to obtain all the required information. The Oracle Database Utilities manual mentions: By default, Oracle Database does not provide any supplemental logging, which means that by default LogMiner is not usable. Therefore, you must enable at least minimal supplemental logging prior to generating log files which will be analyzed by LogMiner. So, we have to enable supplemental logging by using a SQL statement similar to the following: SQL> CONNECT / AS SYSDBA SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; Then the information necessary to populate the USERNAME and SESSION_INFO columns will be stored in the redo stream. The redo stream does not contain the USERNAME and SESSION_INFO data for every transaction. This information is only stored for the first transaction executed in the user's session. So in order to be able to see this information in V$LOGMNR_CONTENTS, all the redo generated during the entire session must be added to the mining session. Should this not be done, then the USERNAME and SESSION_INFO columns will remain empty. LogMiner was first available in Oracle8i. If the COMPATIBLE instance parameter is set to a value lower than 8.1.0 you will not have access to its full functionality. In Oracle9i and lower releases of Oracle, the TRANSACTION_AUDITING instance parameter is set to TRUE by default. This causes the generation of a redo record containing the user logon name, username, session ID, and some operating system and client information. For each successive transaction in the session, Oracle will store only the session ID. These session IDs are linked back to the first record to retrieve user and session information. When TRANSACTION_AUDITING is set to FALSE, this redo record is not written and the user information is not available to LogMiner. SolutionThis can result from your database parameter settings and also from the method you are using to mine redo logs using LogMiner. Ensure that database was in minimum supplemental logging at the time that the redo information was created: SQL> SELECT name, supplemental_log_data_min FROM v$database; NAME                           SUPPLEME ------------------------------ -------- M10202WA                       YES Ensure that all archive redo logs containing the necessary redo information have been added to the LogMiner session. Ensure that the COMPATIBLE initialization parameter is set to 8.1.0 or higher. SQL> show parameter compatible NAME                                 TYPE        VALUE ------------------------------------ ----------- ---------- compatible                           string      10.2.0.2.0 For Oracle8i and Oracle9i only: ensure that the TRANSACTION_AUDITING instance parameter is set to TRUE (default). SQL> show parameter transaction_auditing NAME                                 TYPE        VALUE ------------------------------------ ----------- ---------- transaction_auditing                 boolean     TRUE

郑全

其实就是开启最小追加日志数据：


sql> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

之后，再去查询 ：

SELECT name, supplemental_log_data_min FROM v$database;

郑全

这个最小追加日志没有打开，在 flashback_transaction_query中，sql_undo列将是空的
同时，通过logminer取出的数据，有关客户信息部分，包含machine_info,username,client_info等等都是空的

mengqianke

谢谢，记下来了。