Oracle基本命令教程.docx

活动状态检查 通过查询基本视图，确认数据库和实例处于正常运行的状态，可以对外提供数据服务。回复“D1”查看此步骤下全部命令。 实例状态 select instance_name,status from v$instance; 查询返回实例名称、状态。 会话信息 select sessions_current,sessions_highwater from v$license; 实例当前会话数据和启动最高连接会话数量 select inst_id,username,count(*) from gv$session group by inst_id,username; 查询数据库以用户分组连接数 参数检查 select value from v$parameter where name=open_cursors; 查询给定参数的设置值，示例参数缺省值为300，通常中等规模数据库推荐设置为1000。 参数修改 alter system set undo_retention=3600 comment=default 900 sid=ora11gdg scope=both; 修改给定的初始化参数，RAC环境需要注意SID参数。 隐含参数 select a.ksppinm name, b.ksppstvl value, a.ksppdesc description from x$ksppi a, x$ksppcv b where a.indx = b.indx and a.ksppinm like _optimizer_use_feedback; alter system set _optimizer_use_feedback=false scope=spfile; 应对特殊问题，有时需设置以下划线开头的隐含参数。示例关闭了11.2中引入的cardinality feedback 基数反馈特性。 Cardinality Feedback Cardinality Feedback是11GR2出现的一个新特性，它的出现是为了帮助ORACLE优化器依据更精准的Cardinality产生出更加优秀的执行计划。Cardinality基数的评估准确与否，对于优化器非常重要，直接影响到后续的JOIN COST等重要的成本计算评估，如果评估不当会造成CBO选择不当的执行计划。此技术对于仅执行一次SQL无效，在SQL第一次执行时，记录存储实际的Cardinality和评估的Cardinality之间的差异，如果差异较大，在第二次执行时，优化器会依据实际的Cardinality重新决策生成执行计划，但是需要注意的是，当使用更准确的Cardinality重新生成执行计划时，不一定生成的执行计划与第一次时不一样，完全有可能是相同的。这个技术的出现是由于优化器在一些情况下不能很好的去计算Cardinality的数值，比如：统计信息缺失或陈旧、多谓词、直方图缺失或者缺少直方图等等，在这些情况下，Cardinality?Feedback可能会帮上忙。 我们来看下Cardinality Feedback是如何发挥作用的。注意使用普通用户来测试Cardinality Feedback，sys用户被默认禁用该特性 select product_name from order_items o, product_information p where o.unit_price = 15 and quantity 1 and duct_id = duct_id; 在order_items表上有2个谓词，o.unit_price = 15 and quantity 1，由于优化器对于联合谓词评估不准，导致ORACLE优化器认为经过2个联合谓词的过滤，order_items表只返回一条记录，进而优化器选择了nest loop的执行计划。 ? ??如果Cardinality Feedback被开启，在SQL第一次执行结束后，ORACLE会把实际的Cardinality与评估的Cardinality做比较，如果差异较大，这些实际的Cardinality会被存储以期待SQL再次被执行时这些Cardinality被优化器所使用。我们看看第二次执行的情况： 发现ORACLE 优化器依据第一次执行所记录的Cardinality，重新评估执行计划，在第二次执行时，已经选择了HASH JOIN的执行计划，在执行计划的NOTE部分也看到了cardinality feedback used for this statement字样。11GR2针对此特性，也专门在V$SQL_SHARED_CURSOR中增加了?USE_FEEDBACK_STATS列来记录SQL是否使用了Cardinal