Элемент управления не возвращается к UNIX, когда sqlplus выполняется в то время как l oop сценария оболочки - PullRequest
Новая
       9

Элемент управления не возвращается к UNIX, когда sqlplus выполняется в то время как l oop сценария оболочки

0 голосов
/ 14 апреля 2020

Я заметил, что некоторые сценарии оболочки зависли, потому что сеанс sqlplus не завершил свой сеанс. Такое поведение прерывисто. Я приведу один из сценариев. Ниже приведен код, который выполняет один запрос sql. 

 if [[ ${rcloop1} -eq 0 ]]; then
      sql_cnt_loop=0      
      # perform 2nd loop after 1 second to check if Indexing has completed
      sleep 1
      while : ; do
         exec_SQL "SELECT count(*)    \
                     FROM server_states  \
                    WHERE topic = 'WLM_FPFA_INDEXES'  \
                      AND current_state <> new_state \
                      AND server_name in ('${E_WLM_BATCH_SERVER_NAME_1}', '${E_WLM_BATCH_SERVER_NAME_2}')"
         rcloop2=$?

         if [[ $rcloop2 -eq 0 ]]; then
            sql_cnt_loop=$sql_cnt_loop+1
            if [[ ${E_WLM_SQL_RESULT} -eq 0 ]]; then
               Log "DJ Indexing has Completed..."
               rcloop2=0 # no rows - indexing has completed (not found in server_states table), return RC=0
               break     # exit from 2nd loop
            elif [[ ${E_WLM_SQL_RESULT} -gt 0 ]]; then
               sleep 1 # wait 1 sec then loop again
               continue  # record exists, continue monitoring indexing - loop again
            fi

         fi
      done

      rc=$rcloop2

   else
      rc=$rcloop1
   fi

ниже - сеанс unix. pwlm 8297 8290 0 00:16? 00:00:03 / bin / k sh -a / opt / XWLMLL02 pwlm 29121 8297 0 00:32? 00:00:00 sqlplus -s

Сценарий запустил процесс внутренне, а над частью кода является контроль завершения процесса. Несмотря на то, что процесс завершен, сценарий не продвинулся дальше с этой точки. После проверки я увидел один активный сеанс sqlplus. Я подозреваю, что сеанс sqlplus происходит из приведенного выше кода, и он каким-то образом застрял, в свою очередь, скрипт застрял.

Ниже приведена актуальная функция exec_ SQL. 

exec_SQL()
{
   sql_Stmt=$1

   sql_Type=`echo $sql_Stmt | awk -F " " '{ printf toupper($1) }'`

   E_WLM_SQL_RESULT=`sqlplus -s /@${E_WLM_DB} <<!
      set pagesize 0 feedback off verify off heading off echo on
      whenever SQLERROR exit SQL.SQLCODE
      whenever OSERROR exit 9
      $sql_Stmt;
      commit;
   !`

   sql_RC=$?

   if [[ $sql_RC -eq 0 ]]; then

      str_Result=`echo $E_WLM_SQL_RESULT | grep SP2`  

      if [[ ${#str_Result} > 0 ]]; then
         sql_RC=57      # SQL Error
         sql_Code=0 
      else
         export E_WLM_SQL_RESULT
      fi
   else
      sql_Code=$sql_RC   # Store SQL.SQLCODE before overwriting

      if [[ $sql_RC -eq 9 ]]; then   # OSERROR
         sql_RC=91     
      else
         case $sql_Type in 
            INSERT) sql_RC=52 ;;
            UPDATE) sql_RC=53 ;;
            SELECT) sql_RC=54 ;;
            DELETE) sql_RC=56 ;;
            *) sql_RC=57 ;;
         esac
      fi
   fi

   if [[ $sql_RC -ne 0 ]]; then
      Log "Error in executing SQL Statement: $sql_Stmt "
      Log "SQL.SQLCODE=$sql_Code"
      Log "=====================================   ORACLE ERROR DESCRIPTION  ====================================="  
      Log "$E_WLM_SQL_RESULT"
      Log "======================================================================================================="
      Log "Returning with $sql_RC"

   fi

   return $sql_RC 
}

У меня есть наблюдал эту похожую проблему 3 раза до сих пор за последние 7 дней. Но это для разных скриптов. Логика c остается прежней.

Этот скрипт прекрасно работал в нашей старой инфраструктуре, где был сервер AIX. Мы вообще не сталкивались с этой проблемой.

Кто-нибудь может помочь мне решить проблему?

Заранее спасибо.

...