6

Oracle10gデータベースは最近11gにアップグレードされました。データベースはWindowsServer2003X64マシンで実行されています。TIMESTAMP（6）WITH TIME ZONEデータ列を持つテーブルにアクセスする.NETアプリケーションからのSQLクエリで、次の例外が発生します。

System.Data.OracleClient.OracleException：ORA-01805：日付/時刻操作でエラーが発生する可能性があります

例外に対して推奨されるアクションは、クライアントとサーバーが同じバージョンであることを確認することです。

ORA-01805：日付/時刻操作でエラーが発生する可能性があります原因：クライアントとサーバーのタイムゾーン・ファイルが一致していません。操作により、ローカルタイムゾーンファイルに基づいて誤った結果が生じる可能性があります。処置：クライアントとサーバーのタイムゾーンのバージョンが同じであることを確認してください。

次のクエリを実行して、問題のデータベースのタイムゾーンを確認しました。クライアントのタイムゾーンを設定する（またはタイムゾーンファイルを変更する）方法に関する情報が見つかりません。

SELECT dbtimezone FROM DUAL;
select * from v$timezone_file;

DBTIMEZONE 
---------- 
+00:00     

FILENAME             VERSION                
-------------------- ---------------------- 
timezlrg_14.dat      14

クライアントがインストールしたインスタントクライアント（バージョン11_2）を参照していると思いますか？System.Data.OracleClient.OracleConnection.NETFrameworkによって提供されるようにクエリを実行しています。UIは、「タイムゾーンバージョン」によって、タイムゾーンファイルのバージョンを参照していると想定します。インスタントクライアントにタイムゾーンファイルがある場所がわかりません。どんな提案も認められます。

4

4 に答える 4

4

インスタントクライアントのバージョン11_2_0_1がインストールされていると判断しました。11_2_0_2にアップグレードすると、この問題が軽減されたようです。ただし、インスタントクライアントがタイムゾーンファイルをどのように管理するか、またはそれがどこにあるか、またはそれが何であるかについては、まだはっきりしていません。私が読んだすべてのソースは、クライアントとサーバーが同じタイムゾーンファイルバージョンを持っていることを確認するように言っていますが、それが実際にクライアントでどのように行われるかは私にはわかりません。おそらく、別のバージョンのインスタントクライアントを使用する以外に直接維持できるものではないでしょうか。

于 2011-10-07T13:00:56.930 に答える
3

「genezi-v」を使用して、タイムゾーンファイルのバージョンを確認します。

これが私のLinuxボックスのサンプルです：

$ genezi -v
Client Shared Library 32-bit - 11.2.0.2.0

System name:    Linux
Release:    2.6.32-34-generic
Version:    #77-Ubuntu SMP Tue Sep 13 19:39:17 UTC 2011
Machine:    x86_64

Operating in Instant Client mode.
Small timezone file = timezone_14.dat
Large timezone file = timezlrg_14.dat
于 2011-10-08T16:10:42.707 に答える
1

他の理由に加えて、タイムゾーン変換を実行し、データベースよりもはるかに高いバージョンのcx-Oracleライブラリを使用している場合、python3.6を使用しても問題が発生します。

「マヌエル・ピノ」からのコメントを説明しています。彼がTZ変換ラインにコメントするとすぐに、それは機能します。

最新のcx-Oracle8.1.0を使用したPython3.6でも同じ問題が発生しましたが、古いデータベース12.1に接続していました。

  • 使用されたPython：python3.6
  • 最新のcxをインストール-Oracleバージョン8.1.0（通常は18-19.x前後のリリース用）
  • 接続されたデータベース：12.1.0.2
  • Oracleインスタントクライアント12.2

タイムゾーン変換なしでクエリを呼び出すと、正常に機能します。

sql='''select cast (sysdate AS TIMESTAMP WITH TIME ZONE) from dual'''
cur.execute(sql)
cur.fetchone()
(datetime.datetime(2020, 12, 28, 17, 7, 52),)

タイムゾーン変換を使用して同様のクエリを呼び出すと失敗します。

sql='''select cast (sysdate AS TIMESTAMP WITH TIME ZONE) AT TIME ZONE 'UTC' from dual'''
cur.execute(sql)
cur.fetchone()
*** cx_Oracle.DatabaseError: ORA-01805: possible error in date/time operation

私の場合の解決策：古いcx-Oracleクライアントにダウングレードします（Oracle-インスタントクライアント12.2は変更されません）

pip install -U cx-Oracle==6.4.1
Collecting cx-Oracle==6.4.1
  Using cached cx_Oracle-6.4.1-cp36-cp36m-manylinux1_x86_64.whl (596 kB)
    Installing collected packages: cx-Oracle
  Attempting uninstall: cx-Oracle
    Found existing installation: cx-Oracle 8.1.0
    Uninstalling cx-Oracle-8.1.0:
      Successfully uninstalled cx-Oracle-8.1.0
Successfully installed cx-Oracle-6.4.1

タイムゾーン変換を使用して再度テストします。

sql='''select cast (sysdate AS TIMESTAMP WITH TIME ZONE) AT TIME ZONE 'UTC' from dual'''
cur.execute(sql)
cur.fetchone()
(datetime.datetime(2020, 12, 28, 17, 20, 54),)
于 2020-12-28T16:22:03.237 に答える
0

Dockerを使用するOracle11GのORA-01505でも同じ問題が発生します

ActiveRecord::StatementInvalid (OCIError: ORA-01805: possible error in date/time operation: SELECT  "USERS".* FROM "USERS" WHERE "USERS"."EMAIL" = :a1 ORDER BY "USERS"."ID" ASC FETCH FIRST :a2 ROWS ONLY):

docker-compose.ymlで使用していました

    environment:
      - TZ=America/Guatemala

したがって、行にコメントするだけで、すべてが機能します

      environment:
      #- TZ=America/Guatemala
于 2019-08-01T19:43:33.983 に答える