SQL> create table t as select 1 id,object_name from dba_objects; Table created. SQL> insert into t select 2,object_name from dba_objects; 50366 rows created. SQL> insert into t select 3,object_name from dba_objects; 50366 rows created. SQL> insert into t select 4,object_name from dba_objects; 50366 rows created. SQL> commit; Commit complete. SQL> create index t_ind on t(id,object_name); Index created. SQL> exec dbms_stats.gather_table_stats('HR','T',cascade=>true); PL/SQL procedure successfully completed. 鎵ц鍏ㄨ〃鎵弿 SQL> select /*+ full(t) */ * from t where object_name='EMPLOYEES'; 6 rows selected. Execution Plan ---------------------------------------------------------- Plan hash value: 1601196873 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 5 | 135 | 215 (3)| 00:00:03 | |* 1 | TABLE ACCESS FULL| T | 5 | 135 | 215 (3)| 00:00:03 | -------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - filter("OBJECT_NAME"='EMPLOYEES') Statistics ---------------------------------------------------------- 0 recursive calls 0 db block gets 942 consistent gets 0 physical reads 0 redo size 538 bytes sent via SQL*Net to client 385 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 6 rows processed 涓嶉噰鐢╤int SQL> select * from t where object_name='EMPLOYEES'; 6 rows selected. Execution Plan ---------------------------------------------------------- Plan hash value: 2869677071 -------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 5 | 135 | 5 (0)| 00:00:01 | |* 1 | INDEX SKIP SCAN | T_IND | 5 | 135 | 5 (0)| 00:00:01 | -------------------------------------------------------------------------- Predicate Information (identified by operation id): --------------------------------------------------- 1 - access("OBJECT_NAME"='EMPLOYEES') filter("OBJECT_NAME"='EMPLOYEES') Statistics ---------------------------------------------------------- 1 recursive calls 0 db block gets 17 consistent gets 1 physical reads 0 redo size 538 bytes sent via SQL*Net to client 385 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 6 rows processed 褰撳叏琛ㄦ壂鎻忔壂鎻忎簡942涓潡錛岃仈鍚堢儲寮曞彧鎵弿浜?7涓暟鎹潡銆傚彲浠ョ湅鍒拌仈鍚堢儲寮曠殑絎竴涓瓧孌電殑鍊奸噸澶嶇巼寰堥珮鏃訛紝鍗充嬌璋撹瘝涓病鏈夎仈鍚堢儲寮曠殑絎竴涓瓧孌碉紝渚濈劧浼氫嬌鐢╥ndex_ss鏂瑰紡錛屾晥鐜囪繙榪滈珮浜庡叏琛ㄦ壂鎻忔晥鐜囥備絾褰?/font>絎竴涓瓧孌電殑鍊奸噸澶嶇巼寰堜綆鏃訛紝浣跨敤index_ss鐨勬晥鐜囪浣庝簬鍏ㄨ〃鎵弿錛岃鑰呭彲浠ヨ嚜琛屽疄楠?/font> 鍜岃〃鐨勫叧鑱旂浉鍏崇殑hint
/*+ leading(table_1,table_2) */
鍦ㄥ琛ㄥ叧鑱旀煡璇腑錛屾寚瀹氬摢涓〃浣滀負椹卞姩琛紝鍗沖憡璇変紭鍖栧櫒棣栧厛瑕佽闂摢涓〃涓婄殑鏁版嵁銆?/span> select /*+ leading(t,t1) */ t.* from t,t1 where t.id=t1.id; /*+ order */
璁㎡racle鏍規嵁from鍚庨潰琛ㄧ殑欏哄簭鏉ラ夋嫨椹卞姩琛紝oracle寤鴻浣跨敤leading錛屼粬鏇翠負鐏墊椿 select /*+ order */ t.* from t,t1 where t.id=t1.id; /*+ use_nl(table_1,table_2) */ 鍦ㄥ琛ㄥ叧鑱旀煡璇腑錛屾寚瀹氫嬌鐢╪est loops鏂瑰紡榪涜澶氳〃鍏寵仈銆?/span>
select /*+ use_nl(t,t1) */ t.* from t,t1 where t.id=t1.id;
select /*+ full(employees) cache(employees) */ last_name from employees 闄勫綍hint琛ㄦ牸
Hints for Optimization Approaches and Goals
ALL_ROWS
The ALL_ROWS hint explicitly chooses the cost-based approach to optimize a statement block with a goal of best throughput (that is, minimum total resource consumption).
FIRST_ROWS
The FIRST_ROWS hint explicitly chooses the cost-based approach to optimize a statement block with a goal of best response time (minimum resource usage to return first row). In newer Oracle version you should give a parameter with this hint: FIRST_ROWS(n) means that the optimizer will determine an executionplan to give a fast response for returning the first n rows.
CHOOSE
The CHOOSE hint causes the optimizer to choose between the rule-based approach and the cost-based approach for a SQL statement based on the presence of statistics for the tables accessed by the statement
RULE
The RULE hint explicitly chooses rule-based optimization for a statement block. This hint also causes the optimizer to ignore any other hints specified for the statement block. The RULE hint does not work any more in Oracle 10g.
Hints for Access Paths
FULL
The FULL hint explicitly chooses a full table scan for the specified table. The syntax of the FULL hint is FULL(table) where table specifies the alias of the table (or table name if alias does not exist) on which the full table scan is to be performed.
ROWID
The ROWID hint explicitly chooses a table scan by ROWID for the specified table. The syntax of the ROWID hint is ROWID(table) where table specifies the name or alias of the table on which the table access by ROWID is to be performed. (This hint depricated in Oracle 10g)
CLUSTER
The CLUSTER hint explicitly chooses a cluster scan to access the specified table. The syntax of the CLUSTER hint is CLUSTER(table) where table specifies the name or alias of the table to be accessed by a cluster scan.
HASH
The HASH hint explicitly chooses a hash scan to access the specified table. The syntax of the HASH hint is HASH(table) where table specifies the name or alias of the table to be accessed by a hash scan.
HASH_AJ
The HASH_AJ hint transforms a NOT IN subquery into a hash anti-join to access the specified table. The syntax of the HASH_AJ hint is HASH_AJ(table) where table specifies the name or alias of the table to be accessed.(depricated in Oracle 10g)
INDEX
The INDEX hint explicitly chooses an index scan for the specified table. The syntax of the INDEX hint is INDEX(table index) where:table specifies the name or alias of the table associated with the index to be scanned and index specifies an index on which an index scan is to be performed. This hint may optionally specify one or more indexes:
NO_INDEX
The NO_INDEX hint explicitly disallows a set of indexes for the specified table. The syntax of the NO_INDEX hint is NO_INDEX(table index)
INDEX_ASC
The INDEX_ASC hint explicitly chooses an index scan for the specified table. If the statement uses an index range scan, Oracle scans the index entries in ascending order of their indexed values.
INDEX_COMBINE
If no indexes are given as arguments for the INDEX_COMBINE hint, the optimizer will use on the table whatever boolean combination of bitmap indexes has the best cost estimate. If certain indexes are given as arguments, the optimizer will try to use some boolean combination of those particular bitmap indexes. The syntax of INDEX_COMBINE is INDEX_COMBINE(table index).
INDEX_JOIN
Explicitly instructs the optimizer to use an index join as an access path. For the hint to have a positive effect, a sufficiently small number of indexes must exist that contain all the columns required to resolve the query.
INDEX_DESC
The INDEX_DESC hint explicitly chooses an index scan for the specified table. If the statement uses an index range scan, Oracle scans the index entries in descending order of their indexed values.
INDEX_FFS
This hint causes a fast full index scan to be performed rather than a full table.
NO_INDEX_FFS
Do not use fast full index scan (from Oracle 10g)
INDEX_SS
Exclude range scan from query plan (from Oracle 10g)
INDEX_SS_ASC
Exclude range scan from query plan (from Oracle 10g)
INDEX_SS_DESC
Exclude range scan from query plan (from Oracle 10g)
NO_INDEX_SS
The NO_INDEX_SS hint causes the optimizer to exclude a skip scan of the specified indexes on the specified table. (from Oracle 10g)
Hints for Query Transformations
NO_QUERY_TRANSFORMATION
Prevents the optimizer performing query transformations. (from Oracle 10g)
USE_CONCAT
The USE_CONCAT hint forces combined OR conditions in the WHERE clause of a query to be transformed into a compound query using the UNION ALL set operator. Normally, this transformation occurs only if the cost of the query using the concatenations is cheaper than the cost without them.
NO_EXPAND
The NO_EXPAND hint prevents the optimizer from considering OR-expansion for queries having OR conditions or IN-lists in the WHERE clause. Usually, the optimizer considers using OR expansion and uses this method if it decides that the cost is lower than not using it.
REWRITE
The REWRITE hint forces the optimizer to rewrite a query in terms of materialized views, when possible, without cost consideration. Use the REWRITE hint with or without a view list. If you use REWRITE with a view list and the list contains an eligible materialized view, then Oracle uses that view regardless of its cost.
NOREWRITE / NO_REWRITE
In Oracle 10g renamed to NO_REWRITE. The NOREWRITE/NO_REWRITE hint disables query rewrite for the query block, overriding the setting of the parameter QUERY_REWRITE_ENABLED.
MERGE
The MERGE hint lets you merge views in a query.
NO_MERGE
The NO_MERGE hint causes Oracle not to merge mergeable views. This hint is most often used to reduce the number of possible permutations for a query and make optimization faster.
FACT
The FACT hint indicated that the table should be considered as a fact table. This is used in the context of the star transformation.
NO_FACT
The NO_FACT hint is used in the context of the star transformation to indicate to the transformation that the hinted table should not be considered as a fact table.
STAR_TRANSFORMATION
The STAR_TRANSFORMATION hint makes the optimizer use the best plan in which the transformation has been used. Without the hint, the optimizer could make a query optimization decision to use the best plan generated without the transformation, instead of the best plan for the transformed query.
NO_STAR_TRANSFORMATION
Do not use star transformation (from Oracle 10g)
UNNEST
The UNNEST hint specifies subquery unnesting.
NO_UNNEST
Use of the NO_UNNEST hint turns off unnesting for specific subquery blocks.
Hints for Join Orders
LEADING
Give this hint to indicate the leading table in a join. This will indicate only 1 table. If you want to specify the whole order of tables, you can use the ORDERED hint. Syntax: LEADING(table)
ORDERED
The ORDERED hint causes Oracle to join tables in the order in which they appear in the FROM clause. If you omit the ORDERED hint from a SQL statement performing a join , the optimizer chooses the order in which to join the tables. You may want to use the ORDERED hint to specify a join order if you know something about the number of rows selected from each table that the optimizer does not. Such information would allow you to choose an inner and outer table better than the optimizer could.
Hints for Join Operations
USE_NL
The USE_NL hint causes Oracle to join each specified table to another row source with a nested loops join using the specified table as the inner table. The syntax of the USE_NL hint is USE_NL(table table) where table is the name or alias of a table to be used as the inner table of a nested loops join.
NO_USE_NL
Do not use nested loop (from Oracle 10g)
USE_NL_WITH_INDEX
Specifies a nested loops join. (from Oracle 10g)
USE_MERGE
The USE_MERGE hint causes Oracle to join each specified table with another row source with a sort-merge join. The syntax of the USE_MERGE hint is USE_MERGE(table table) where table is a table to be joined to the row source resulting from joining the previous tables in the join order using a sort-merge join.
NO_USE_MERGE
Do not use merge (from Oracle 10g)
USE_HASH
The USE_HASH hint causes Oracle to join each specified table with another row source with a hash join. The syntax of the USE_HASH hint is USE_HASH(table table) where table is a table to be joined to the row source resulting from joining the previous tables in the join order using a hash join.
NO_USE_HASH
Do not use hash (from Oracle 10g)
Hints for Parallel Execution
PARALLEL
The PARALLEL hint allows you to specify the desired number of concurrent query servers that can be used for the query. The syntax is PARALLEL(table number number). The PARALLEL hint must use the table alias if an alias is specified in the query. The PARALLEL hint can then take two values separated by commas after the table name. The first value specifies the degree of parallelism for the given table, the second value specifies how the table is to be split among the instances of a parallel server. Specifying DEFAULT or no value signifies the query coordinator should examine the settings of the initialization parameters (described in a later section) to determine the default degree of parallelism.
NOPARALLEL / NO_PARALLEL
The NOPARALLEL hint allows you to disable parallel scanning of a table, even if the table was created with a PARALLEL clause. In Oracle 10g this hint was renamed to NO_PARALLEL.
PQ_DISTRIBUTE
The PQ_DISTRIBUTE hint improves the performance of parallel join operations. Do this by specifying how rows of joined tables should be distributed among producer and consumer query servers. Using this hint overrides decisions the optimizer would normally make.
NO_PARALLEL_INDEX
The NO_PARALLEL_INDEX hint overrides a PARALLEL attribute setting on an index to avoid a parallel index scan operation.
Additional Hints
APPEND
When the APPEND hint is used with the INSERT statement, data is appended to the table. Existing free space in the block is not used. If a table or an index is specified with nologging, this hint applied with an insert statement produces a direct path insert which reduces generation of redo.
NOAPPEND
Overrides the append mode.
CACHE
The CACHE hint specifies that the blocks retrieved for the table in the hint are placed at the most recently used end of the LRU list in the buffer cache when a full table scan is performed. This option is useful for small lookup tables. In the following example, the CACHE hint overrides the table default caching specification.
NOCACHE
The NOCACHE hint specifies that the blocks retrieved for this table are placed at the least recently used end of the LRU list in the buffer cache when a full table scan is performed. This is the normal behavior of blocks in the buffer cache.
PUSH_PRED
The PUSH_PRED hint forces pushing of a join predicate into the view.
NO_PUSH_PRED
The NO_PUSH_PRED hint prevents pushing of a join predicate into the view.
PUSH_SUBQ
The PUSH_SUBQ hint causes nonmerged subqueries to be evaluated at the earliest possible place in the execution plan.
NO_PUSH_SUBQ
The NO_PUSH_SUBQ hint causes non-merged subqueries to be evaluated as the last step in the execution plan.
QB_NAME
Specifies a name for a query block. (from Oracle 10g)
CURSOR_SHARING_EXACT
Oracle can replace literals in SQL statements with bind variables, if it is safe to do so. This is controlled with the CURSOR_SHARING startup parameter. The CURSOR_SHARING_EXACT hint causes this behavior to be switched off. In other words, Oracle executes the SQL statement without any attempt to replace literals by bind variables.
DRIVING_SITE
The DRIVING_SITE hint forces query execution to be done for the table at a different site than that selected by Oracle
DYNAMIC_SAMPLING
The DYNAMIC_SAMPLING hint lets you control dynamic sampling to improve server performance by determining more accurate predicate selectivity and statistics for tables and indexes. You can set the value of DYNAMIC_SAMPLING to a value from 0 to 10. The higher the level, the more effort the compiler puts into dynamic sampling and the more broadly it is applied. Sampling defaults to cursor level unless you specify a table.
SPREAD_MIN_ANALYSIS
This hint omits some of the compile time optimizations of the rules, mainly detailed dependency graph analysis, on spreadsheets. Some optimizations such as creating filters to selectively populate spreadsheet access structures and limited rule pruning are still used. (from Oracle 10g)
Hints with unknown status
MERGE_AJ
The MERGE_AJ hint transforms a NOT IN subquery into a merge anti-join to access the specified table. The syntax of the MERGE_AJ hint is MERGE_AJ(table) where table specifies the name or alias of the table to be accessed.(depricated in Oracle 10g)
AND_EQUAL
The AND_EQUAL hint explicitly chooses an execution plan that uses an access path that merges the scans on several single-column indexes. The syntax of the AND_EQUAL hint is AND_EQUAL(table index index) where table specifies the name or alias of the table associated with the indexes to be merged. and index specifies an index on which an index scan is to be performed. You must specify at least two indexes. You cannot specify more than five. (depricated in Oracle 10g)
STAR
The STAR hint forces the large table to be joined last using a nested loops join on the index. The optimizer will consider different permutations of the small tables. (depricated in Oracle 10g)
BITMAP
Usage: BITMAP(table_name index_name) Uses a bitmap index to access the table. (depricated ?)
HASH_SJ
Use a Hash Anti-Join to evaluate a NOT IN sub-query. Use this hint in the sub-query, not in the main query. Use this when your high volume NOT IN sub-query is using a FILTER or NESTED LOOPS join. Try MERGE_AJ if HASH_AJ refuses to work.(depricated in Oracle 10g)
NL_SJ
Use a Nested Loop in a sub-query. (depricated in Oracle 10g)
NL_AJ
Use an anti-join in a sub-query. (depricated in Oracle 10g)
SQL> select object_id,session_id from v$locked_object; //娉ㄦ剰session_id 灝辨槸涓婇攣鐨?session鏍囧織 SQL> select username,sid,SERIAL# from v$session where sid=銆傘? //榪欓噷鐨凷ID = session_id SQL> alter system kill session 'id,serial#'; //鏉姝昏session
鐜板湪 IT 寮鍙戜漢鍛樻瘮浠ュ線浠諱綍鏃跺欓兘鏇村姞鍏蟲敞嫻嬭瘯鐨勯噸瑕佹э紝娌℃湁緇忚繃鑹ソ嫻嬭瘯鐨勪唬鐮佹洿瀹規槗鍑洪棶棰樸傚湪鏋侀檺緙栫▼涓紝嫻嬭瘯椹卞姩寮鍙戝凡緇忚璇佹槑鏄竴縐嶆湁鏁堟彁楂樿蔣浠惰川閲忕殑鏂規硶銆傚湪嫻嬭瘯椹卞姩鐨勫紑鍙戞柟寮忎腑錛岃蔣浠跺伐紼嬪笀鍦ㄧ紪鍐欏姛鑳戒唬鐮佷箣鍓嶉鍏堢紪鍐欐祴璇曚唬鐮侊紝榪欐牱鑳戒粠鏈寮濮嬩繚璇佺▼搴忎唬鐮佺殑姝g‘鎬э紝騫朵笖鑳藉鍦ㄧ▼搴忕殑姣忔婕旇繘鏃惰繘琛岃嚜鍔ㄧ殑鍥炲綊嫻嬭瘯銆傛祴璇曞浜庤蔣浠朵駭鍝佺殑鎴愯觸璧風潃鑷沖叧閲嶈鐨勪綔鐢紝鍦ㄦ瀬闄愮紪紼嬮鍩燂紝鐢氳嚦鏈変漢鎻愯浠諱綍鏈粡嫻嬭瘯鐨勪唬鐮侀兘搴旇鑷姩浠庡彂甯冪殑浜у搧涓垹闄ゃ備綔鑰呭茍涓嶇‘淇¤繖涓鐐規槸姝g‘鐨勶紝浣嗘槸嫻嬭瘯鏈韓鐨勮川閲忕‘瀹炴槸涓涓渶瑕侀珮搴﹀叧娉ㄧ殑闂銆傛祴璇曠殑瑕嗙洊鐜囨槸嫻嬭瘯璐ㄩ噺鐨勪竴涓噸瑕佹寚鏍囷紝鎴戜滑闇瑕佸伐鍏鋒潵甯姪鎴戜滑榪涜瀵硅蔣浠舵祴璇曡鐩栫殑鑰冨療銆?/p>
EclEmma 灝辨槸榪欐牱涓涓兘甯姪寮鍙戜漢鍛樿冨療嫻嬭瘯瑕嗙洊鐜囩殑浼樼鐨?Eclipse 寮婧愭彃浠躲侲clEmma 鍦ㄨ鐩栨祴璇曢鍩熸槸濡傛鐨勪紭縐錛屼互鑷翠簬瀹冨湪榪囧幓涓嶄箙鐨?2006 騫存垚涓轟簡 Eclipse Community Awards Winners 鍐寵禌閫夋墜銆傝櫧鐒舵渶鍚?Eclipse Checkstyle Plugin 鍙栧緱浜?Best Open Source Eclipse-based Developer tool 鐨勭О鍙鳳紝浣嗘垜浠篃鍙互鐢辨鐪嬪埌 EclEmma 瀵瑰紑鍙戜漢鍛樼殑甯姪鏄法澶х殑錛圗clipse Community Award 鐨勫叿浣撲俊鎭彲浠ュ弬闃?鍙傝冭祫婧?/a>錛夈?/p>
棰勬彃鍏ユā寮忥細瀵圭▼搴忚繘琛屾祴閲忎箣鍓嶏紝闇瑕侀噰鐢?Emma 鎻愪緵鐨勫伐鍏峰 class 鏂囦歡鎴栬?jar 鏂囦歡榪涜淇敼銆備慨鏀瑰畬鎴愪箣鍚庣殑浠g爜鍙互绔嬪埢琚墽琛屻傝鐩栨祴璇曠殑緇撴灉灝嗕細琚瓨鏀懼埌鎸囧畾鐨勬枃浠朵腑銆?/li>
鍗蟲椂鎻掑叆妯″紡錛?/strong>鍗蟲椂鎻掑叆妯″紡涓嶉渶瑕佷簨鍏堝浠g爜榪涜淇敼銆傜浉鍙嶏紝瀵逛唬鐮佺殑淇敼鏄氳繃涓涓?Emma 瀹氬埗鐨?Class loader錛堢被杞藉叆鍣級榪涜鐨勩傝繖縐嶆柟寮忕殑浼樼偣寰堟槑鏄撅紝鎴戜滑涓嶉渶瑕佸 class 鎴栬?jar 鏂囦歡榪涜浠諱綍淇敼銆傜己鐐規槸鎴戜滑涓轟簡鑾峰緱嫻嬭瘯鐨勭粨鏋滐紝闇瑕佺敤 Emma 鎻愪緵鐨勫懡浠?emmarun 鏉ユ墽琛?Java 搴旂敤紼嬪簭銆?/li>
Exception in thread "main" org.codehaus.xfire.XFireRuntimeException: Could not invoke service.. Nested exception is org.codehaus.xfire.fault.XFireFault: 闈炴硶鐨勭敤鎴峰悕鍜屽瘑鐮?br />org.codehaus.xfire.fault.XFireFault: 闈炴硶鐨勭敤鎴峰悕鍜屽瘑鐮?br /> at org.codehaus.xfire.fault.Soap11FaultSerializer.readMessage(Soap11FaultSerializer.java:31) at org.codehaus.xfire.fault.SoapFaultSerializer.readMessage(SoapFaultSerializer.java:28) at org.codehaus.xfire.soap.handler.ReadHeadersHandler.checkForFault(ReadHeadersHandler.java:111) at org.codehaus.xfire.soap.handler.ReadHeadersHandler.invoke(ReadHeadersHandler.java:67) at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131) at org.codehaus.xfire.client.Client.onReceive(Client.java:406) at org.codehaus.xfire.transport.http.HttpChannel.sendViaClient(HttpChannel.java:139) at org.codehaus.xfire.transport.http.HttpChannel.send(HttpChannel.java:48) at org.codehaus.xfire.handler.OutMessageSender.invoke(OutMessageSender.java:26) at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131) at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:79) at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:114) at org.codehaus.xfire.client.Client.invoke(Client.java:336) at org.codehaus.xfire.client.XFireProxy.handleRequest(XFireProxy.java:77) at org.codehaus.xfire.client.XFireProxy.invoke(XFireProxy.java:57) at $Proxy0.getUser(Unknown Source) at test.ClientTest.main(ClientTest.java:39)
Exception in thread "main" org.codehaus.xfire.XFireRuntimeException: Could not invoke service.. Nested exception is org.codehaus.xfire.fault.XFireFault: 璇鋒眰蹇呴』鍖呭惈楠岃瘉淇℃伅 org.codehaus.xfire.fault.XFireFault: 璇鋒眰蹇呴』鍖呭惈楠岃瘉淇℃伅 at org.codehaus.xfire.fault.Soap11FaultSerializer.readMessage(Soap11FaultSerializer.java:31) at org.codehaus.xfire.fault.SoapFaultSerializer.readMessage(SoapFaultSerializer.java:28) at org.codehaus.xfire.soap.handler.ReadHeadersHandler.checkForFault(ReadHeadersHandler.java:111) at org.codehaus.xfire.soap.handler.ReadHeadersHandler.invoke(ReadHeadersHandler.java:67) at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131) at org.codehaus.xfire.client.Client.onReceive(Client.java:406) at org.codehaus.xfire.transport.http.HttpChannel.sendViaClient(HttpChannel.java:139) at org.codehaus.xfire.transport.http.HttpChannel.send(HttpChannel.java:48) at org.codehaus.xfire.handler.OutMessageSender.invoke(OutMessageSender.java:26) at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131) at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:79) at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:114) at org.codehaus.xfire.client.Client.invoke(Client.java:336) at org.codehaus.xfire.client.XFireProxy.handleRequest(XFireProxy.java:77) at org.codehaus.xfire.client.XFireProxy.invoke(XFireProxy.java:57) at $Proxy0.getUser(Unknown Source) at test.ClientTest.main(ClientTest.java:35)
涓鑸潵璇達紝鍦?/span>Oracle鏁版嵁搴撲腑錛屾垜浠tb琛ㄧ殑name瀛楁榪涜妯$硦鏌ヨ浼氶噰鐢ㄤ笅闈袱縐嶆柟寮忥細 1.select * from tb where name like '%XX%'; 2.select * from tb where instr(name,'XX')>0;