漏洞报告显示：
 Medium (CVSS: 5.8)
 NVT: HTTP Debugging Methods (TRACE/TRACK) Enabled
 References
 cve: CVE-2003-1567 cve: CVE-2004-2320 cve: CVE-2004-2763 cve: CVE-2005-3398 cve: CVE-2006-4683 cve: CVE-2007-3008 cve: CVE-2008-7253 cve: CVE-2009-2823 cve: CVE-2010-0386 cve: CVE-2012-2223 cve: CVE-2014-7883
 bid: 9506
 bid: 9561
 bid: 11604
 Summary
 The remote web server supports the TRACE and/or TRACK methods. TRACE and TRACK are HTTP methods which are used to debug web server connections.
 Solution:
 Solution type: Mitigation
 Disable the TRACE and TRACK methods in your web server con guration. Please see the manual of your web server or the references for more information
 漏洞解决：根据建议关闭‘TRACE and TRACK methods ’
 处理方法：Apache版本大于2.2，在httpd.conf末尾添加：
 TraceEnable off
 1.查看Apache版本：httpd -v
 
 2.在httpd.conf末尾添加TraceEnable off
 
 3.验证

 
在httpd.conf添加
 
TraceEnable off
 

 
 
 
  
 Monitoring Errors with Trace Files and the Alert Log 
 
  
 Each server and background process can write to an associated trace file. When an internal error is detected by a process, it dumps information about the error to its trace file. Some of the information written to a trace file is intended for the database administrator, and other information is for Oracle Support Services. Trace file information is also used to tune applications and instances. 
 
  
 
   
 Note: 
 Critical errors also create incidents and incident dumps in the Automatic Diagnostic Repository. See 
   Chapter 9, "Managing Diagnostic Data" for more information. 
  
 
  
 The alert log is a chronological log of messages and errors, and includes the following items:
 
  
 
 All internal errors (ORA-00600), block corruption errors (ORA-01578), and deadlock errors (ORA-00060) that occur 
 
 
 Administrative operations, such as CREATE, ALTER, and DROP statements and STARTUP, SHUTDOWN, and ARCHIVELOG statements 
 
 
 Messages and errors relating to the functions of shared server and dispatcher processes 
 
 
 Errors occurring during the automatic refresh of a materialized view 
 
 
 The values of all initialization parameters that had nondefault values at the time the database and instance start 
 
  
 Oracle Database uses the alert log to record these operations as an alternative to displaying the information on an operator's console (although some systems also display information on the console). If an operation is successful, a "completed" message is written in the alert log, along with a timestamp. 
 
  
 The alert log is maintained as both an XML-formatted file and a text-formatted file. You can view either format of the alert log with any text editor or you can use the ADRCI utility to view the XML-formatted version of the file with the XML tags stripped. 
 
  
 Check the alert log and trace files of an instance periodically to learn whether the background processes have encountered errors. For example, when the log writer process (LGWR) cannot write to a member of a log group, an error message indicating the nature of the problem is written to the LGWR trace file and the alert log. Such an error message means that a media or I/O problem has occurred and should be corrected immediately. 
 
  
 Oracle Database also writes values of initialization parameters to the alert log, in addition to other important statistics. 
 
  
 The alert log and all trace files for background and server processes are written to the Automatic Diagnostic Repository, the location of which is specified by the DIAGNOSTIC_DEST initialization parameter. The names of trace files are operating system specific, but each file usually includes the name of the process writing the file (such as LGWR and RECO). 
 
  
 
   
 See Also: 
 
   
 
 Chapter 9, "Managing Diagnostic Data" for information on the Automatic Diagnostic Repository. 
 
 
 "Alert Log" for additional information about the alert log. 
 
 
 "Viewing the Alert Log" 
 
 
 Oracle Database Utilities for information on the ADRCI utility. 
 
 
 Your operating system specific Oracle documentation for information about the names of trace files 
 
  
 
   
  
 
    
   
 Controlling the Size of Trace Files 
 
   
 You can control the maximum size of all trace files (excluding the alert log) using the initialization parameter MAX_DUMP_FILE_SIZE, which limits the file to the specified number of operating system blocks. To control the size of an alert log, you must manually delete the file when you no longer need it. Otherwise the database continues to append to the file. 
 
   
 You can safely delete the alert log while the instance is running, although you should consider making an archived copy of it first. This archived copy could prove valuable if you should have a future problem that requires investigating the history of an instance. 
 
  
 
   
  
 
    
   
 Controlling When Oracle Database Writes to Trace Files 
 
   
 Background processes always write to a trace file when appropriate. In the case of the ARCn background process, it is possible, through an initialization parameter, to control the amount and type of trace information that is produced. This behavior is described in "Controlling Trace Output Generated by the Archivelog Process". Other background processes do not have this flexibility. 
 
   
 Trace files are written on behalf of server processes whenever critical errors occur. Additionally, setting the initialization parameter SQL_TRACE = TRUE causes the SQL trace facility to generate performance statistics for the processing of all SQL statements for an instance and write them to the Automatic Diagnostic Repository. 
 
   
 Optionally, you can request that trace files be generated for server processes. Regardless of the current value of the SQL_TRACE initialization parameter, each session can enable or disable trace logging on behalf of the associated server process by using the SQL statement ALTER SESSION SET SQL_TRACE. This example enables the SQL trace facility for a specific session: 
 
   
