MYSQL网页编程之Oracle有用技能

对免费版的用户也具有充足的支持服务。在dev.mysql.com上，一个大型的MySQL学习教程强大社区用户和开发者可以讨论所有关于MySQL的事情。这个站点拥有博客、指南、视频、技术交流会、白皮书和论坛等方式的交流。oracle|技能1.找出无用索引:
　　
　DML功能低下，个中最严峻的缘故原由之一是无用索引的存在。一切SQL的拔出，更新和删除操纵在它们必要在每行数据被改动时修正大批索引的时分会变得更慢。很多Oracle办理职员只需瞥见在一个SQL查询的WHERE语句呈现了一列的话就会为它分派索引。固然这个办法可以让SQL运转得更疾速，可是基于功效的Oracle索引使得数据库办理职员有大概在数据表的行上过分分派索引。过分分派索引会严峻影响关头Oracle数据表的功能。
　　
　在Oracle9i呈现之前，没有举措断定SQL查询没有利用的索引。Oracle9i有一个工具可以让你利用ALTERINDEX命令监督索引的利用。然后你能够查找这些没有利用的索引并从数据库里删除它们。
　　
　上面是一段剧本，它可以翻开一个体系中一切索引的监督功效:
　　
　　spoolrun_monitor.sql
　　
　　selectalterindex||owner||.||index_name||monitoringusage;
　　
　　fromdba_indexes
　　
　　whereownernotin(SYS,SYSTEM);
　　
　　spooloff;
　　
　　@run_monitor
　　
　你必要守候一段工夫直到在数据库上运转了充足多的SQL语句今后，然后你就能够查询新的V$OBJECT_USAGE视图。
　　
　　selectindex_name,table_name,mon,used
　　
　　fromv$object_usage;
　　
　鄙人面，我们能够瞥见V$OBJECT_USAGE有一列被称作USED，它的值是YES大概NO。它不会告知你Oracle利用了这个索引几次，可是这个工具关于找出没有利用的索引仍是很有效的。
　　
　　SQL>select*fromv$object_usagewhererownum<10;
　　
　　INDEX_NAMETABLE_NAMEMONITORINGUSEDSTART_MONITORINGEND_MONITORING
　　
　　----------------------------------------------------------------------------------------------------------------
　　
　　ASDDIM_ACCT_ITEM_TYPE_TEMPYESNO01/15/200413:50:59
　　
　　IDX_ACCOUNT_ACCESSORY_TARIFF1ACCOUNT_ACCESSORY_TARIFFYESNO01/15/200413:50:59
　　
　　IDX_ACCOUNT_QUOTA_LOG1ACCOUNT_QUOTA_LOGYESNO01/15/200413:50:59
　　
　　IDX_ACCOUNT_SYSTEM_PARAMETERS1ACCOUNT_SYSTEM_PARAMETERSYESNO01/15/200413:50:59
　　
　　IDX_ACCT2ACCTYESNO01/15/200413:50:59
　　
　　IDX_ACCT3ACCTYESNO01/15/200413:51:00
　　
　　IDX_ACCT4ACCTYESNO01/15/200413:51:00
　　
　　IDX_ACCT_BIND_DISCT1ACCT_BIND_DISCTYESNO01/15/200413:51:00
　　
　　IDX_ACCT_BIND_DISCT2ACCT_BIND_DISCTYESNO01/15/200413:51:00
　　
　2.检察一个很长的操纵已做了几:
　　
　v$session_longops视图可使Oracle专家削减运转工夫很长的DDL和DML语句的运转工夫。比方在数据堆栈情况中，即便利用并行索引创立手艺，构建一个良多G字节年夜的索引必要泯灭良多个小时。这里你就能够查询v$session_longops视图疾速找出一个特定的DDL语句已完成了几。实在v$session_longops视图也能够用于任何运转工夫很长的操纵，包含运转工夫很长的更新操纵。
　　
　上面的剧本将显现一个形态信息，申明了运转工夫很长的DDL操纵已利用的工夫。注重你必需从v$session中获得SID并将其拔出到上面的SQL语句中:
　　
　　selectsid,start_time,elapsed_seconds,message
　　
　　fromv$session_longops
　　
　　wheresid=13
　　
　　orderbystart_time;
　　
　　这里是一个输入的例子，显现了运转工夫很长的CREATEINDEX语句的运转历程。
　　
　　SIDMESSAGE
　　
　　------------------------------------------------------------------
　　
　　11TableScan:CUST.PK_IDX:732outof243260Blocksdone
　　
　3.用settransaction命令办理ORA-01555毛病
　　
　在实行年夜事件时,偶然oracle会报出以下的毛病:
　　
　　ORA-01555:snapshottooold(rollbacksegmenttoosmall)
　　
　　这申明oracle给此事件随机分派的回滚段太小了,这时候能够为它指定一个充足年夜的回滚段,以确保这个事件的乐成实行.比方
　　
　　settransactionuserollbacksegmentroll_abc;
　　
　　deletefromtable_namewhere...;
　　
　　commit;
　　
　　提交停止后ORACLE会主动开释对roll_abc的指定。
　　
　4.删除表中反复纪录
　　
　办法道理:
　　
　1、Oracle中，每笔记录都有一个rowid，rowid在全部数据库中是独一的，　rowid断定了每笔记录是在ORACLE中的哪个数据文件、块、行上。
　　
　2、在反复的纪录中，大概一切列的内容都不异，但rowid不会不异，以是只需断定出反复纪录中那些具有最年夜rowid的就能够了，其他全体删除。
　　
　完成办法:
　　
　　SQL>createtablea(bmchar(4),mcvarchar2(20));
　　
　　Tablecreated
　　
　　SQL>insertintoavalues(1111,aaaa);
　　
　　SQL>insertintoavalues(1112,aaaa);
　　
　　SQL>insertintoavalues(1113,aaaa);
　　
　　SQL>insertintoavalues(1114,aaaa);
　　
　　SQL>insertintoaselect*froma;
　　
　　4rowsinserted
　　
　　SQL>commit;
　　
　　Commitcomplete
　　
　　SQL>selectrowid,bm,mcfroma;
　　
　　ROWIDBMMC
　　
　　------------------------------------------
　　
　　AAAIRIAAQAAAAJqAAA1111aaaa
　　
　　AAAIRIAAQAAAAJqAAB1112aaaa
　　
　　AAAIRIAAQAAAAJqAAC1113aaaa
　　
　　AAAIRIAAQAAAAJqAAD1114aaaa
　　
　　AAAIRIAAQAAAAJqAAE1111aaaa
　　
　　AAAIRIAAQAAAAJqAAF1112aaaa
　　
　　AAAIRIAAQAAAAJqAAG1113aaaa
　　
　　AAAIRIAAQAAAAJqAAH1114aaaa
　　
　　8rowsselected
　　
　查出反复纪录
　　
　　SQL>selectrowid,bm,mcfromawherea.rowid!=(selectmax(rowid)fromabwherea.bm=b.bmanda.mc=b.mc);
　　
　　ROWIDBMMC
　　
　　------------------------------------------
　　
　　AAAIRIAAQAAAAJqAAA1111aaaa
　　
　　AAAIRIAAQAAAAJqAAB1112aaaa
　　
　　AAAIRIAAQAAAAJqAAC1113aaaa
　　
　　AAAIRIAAQAAAAJqAAD1114aaaa
　　
　删除反复纪录
　　
　　SQL>deletefromaawherea.rowid!=(selectmax(rowid)fromabwherea.bm=b.bmanda.mc=b.mc);
　　
　删除4个纪录.
　　
　　SQL>selectrowid,bm,mcfroma;
　　
　　ROWIDBMMC
　　
　　------------------------------------------
　　
　　AAAIRIAAQAAAAJqAAE1111aaaa
　　
　　AAAIRIAAQAAAAJqAAF1112aaaa
　　
　　AAAIRIAAQAAAAJqAAG1113aaaa
　　
　　AAAIRIAAQAAAAJqAAH1114aaaa
　　
　5.把持文件破坏时的恢复
　　
　依据以下毛病信息，我们发明数据库只能启动实例，读把持文件时产生毛病。在数据库计划的过程当中，从平安的角度思索，体系利用了三个镜像的把持文件，如今三个把持文件version号纷歧致。
　　
　　SVRMGRL>startup
　　
　　oracleinstancestarted
　　
　　totalsystemglobalarea222323980bytes
　　
　　fixedsize70924bytes
　　
　　variablesize78667776bytes
　　
　　databasebuffers143507456bytes
　　
　　redobuffers77824bytes
　　
　　ORA-00214:controlfile‘d:oracleoradataorclcontrol01.ctl’version57460inconsistentwithfile‘d:oracleoradataorclcontrol02.ctl’version57452.
　　
　依据以上剖析，我们试着修正参数文件。将参数文件中的control_file参数修正为一个把持文件，分离利用control01、control02、control03。但数据库都没法启动，申明三个把持文件都已破坏。
　　
　因为没有把持文件的备份，我们只能接纳重修把持文件的做法。
　　
　　D:>svrmgrl
　　
　　OracleServerManagerRelease3.1.6.0.0-Production
　　
　　版权一切(c)1997，1999，OracleCorporation。保存一切权力。
　　
　　Oracle8iEnterpriseEditionRelease8.1.6.0.0-Production
　　
　　WiththePartitioningoption
　　
　　JServerRelease8.1.6.0.0-Production
　　
　　SVRMGR>connectinternal
　　
　　毗连乐成。
　　
　　SVRMGR>shutdowmabort
　　
　　已封闭ORACLE实例。
　　
　　SVRMGR>startupnomount
　　
　　已启动ORACLE实例。
　　
　　体系全局地区算计有108475660个字节
　　
　　FixedSize70924个字节
　　
　　VariableSize46116864个字节
　　
　　DatabaseBuffers62210048个字节
　　
　　RedoBuffers77824个字节
　　
　　SVRMGR>createcontrolfilereusedatabaseorclnoresetlogsarchivelog
　　
　　Logfilegroup1‘d:oracleoradataorcledo01.log’,
　　
　　group2‘d:oracleoradataorcledo02.log’,
　　
　　group3‘d:oracleoradataorcledo03.log’
　　
　　datafile‘d:oracleoradataorclsystem01.dbf’,
　　
　　‘d:oracleoradataorclusers01.dbf’,
　　
　　‘d:oracleoradataorcl        emp01.dbf’,
　　
　　‘d:oracleoradataorcl        ools01.dbf’,
　　
　　‘d:oracleoradataorclindx01.dbf’,
　　
　　‘d:oracleoradataorcldr01.dbf’,
　　
　　‘d:oracleoradataorclbs01.dbf’;
　　
　　语句已处置。
　　
　　乐成地重修把持文件后，我们实验着翻开数据库，但体系报错，提醒必要举行介质恢复。
　　
　　SVRMGR>recoverdatafile‘d:oracleoradataorclsystem01.dbf’;
　　
　　介质已恢复。
　　
　　SVRMGR>recoverdatafile‘d:oracleoradataorclusers0101.dbf’;
　　
　　介质已恢复。
　　
　　SVRMGR>recoverdatafile‘d:oracleoradataorcl        emp01.dbf’;
　　
　　介质已恢复。
　　
　　SVRMGR>recoverdatafile‘d:oracleoradataorcl        ools01.dbf’;
　　
　　介质已恢复。
　　
　　SVRMGR>recoverdatafile‘d:oracleoradataorclindx01.dbf’;
　　
　　介质已恢复。
　　
　　SVRMGR>recoverdatafile‘d:oracleoradataorcldr01.dbf’;
　　
　　介质已恢复。
　　
　　SVRMGR>recoverdatafile‘d:oracleoradataorclbs01.dbf’;
　　
　　介质已恢复。
　　
　　介质恢复后，从头翻开数据库，提醒日记文件也需恢复。
　　
　　SVRMGR>recoverdatabaseuntilcancel;
　　
　　日记已恢复。
　　
　把持文件、数据文件、日记文件全体恢复后，将三种文件同步，并翻开数据库，乐成地完成了数据库的恢停工作。
　　
　　SVRMGR>alterdatabaseopenresetlogs;
　　
　数据库已变动。
　　
　当即封闭数据库，并举行数据库的冷备份，将数据库的数据完全地保留上去。根据Evans的调查报告，“MySQL的使用在未来将继续呈成长趋势。”

如果处理少量数据,比如几百条记录的数据,我不知道这两种情况哪个效率更高,如果处理大量数据呢?比如有表中有20万条记录.

也可谈一下你是怎么优化存储过程的?

SQL语言是学习所有数据库产品的基础，无论你是做数据库管理还是做数据库开发都是这样。不过具体学习的侧重点要看你将来做哪一块，如果是做数据库管理（DBA），侧重点应该放在SQLServer的系统管理上.

我们学到了什么？思考问题的时候从表的角度来思考问

也可谈一下你是怎么优化存储过程的?

这一点很好的加强了profiler的功能。但是提到profiler提醒大家注意一点。windows2003要安装sp1补丁才能启动profiler。否则点击没有反应。

你可以简单地认为适合的就是好，不适合就是不好。

SQLServer的异构移植功能个人感觉最好了。（如果对比过SQLServer的链接服务器和Oracle的透明网关的朋友会发现SQLServer的sp_addlinkedserver(openquery)异构数据库系列比Oracle真是强太多了。）