怎么解決數(shù)據(jù)庫ora-600異常

本篇內(nèi)容介紹了“怎么解決數(shù)據(jù)庫ora-600異常”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

一，問題描述

用戶反饋，執(zhí)行一段SQL時，出現(xiàn)ora-600的異常。

create or replace view grp_cust_ucs_v as

select distinct

       a.CUST_ID,

       a.CUST_NAME,

       b.service_id,

       b.list_system_id,

       a.CUST_ADDR,

       decode(a.CUST_TYPE,'01','大客','02','中小','03','公眾','04','校園','未知')CUST_TYPE,

       a.CARD_TYPE,

       a.CRAD_NO,

       a.EPARCHY_CODE,

       a.CITY_CODE,

       a.SCORE_VALUE,

       a.CREDIT_CLASS,

       a.BASIC_CREDIT_VALUE,

       a.CREDIT_VALUE,

       a.DEVELOP_DEPART_ID,

       f_develop_staff_tonumber(a.CUST_ID) DEVELOP_STAFF_ID,

       a.IN_DEPART_ID,

       a.IN_STAFF_ID,

       a.IN_DATE,

       a.REMOVE_FLAG,

       a.REMOVE_DATE,

       a.REMOVE_STAFF_ID,

       a.REMOVE_CHANGE,

       a.UPDATE_TIME,

       a.UPDATE_STAFF_ID,

       a.UPDATE_DEPART_ID,

       b.ACTIVE_TIME,

       b.active_man,

       case

            when b.cust_id is null then '10'

            when b.cust_id is not null then '11'

       end  as CUST_STATUS,

       b.if_valid,

       b.sync_status,

       b.inactive_time,

       b.inactive_man,

       a.new_cust_type,

       (select b2.SYSTEM_USER_NAME||'('||b2.SYSTEM_USER_CODE||')' from grp_distribute_cust_manager b1,v_system_user b2

        where b1.cust_id=a.cust_id and b1.status=10 and b1.manager_id=b2.SYSTEM_USER_ID)accept_man,

       (select b2.SYSTEM_USER_NAME||'('||b2.SYSTEM_USER_CODE||')' from grp_distribute_cust_manager b1,v_system_user b2

        where b1.cust_id=a.cust_id and b1.status=10 and b1.send_user=b2.SYSTEM_USER_ID)send_man,

       (select to_char(b1.send_date,'yyyy/mm/dd') from grp_distribute_cust_manager b1

        where b1.cust_id=a.cust_id and b1.status=10)send_date,

       (select b1.manager_id from grp_distribute_cust_manager b1

        where b1.cust_id=a.cust_id and b1.status=10)accept_man_id

  from GRP_BMS_CUST_INFO a,GRP_CUST_UCS_T b

 where a.cust_id = b.cust_id(+)

   and b.if_valid(+) = '10';

二、問題解決

這是oracle的一個bug，在10.2.0.5.4和以后版本已經(jīng)解決了，當(dāng)大表hash join關(guān)聯(lián)或者大表執(zhí)行hash group by就有可能出現(xiàn)上述的ora-600 [kcblasm_1], [103], [], [], [], [], [], []問題。

可以選擇規(guī)避掉hash join執(zhí)行計劃或者h(yuǎn)ash group by的執(zhí)行計劃來避開相應(yīng)sql引起的錯誤，我們可以在執(zhí)行這個sql語句之前：

alter session set “_hash_group_enabled”=false 禁掉hash join連接方式，或者sql語句里面使用hint no_use_hash。

alter session set “_gby_hash_aggregation_enabled”=falase 禁掉hash group by執(zhí)行路徑

Oralce給出的最快捷的方式是直接打patch到10.2.0.5.4或者以上版本，也可以選擇在linux和unix平臺打patch 7612454去解決這個問題，而windows下需要下載patch 3或者以上版本來解決這個問題。

在這里，我們選擇在sql語句里面使用hint no_use_hash，問題得到解決。

“怎么解決數(shù)據(jù)庫ora-600異?！钡膬?nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！