ALTER SESSION SET SQL_TRACE TRUE;
 
   
 Use the DBMS_SESSION or the DBMS_MONITOR packages to control SQL tracing for a session. 
 
   
 
    
 Caution: 
 The SQL trace facility for server processes can cause significant system overhead resulting in severe performance impact, so you should enable this feature only when collecting statistics. 
   
 
   
 
    
 See Also: 
 
    
 
 Chapter 9, "Managing Diagnostic Data" for more information on how the database handles critical errors, otherwise known as "incidents." 
 
   
 
  
 
  
   
  
 
   
 Reading the Trace File for Shared Server Sessions 
 
   
 If shared server is enabled, each session using a dispatcher is routed to a shared server process, and trace information is written to the server trace file only if the session has enabled tracing (or if an error is encountered). Therefore, to track tracing for a specific session that connects using a dispatcher, you might have to explore several shared server trace files. To help you, Oracle provides a command line utility program, trcsess, which consolidates all trace information pertaining to a user session in one place and orders the information by time. 
 
   
 
    
 See Also: 
 
    Oracle Database Performance Tuning Guide for information about using the SQL trace facility and using TKPROF and trcsess to interpret the generated trace files 
   
 
  
 
 
 
 
  
 
 Monitoring Database Operations with Server-Generated Alerts 
 
 
 A server-generated alert is a notification from the Oracle Database server of an impending problem. The notification may contain suggestions for correcting the problem. Notifications are also provided when the problem condition has been cleared. 
 
 
 Alerts are automatically generated when a problem occurs or when data does not match expected values for metrics, such as the following: 
 
 
 
 Physical Reads Per Second 
 
 
 User Commits Per Second 
 
 
 SQL Service Response Time 
 
 
 Server-generated alerts can be based on threshold levels or can issue simply because an event has occurred. Threshold-based alerts can be triggered at both threshold warning and critical levels. The value of these levels can be customer-defined or internal values, and some alerts have default threshold levels which you can change if appropriate. For example, by default a server-generated alert is generated for tablespace space usage when the percentage of space usage exceeds either the 85% warning or 97% critical threshold level. Examples of alerts not based on threshold levels are: 
 
 
 
 Snapshot Too Old 
 
 
 Resumable Session Suspended 
 
 
 Recovery Area Space Usage 
 
 
 An alert message is sent to the predefined persistent queue ALERT_QUE owned by the user SYS. Oracle Enterprise Manager reads this queue and provides notifications about outstanding server alerts, and sometimes suggests actions for correcting the problem. The alerts are displayed on the Enterprise Manager Database Home page and can be configured to send email or pager notifications to selected administrators. If an alert cannot be written to the alert queue, a message about the alert is written to the Oracle Database alert log. 
 
 
 Background processes periodically flush the data to the Automatic Workload Repository to capture a history of metric values. The alert history table and ALERT_QUE are purged automatically by the system at regular intervals. 
 
 
 
 
 来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/26844646/viewspace-1124383/，如需转载，请注明出处，否则将追究法律责任。 
 
 
转载于:http://blog.itpub.net/26844646/viewspace-1124383/

我们在Chrome开发者工具里调试的时候，有时需要把函数执行的调用堆栈信息保存到本地以便进一步处理：
 
 
然而Call stack列表下的数据无法复制粘贴。
 其实，我们只需要在console控制台里，输入console.trace:
 
 
这里打印的callstack是可以复制粘贴的：
 
 
ctrl v到本地即可：
 
 
更多Jerry的原创文章，尽在：“汪子熙”: