TRACE DBLINK
On my DB:
I have a running process from a dblink (remote DB)
ORIGIN GTXID LSESSION USERNAME S WAITING
plm0126mx-511 PROD202.8c93f109.3.19.222478 553.35086 RSEGA A direct path read
plm0126mx-29296 PROD202.8c93f109.7.29.180228 695.13691 RSEGA A direct path read
I need to identify the source process "A direct path read"
Regards,
How do I ask a question on the forums?
SQL and PL/SQL FAQ
Similar Messages
-
Trace queries from abap to a custom oracle database via dblink
I' m
connecting to a database by dblink (name magiap).
I
would like to know if somewhere I can trace all the queries from abap to oracle
in this specific session , to dbs ='MAGIAP'.
For istance, i would like that the query
"SELECT "DESPARTY1"
into :v_DESPARTY1
FROM "T040PARTY"
WHERE "CODPARTY" = '305142941' will
be stored some where (in a file??).
I would like that parameters - w_CODPARTY- will be substituted and stored in the trace
file with the value (305142941), as shown in the previous
Here
is the piece of code ..(a very short example of course)..
DATA : dbs LIKE dbcon-con_name,
v_CODPARTY(15),
v_DESPARTY1(60).
data : w_CODPARTY(15) value '305142941'.
dbs = 'MAGIAP'.
TRY.
EXEC SQL.
CONNECT TO :dbs
ENDEXEC.
IF sy-subrc <> 0.
EXEC SQL.
CONNECT TO :dbs
ENDEXEC.
ENDIF.
IF sy-subrc <> 0.
* RAISE err_conn_aea.
ENDIF.
EXEC SQL.
set connection :dbs
ENDEXEC.
EXEC SQL .
SELECT "DESPARTY1"
into :v_DESPARTY1
FROM "T040PARTY"
WHERE "CODPARTY" =
:w_CODPARTY
ENDEXEC.
IF sy-subrc NE 0.
* rc = 4.
ENDIF.
EXEC SQL.
DISCONNECT :dbs
ENDEXEC.
ENDTRY.Hi Silvana,
The SQL statements have been stored in the SQL Cursor Cache, on the database and they will be available until they have been invalidated. You can access the statements at the 'MAGIAP' side and see the last executed queries in the cache.
You can access bind variables by query on the V$SQL_BIND_CAPTURE table, also.
On the other hand, you can activate the trace by the statement, below;
ALTER SYSTEM SET sql_trace = true SCOPE=MEMORY;
Then, the sql statements will be available in the usertrace file. Please note that you should execute and investigate all the statements that I noted above, at the remote side. Plus, as far as I know that it is not able to distinguish the records by the "dblink name". You should check all the statements and try to figure out what queries have been executed remotely.
Best regards,
Orkun Gedik -
Trace in coming dblink connections
Is there any way to trace the incoming dblink requests?
We have audit_trail=xml
Is there a way to prevent requests through dblinks? Should open_links=0 could achieve it?
Thanks
Raviuser631415 wrote:
Is there any way to trace the incoming dblink requests?
We have audit_trail=xml
Is there a way to prevent requests through dblinks? Should open_links=0 could achieve it?
Thanks
RaviFrom the Reference Manual:
"OPEN_LINKS specifies the maximum number of concurrent open connections <i>to remote databases</i> ..."
As for requests <i>from</i> a db link that is defined in another db ... as far as the database that is the target of the dblink, it is just another client connection. -
Lock-ups while inserting to a remote database using a dblink
Our application runs across multiple instances of Oracle 8i - 8.1.6.
Throughout the day we run some batch processes to transfer data across these instances using dblinks. Ocassionally the process locks up and further investigation shows that the server from which we are pushing information out seems to have executed an insert statement on a remote instance (insert into test_table@tst_dblink select * from local_table) and is waiting for a return from the remote server while the remote instance seems to be hanging too. Oracle does not return any error but simply waits forever for the statement to finish.
If anybody has experienced this before can you please share any information you may have on 1. how to prevent this from happening or 2. How to make oracle give up on the transaction, roll it back and raise an error?
Thanks a lot....Well, certainly we need more info to fix the problem! couple of "system states" on both the machines when the job is hanging would help. couple of "stack trace" of the shadow process will also help. please call local oracle support with the system state and stack trace.
Sounds like the job is hanging on some resource (lock,enque,latch,io...). oracle doesn't give up for few resources, like waiting on ST,latch, io etc. we have to kill the offending process if we want!!
just my 2 cents :)
G -
Hello, I have 2 instances, into production environment, instance A and instance B. Into instance A I have a dblink to instance B...
The problem appear when I want to see the indexes of a table of instance B from instance A, to do this I press F4 into TOAD over:
owner.table@dblink
and when I click into tab "Indexes", Oracle said me: "The table does not exist", I review the grants, and this is ok, and the table exist in instance B.
One explanation, I have the same environment into testing, and there work perfectly, I have the same dblinks, the same users and the same grants.
Any suggestion to help me.You may want to contact the folks that make TOAD.
My guess is that TOAD is querying the local USER_/ ALL_/ DBA_INDEXES table rather than the USER_/ ALL/ DBA_INDEXES table at the remote server. You could run a client-side SQL trace to see what SQL is being generated to see if the problem is that TOAD is generating the incorrect SQL or whether there is some problem with the database. But I'm not sure how productive that would be since it's not like you could fix the SQL TOAD is submitting. If there is an option in TOAD that changes the behavior here, it's certainly possible that someone here will know it. But TOAD support is probably more likely.
Justin -
DBLINK truncation with SAP HANA db
Hi - I have Oracle 11g installed in my Windows laptop and dblink connected to SAP's HANA database via ODBC using the HANA odbc driver. My NVARCHAR data in HANA is being truncated in half. I am working thru sqlplus. Same result in SQL developer client tool. The VARCHAR data is ok. I created three Oracle instances with the only difference being the NLS_CHARACTERSET & NLS_NCHAR_CHARACTERSET values. I have three SIDS: orcl, orulu, and orclutf8. All with the same result. My gateway settings for each are all the same. I started testing with SID orcl and once I found that out I decided to create orclu and orclutf8. In our Unix boxes, we have orcl and orclu settings and those are behaving the same (we use unixodbc.org as the mgr).
I provided orclutf8 gateway .ora file and the orclut8 system info below.
Symptoms/Info:
The character set of HANA db is AL32UTF8.
The HANA db table contains NVARCHAR and have Unicode values (eg: em dash, even Chinese char). NVARCHAR columns gets cut in half as shown in sqlplus (same in sql developer).
For the half that do show up, the actual Unicode character shows up in sqlplus as either unprintable character or upside down question mark or a \u character. This is ok coz no abends therefore data gets process and let my customers deal with the non-converted data – it is ok with them.
Since all SIDs are behaving the same way, I provided you information for orclutf8: initdwutf.ora, the system info, and the trace file. Of all things that SHOULD work, it is the one with the exact character set to HANA.
I have two tables in HANA with the same number of columns and rows. Only difference is NVARCHAR versus VARCHAR.There are three columns with 3, 20, and 150 length.
I took a Oracle trace when selecting from each table and compared them both. I pasted a picture at the bottom. The left side is the VARCHAR and right side NVARCHAR. You can see the HANA odbc driver report a truncation issue on line 209 but I do not see this error in sqlplus. I have a SAP incident open on this.
Is there something in the Oracle side that can be tried? For example, in the trace compare picture, the VARCHAR trace shows that is doubled the data size for each column from 3, 20, and 150 to 6, 40, and 300. In the NVARCHAR it did not.
SID: orcl
SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET’;
WE8MSWIN1252
SELECT value$ FROM sys.props$ WHERE name = 'NLS_NCHAR_CHARACTERSET’;
AL16UTF16
SID: orclu
SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET’;
AL32UTF8
SELECT value$ FROM sys.props$ WHERE name = 'NLS_NCHAR_CHARACTERSET’;
AL16UTF16
SID: orclutf8
SELECT value$ FROM sys.props$ WHERE name = 'NLS_CHARACTERSET’;
AL32UTF8
SELECT value$ FROM sys.props$ WHERE name = 'NLS_NCHAR_CHARACTERSET’;
UTF8
initdw7utf.ora:
# This is a sample agent init file that contains the HS parameters that are
# needed for the Database Gateway for ODBC
# HS init parameters
#HS_FDS_CONNECT_INFO = <odbc data_source_name>
HS_FDS_CONNECT_INFO = HANADW7
HS_FDS_TRACE_LEVEL=DEBUG
#HS_LANGUAGE=AL32UTF8
HS_LANGUAGE=AMERICAN_AMERICA.AL32UTF8
HS_FDS_REMOTE_DB_CHARSET=AL32UTF8
# Environment variables required for the non-Oracle system
#set <envvar>=<value>
SELECT * FROM sys.props$:
DICT.BASE 2
DEFAULT_TEMP_TABLESPACE TEMP
DEFAULT_PERMANENT_TABLESPACE USERS
DEFAULT_EDITION ORA$BASE
Flashback Timestamp TimeZone GMT
TDE_MASTER_KEY_ID
DST_UPGRADE_STATE NONE
DST_PRIMARY_TT_VERSION 11
DST_SECONDARY_TT_VERSION 0
DEFAULT_TBS_TYPE SMALLFILE
NLS_LANGUAGE AMERICAN
NLS_TERRITORY AMERICA
NLS_CURRENCY $
NLS_ISO_CURRENCY AMERICA
NLS_NUMERIC_CHARACTERS .,
NLS_CHARACTERSET AL32UTF8
NLS_CALENDAR GREGORIAN
NLS_DATE_FORMAT DD-MON-RR
NLS_DATE_LANGUAGE AMERICAN
NLS_SORT BINARY
NLS_TIME_FORMAT HH.MI.SSXFF AM
NLS_TIMESTAMP_FORMAT DD-MON-RR HH.MI.SSXFF AM
NLS_TIME_TZ_FORMAT HH.MI.SSXFF AM TZR
NLS_TIMESTAMP_TZ_FORMAT DD-MON-RR HH.MI.SSXFF AM TZR
NLS_DUAL_CURRENCY $
NLS_COMP BINARY
NLS_LENGTH_SEMANTICS BYTE
NLS_NCHAR_CONV_EXCP FALSE
NLS_NCHAR_CHARACTERSET UTF8
NLS_RDBMS_VERSION 11.2.0.1.0
GLOBAL_DB_NAME ORCLUTF8
EXPORT_VIEWS_VERSION 8
WORKLOAD_CAPTURE_MODE
WORKLOAD_REPLAY_MODE
NO_USERID_VERIFIER_SALT 57505D68AFECC3BCECE484A1C42CC8CE
DBTIMEZONE 00:001) When I tried HS_KEEP_REMOTE_COLUMN_SIZE=LOCAL the nvarchar select statement still truncated and displayed them in sqlplus.
For the varchar select statement, it just error'ed out in sqlplus.
ERROR:
ORA-28562: Heterogeneous Services data truncation error
ORA-02063: preceding line from DEVUTF8
no rows selected
I commented out the HS_KEEP_REMOTE_COLUMN_SIZE=LOCAL for now.
2) For the nvarchar select statement, I do not get an error messages via sqlplus. I get the records displayed truncated in half they should be. A native odbc error do show up in the Oracle Trace file. I think that comes from the HANA odbc driver. It is line 209 of the picture in my original thread.
3) DESCRIBE commands output below:
SQL> desc ESBA_DB.ZTESTSAP@DEVUTF8 - THIS IS THE NVARCHAR TABLE. The sizes match what is in HANA db.
Name Null? Type
MANDT NOT NULL NVARCHAR2(3)
NAME NOT NULL NVARCHAR2(20)
NAME_150 NOT NULL NVARCHAR2(150)
SQL> desc PTAN.ZTESTSAP_VC@DEVUTF8 - THIS IS THE VARCHAR TABLE.The sizes do not match what is in HANA db.
Name Null? Type
MANDT VARCHAR2(1)
NAME VARCHAR2(6)
NAME150 VARCHAR2(50)
4) Below is the gateway trace. I included from the first occurence of hgodscr and all the way to the end of it. You can see the HANA odbc driver truncation.
Entered hgodscr, cursor id 1 at 2014/10/02-11:15:41
Allocate hoada @ 03705518
Entered hgopcda at 2014/10/02-11:15:41
Column:1(M): dtype:-9 (WVARCHAR), prc/scl:3/0, nullbl:1, octet:3, sign:1, radix:0
Exiting hgopcda, rc=0 at 2014/10/02-11:15:41
Entered hgopcda at 2014/10/02-11:15:41
Column:2(N): dtype:-9 (WVARCHAR), prc/scl:20/0, nullbl:1, octet:20, sign:1, radix:0
Exiting hgopcda, rc=0 at 2014/10/02-11:15:41
Entered hgopcda at 2014/10/02-11:15:41
Column:3(N): dtype:-9 (WVARCHAR), prc/scl:150/0, nullbl:1, octet:150, sign:1, radix:0
Exiting hgopcda, rc=0 at 2014/10/02-11:15:41
hgodscr, line 910: Printing hoada @ 03705518
MAX:3, ACTUAL:3, BRC:100, WHT=5 (SELECT_LIST)
hoadaMOD bit-values found (0x40:TREAT_AS_NCHAR)
DTY NULL-OK LEN MAXBUFLEN PR/SC CST IND MOD NAME
12 VARCHAR Y 3 3 128/ 3 1000 0 40 MANDT
12 VARCHAR Y 20 20 128/ 20 1000 0 40 NAME
12 VARCHAR Y 150 150 128/150 1000 0 40 NAME_150
Exiting hgodscr, rc=0 at 2014/10/02-11:15:41
Entered hgoftch, cursor id 1 at 2014/10/02-11:15:41
hgoftch, line 130: Printing hoada @ 03705518
MAX:3, ACTUAL:3, BRC:100, WHT=5 (SELECT_LIST)
hoadaMOD bit-values found (0x40:TREAT_AS_NCHAR)
DTY NULL-OK LEN MAXBUFLEN PR/SC CST IND MOD NAME
12 VARCHAR Y 3 3 128/ 3 1000 0 40 MANDT
12 VARCHAR Y 20 20 128/ 20 1000 0 40 NAME
12 VARCHAR Y 150 150 128/150 1000 0 40 NAME_150
Performing delayed open.
SQLBindCol: column 1, cdatatype: -8, bflsz: 6
SQLBindCol: column 2, cdatatype: -8, bflsz: 22
SQLBindCol: column 3, cdatatype: -8, bflsz: 152
Entered hgopoer at 2014/10/02-11:15:41
hgopoer, line 233: got native error 0 and sqlstate 01004; message follows...
[SAP AG][LIBODBCHDB32 DLL] Data truncated {01004}[SAP AG][LIBODBCHDB32 DLL] Data truncated {01004}[SAP AG][LIBODBCHDB32 DLL] Data truncated {01004}[SAP AG][LIBODBCHDB32 DLL] Data truncated {01004}[SAP AG][LIBODBCHDB32 DLL] Data truncated {01004}
Exiting hgopoer, rc=0 at 2014/10/02-11:15:41
hgoftch, line 740: calling SQLFetch got sqlstate 01004
SQLFetch: row: 1, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 1, column 1, bflsz: 6, bflar: 6, (bfl: 3, mbl: 3)
SQLFetch: row: 1, column 2, bflsz: 22, bflar: 6
SQLFetch: row: 1, column 2, bflsz: 22, bflar: 6, (bfl: 20, mbl: 20)
SQLFetch: row: 1, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 1, column 3, bflsz: 152, bflar: 0, (bfl: 150, mbl: 150)
SQLFetch: row: 2, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 2, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 2, column 2, bflsz: 22, bflar: 12
SQLFetch: row: 2, column 2, bflsz: 22, bflar: 12, (bfl: 0, mbl: 20)
SQLFetch: row: 2, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 2, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 3, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 3, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 3, column 2, bflsz: 22, bflar: 8
SQLFetch: row: 3, column 2, bflsz: 22, bflar: 8, (bfl: 0, mbl: 20)
SQLFetch: row: 3, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 3, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 4, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 4, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 4, column 2, bflsz: 22, bflar: 6
SQLFetch: row: 4, column 2, bflsz: 22, bflar: 6, (bfl: 0, mbl: 20)
SQLFetch: row: 4, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 4, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 5, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 5, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 5, column 2, bflsz: 22, bflar: 12
SQLFetch: row: 5, column 2, bflsz: 22, bflar: 12, (bfl: 0, mbl: 20)
SQLFetch: row: 5, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 5, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 6, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 6, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 6, column 2, bflsz: 22, bflar: 8
SQLFetch: row: 6, column 2, bflsz: 22, bflar: 8, (bfl: 0, mbl: 20)
SQLFetch: row: 6, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 6, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 7, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 7, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 7, column 2, bflsz: 22, bflar: 6
SQLFetch: row: 7, column 2, bflsz: 22, bflar: 6, (bfl: 0, mbl: 20)
SQLFetch: row: 7, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 7, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 8, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 8, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 8, column 2, bflsz: 22, bflar: 12
SQLFetch: row: 8, column 2, bflsz: 22, bflar: 12, (bfl: 0, mbl: 20)
SQLFetch: row: 8, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 8, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 9, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 9, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 9, column 2, bflsz: 22, bflar: 8
SQLFetch: row: 9, column 2, bflsz: 22, bflar: 8, (bfl: 0, mbl: 20)
SQLFetch: row: 9, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 9, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 10, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 10, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 10, column 2, bflsz: 22, bflar: 6
SQLFetch: row: 10, column 2, bflsz: 22, bflar: 6, (bfl: 0, mbl: 20)
SQLFetch: row: 10, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 10, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 11, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 11, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 11, column 2, bflsz: 22, bflar: 12
SQLFetch: row: 11, column 2, bflsz: 22, bflar: 12, (bfl: 0, mbl: 20)
SQLFetch: row: 11, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 11, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 12, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 12, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 12, column 2, bflsz: 22, bflar: 8
SQLFetch: row: 12, column 2, bflsz: 22, bflar: 8, (bfl: 0, mbl: 20)
SQLFetch: row: 12, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 12, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 13, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 13, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 13, column 2, bflsz: 22, bflar: 6
SQLFetch: row: 13, column 2, bflsz: 22, bflar: 6, (bfl: 0, mbl: 20)
SQLFetch: row: 13, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 13, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 14, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 14, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 14, column 2, bflsz: 22, bflar: 12
SQLFetch: row: 14, column 2, bflsz: 22, bflar: 12, (bfl: 0, mbl: 20)
SQLFetch: row: 14, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 14, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 15, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 15, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 15, column 2, bflsz: 22, bflar: 40
SQLFetch: row: 15, column 2, bflsz: 22, bflar: 40, (bfl: 0, mbl: 20)
SQLFetch: row: 15, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 15, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 16, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 16, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 16, column 2, bflsz: 22, bflar: 8
SQLFetch: row: 16, column 2, bflsz: 22, bflar: 8, (bfl: 0, mbl: 20)
SQLFetch: row: 16, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 16, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 17, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 17, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 17, column 2, bflsz: 22, bflar: 32
SQLFetch: row: 17, column 2, bflsz: 22, bflar: 32, (bfl: 0, mbl: 20)
SQLFetch: row: 17, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 17, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 18, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 18, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 18, column 2, bflsz: 22, bflar: 40
SQLFetch: row: 18, column 2, bflsz: 22, bflar: 40, (bfl: 0, mbl: 20)
SQLFetch: row: 18, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 18, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 19, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 19, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 19, column 2, bflsz: 22, bflar: 12
SQLFetch: row: 19, column 2, bflsz: 22, bflar: 12, (bfl: 0, mbl: 20)
SQLFetch: row: 19, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 19, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 20, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 20, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 20, column 2, bflsz: 22, bflar: 2
SQLFetch: row: 20, column 2, bflsz: 22, bflar: 2, (bfl: 0, mbl: 20)
SQLFetch: row: 20, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 20, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 21, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 21, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 21, column 2, bflsz: 22, bflar: 2
SQLFetch: row: 21, column 2, bflsz: 22, bflar: 2, (bfl: 0, mbl: 20)
SQLFetch: row: 21, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 21, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 22, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 22, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 22, column 2, bflsz: 22, bflar: 6
SQLFetch: row: 22, column 2, bflsz: 22, bflar: 6, (bfl: 0, mbl: 20)
SQLFetch: row: 22, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 22, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 23, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 23, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 23, column 2, bflsz: 22, bflar: 12
SQLFetch: row: 23, column 2, bflsz: 22, bflar: 12, (bfl: 0, mbl: 20)
SQLFetch: row: 23, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 23, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 24, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 24, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 24, column 2, bflsz: 22, bflar: 40
SQLFetch: row: 24, column 2, bflsz: 22, bflar: 40, (bfl: 0, mbl: 20)
SQLFetch: row: 24, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 24, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 25, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 25, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 25, column 2, bflsz: 22, bflar: 8
SQLFetch: row: 25, column 2, bflsz: 22, bflar: 8, (bfl: 0, mbl: 20)
SQLFetch: row: 25, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 25, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 26, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 26, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 26, column 2, bflsz: 22, bflar: 32
SQLFetch: row: 26, column 2, bflsz: 22, bflar: 32, (bfl: 0, mbl: 20)
SQLFetch: row: 26, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 26, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 27, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 27, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 27, column 2, bflsz: 22, bflar: 40
SQLFetch: row: 27, column 2, bflsz: 22, bflar: 40, (bfl: 0, mbl: 20)
SQLFetch: row: 27, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 27, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 28, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 28, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 28, column 2, bflsz: 22, bflar: 12
SQLFetch: row: 28, column 2, bflsz: 22, bflar: 12, (bfl: 0, mbl: 20)
SQLFetch: row: 28, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 28, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 29, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 29, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 29, column 2, bflsz: 22, bflar: 2
SQLFetch: row: 29, column 2, bflsz: 22, bflar: 2, (bfl: 0, mbl: 20)
SQLFetch: row: 29, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 29, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 30, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 30, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 30, column 2, bflsz: 22, bflar: 2
SQLFetch: row: 30, column 2, bflsz: 22, bflar: 2, (bfl: 0, mbl: 20)
SQLFetch: row: 30, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 30, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 31, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 31, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 31, column 2, bflsz: 22, bflar: 6
SQLFetch: row: 31, column 2, bflsz: 22, bflar: 6, (bfl: 0, mbl: 20)
SQLFetch: row: 31, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 31, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 32, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 32, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 32, column 2, bflsz: 22, bflar: 12
SQLFetch: row: 32, column 2, bflsz: 22, bflar: 12, (bfl: 0, mbl: 20)
SQLFetch: row: 32, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 32, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 33, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 33, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 33, column 2, bflsz: 22, bflar: 8
SQLFetch: row: 33, column 2, bflsz: 22, bflar: 8, (bfl: 0, mbl: 20)
SQLFetch: row: 33, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 33, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 34, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 34, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 34, column 2, bflsz: 22, bflar: 6
SQLFetch: row: 34, column 2, bflsz: 22, bflar: 6, (bfl: 0, mbl: 20)
SQLFetch: row: 34, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 34, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 35, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 35, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 35, column 2, bflsz: 22, bflar: 12
SQLFetch: row: 35, column 2, bflsz: 22, bflar: 12, (bfl: 0, mbl: 20)
SQLFetch: row: 35, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 35, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 36, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 36, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 36, column 2, bflsz: 22, bflar: 8
SQLFetch: row: 36, column 2, bflsz: 22, bflar: 8, (bfl: 0, mbl: 20)
SQLFetch: row: 36, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 36, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 37, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 37, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 37, column 2, bflsz: 22, bflar: 6
SQLFetch: row: 37, column 2, bflsz: 22, bflar: 6, (bfl: 0, mbl: 20)
SQLFetch: row: 37, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 37, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 38, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 38, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 38, column 2, bflsz: 22, bflar: 12
SQLFetch: row: 38, column 2, bflsz: 22, bflar: 12, (bfl: 0, mbl: 20)
SQLFetch: row: 38, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 38, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 39, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 39, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 39, column 2, bflsz: 22, bflar: 8
SQLFetch: row: 39, column 2, bflsz: 22, bflar: 8, (bfl: 0, mbl: 20)
SQLFetch: row: 39, column 3, bflsz: 152, bflar: 0
SQLFetch: row: 39, column 3, bflsz: 152, bflar: 0, (bfl: 0, mbl: 150)
SQLFetch: row: 40, column 1, bflsz: 6, bflar: 6
SQLFetch: row: 40, column 1, bflsz: 6, bflar: 6, (bfl: 0, mbl: 3)
SQLFetch: row: 40, column 2, bflsz: 22, bflar: 38
SQLFetch: row: 40, column 2, bflsz: 22, bflar: 38, (bfl: 0, mbl: 20)
SQLFetch: row: 40, column 3, bflsz: 152, bflar: 298
SQLFetch: row: 40, column 3, bflsz: 152, bflar: 298, (bfl: 0, mbl: 150)
40 rows fetched
Exiting hgoftch, rc=0 at 2014/10/02-11:15:42 with error ptr FILE:hgoftch.c LINE:740 ID:Fetch resultset data
Entered hgoftch, cursor id 1 at 2014/10/02-11:15:42
hgoftch, line 130: Printing hoada @ 03705518
MAX:3, ACTUAL:3, BRC:40, WHT=5 (SELECT_LIST)
hoadaMOD bit-values found (0x40:TREAT_AS_NCHAR)
DTY NULL-OK LEN MAXBUFLEN PR/SC CST IND MOD NAME
12 VARCHAR Y 4 3 128/ 3 1000 0 40 MANDT
12 VARCHAR Y 6 20 128/ 20 1000 0 40 NAME
12 VARCHAR Y 0 150 128/150 1000 0 40 NAME_150
0 rows fetched
Exiting hgoftch, rc=1403 at 2014/10/02-11:15:42
Entered hgoclse, cursor id 1 at 2014/10/02-11:15:46
Exiting hgoclse, rc=0 at 2014/10/02-11:15:46
Entered hgodafr, cursor id 1 at 2014/10/02-11:15:46
Free hoada @ 03705518
Exiting hgodafr, rc=0 at 2014/10/02-11:15:46
Entered hgocomm at 2014/10/02-11:15:46
keepinfo:0, tflag:1
00: 4F52434C 55544638 2E376265 35343664 [ORCLUTF8.7be546d]
10: 392E312E 32362E36 3630 [9.1.26.660]
tbid (len 23) is ...
00: 4F52434C 55544638 5B312E32 362E3636 [ORCLUTF8[1.26.66]
10: 305D5B31 2E345D [0][1.4]]
cmt(0):
Entered hgocpctx at 2014/10/02-11:15:46
Exiting hgocpctx, rc=0 at 2014/10/02-11:15:46
Exiting hgocomm, rc=0 at 2014/10/02-11:15:46
Entered hgolgof at 2014/10/02-11:15:46
tflag:1
Exiting hgolgof, rc=0 at 2014/10/02-11:15:46
Entered hgoexit at 2014/10/02-11:15:46
Exiting hgoexit, rc=0 -
Query from oracle to MySql using dblink fetch all the rows in MySql table
Hello,
I am using Heterogeneous connectivity between oracle 10204 to Mysql database.
I have a database link in the oracle side .
I am query a table in MySql that have 10 million rows.
Its doesnt matter if i am running :
select * from "CDR_Accounts"@mysql where "id"=7675405;
or
select * from "CDR_Accounts"@mysql ;
There is an index on the id column.
Yet, it seems that the Mysql is feteching all the rows from the table , all the data is transfering to oracle over the dblink , and only after that the requested rows are get back to the client.
The /etc/odbcinst.ini file is as follow:
[odbcprd:oracle@odbc /software/oracle]$ cat /etc/odbcinst.ini
[myodbc3]
Description = Mysql connector to mysql version 3.5
Driver = /software/oracle/MysqlOdbc/3.52/lib/libmyodbc3-3.51.25.so
Driver64 = /usr/lib
Setup = /software/oracle/MysqlOdbc/3.52/lib/libmyodbc3S-3.51.25.so
Setup64 = /usr/lib
UsageCount = 1
CPTimeout = 3600
CPReuse = Please advice
ThanksWhen using a gateway it is always possible that a where clause is not sent to the remote database. This is called post processing and depends on several factors like the used ODBC driver, the columns and its data types but also if you specify certain functions in the where clause.
The fastest way to see if post processing happens is in Oracle 11g the explain plan for a query. In 10g the plan does not always match the statement sent to the foreign database. Here it would be better to enable gateway tracing and setting the trace level to ON. This will log the statements sent to the foreign database and you can compare what statement was sent with the statement you've tried to execute. -
Query started taking longer time with SQL*Net message from dblink
Hi,
Since Yesterday we started see one query which normally used to take 3 min but now it started taking 70 min after a small change do the query instead of accessing view we started accessing directly table.
Both Schema's are on same DB.
Oracle version=11.2.0.2
OS=Solaris 10
Existing Query
WITH ot_symbol_data_v AS
(SELECT dat.symbol, dat.startdate, dat.enddate, oi.currencycode,
dat.primarymarket, primsymb.symbol primarysymbol, dat.mic,
dat.universeid, dat.symbology
FROM onetick_symbol_data@refdata_link dat
LEFT JOIN
(SELECT symbology, universeid, mic, MAX (enddate) enddate
FROM onetick_symbol_data@refdata_link
GROUP BY symbology, universeid, mic) prim
ON prim.symbology = dat.symbology
AND prim.universeid = dat.universeid
AND prim.mic = dat.primarymarket
LEFT JOIN onetick_symbol_data@refdata_link primsymb
ON prim.symbology = primsymb.symbology
AND prim.universeid = primsymb.universeid
AND prim.mic = primsymb.mic
AND prim.enddate = primsymb.enddate
JOIN onetick_isincur_data@refdata_link oi
ON dat.universeid = oi.universeid
JOIN
(SELECT universeid, MAX (enddate) AS enddate
FROM onetick_isincur_data@refdata_link
GROUP BY universeid) oilatest
ON oi.universeid = oilatest.universeid
AND oi.enddate = oilatest.enddate
ORDER BY dat.universeid, dat.mic, dat.symbology, dat.enddate)
SELECT i.instrumentid
|| '||'
|| i.firsttradingdate
|| '000000|'
|| NVL (i.delisteddate, '30001231')
|| '000000|'
|| i.home_market
|| '|'
|| DECODE (imfm.feedid, 0, 'FIXN_RFA', 1, 'ALGO', 2, 'FIXNETIX')
|| '::'
|| osdv.primarysymbol
FROM tibex_meinstrumentview i JOIN tibex_instrumentmicfeedmapview imfm
ON i.isin = imfm.isin
AND i.currencycode = imfm.currencycode
AND i.home_market = imfm.mic
JOIN rd_universeview@refdata_link u
ON i.instrumentid = u.instrumentid AND i.instrumentstatus != 3
and active='Y'
JOIN
(SELECT universeid, DECODE (symbology, 1, 0, 2, 2, -1) feedid,
primarysymbol
FROM ot_symbol_data_v
GROUP BY universeid, symbology, primarysymbol) osdv
ON u.universeid = osdv.universeid
WHERE osdv.feedid = imfm.feedid
ORDER BY i.isin, i.currencycode, i.instrumentid;
New Query
WITH ot_symbol_data_v AS
(SELECT dat.symbol, dat.startdate, dat.enddate, oi.currencycode,
dat.primarymarket, primsymb.symbol primarysymbol, dat.mic,
dat.universeid, dat.symbology
FROM onetick_symbol_data@refdata_link dat
LEFT JOIN
(SELECT symbology, universeid, mic, MAX (enddate) enddate
FROM onetick_symbol_data@refdata_link
GROUP BY symbology, universeid, mic) prim
ON prim.symbology = dat.symbology
AND prim.universeid = dat.universeid
AND prim.mic = dat.primarymarket
LEFT JOIN onetick_symbol_data@refdata_link primsymb
ON prim.symbology = primsymb.symbology
AND prim.universeid = primsymb.universeid
AND prim.mic = primsymb.mic
AND prim.enddate = primsymb.enddate
JOIN onetick_isincur_data@refdata_link oi
ON dat.universeid = oi.universeid
JOIN
(SELECT universeid, MAX (enddate) AS enddate
FROM onetick_isincur_data@refdata_link
GROUP BY universeid) oilatest
ON oi.universeid = oilatest.universeid
AND oi.enddate = oilatest.enddate
ORDER BY dat.universeid, dat.mic, dat.symbology, dat.enddate)
SELECT i.instrumentid
|| '||'
|| i.firsttradingdate
|| '000000|'
|| NVL (i.delisteddate, '30001231')
|| '000000|'
|| i.home_market
|| '|'
|| DECODE (imfm.feedid, 0, 'FIXN_RFA', 1, 'ALGO', 2, 'FIXNETIX')
|| '::'
|| osdv.primarysymbol
FROM tibex_meinstrumentview i JOIN tibex_instrumentmicfeedmapview imfm
ON i.isin = imfm.isin
AND i.currencycode = imfm.currencycode
AND i.home_market = imfm.mic
JOIN universe@refdata_link u
ON i.instrumentid = u.instrumentid AND i.instrumentstatus != 3
and active='Y'
JOIN
(SELECT universeid, DECODE (symbology, 1, 0, 2, 2, -1) feedid,
primarysymbol
FROM ot_symbol_data_v
GROUP BY universeid, symbology, primarysymbol) osdv
ON u.universeid = osdv.universeid
WHERE osdv.feedid = imfm.feedid
ORDER BY i.isin, i.currencycode, i.instrumentid;Most of the wait event is
SQL*Net message from dblink
SQL*Net message to dblink
Regards
NMHi Kim,
uat_trd_owner@UAT001> select * from table(dbms_xplan.display);
PLAN_TABLE_OUTPUT
Plan hash value: 741667790
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Inst |IN-OUT|
| 0 | SELECT STATEMENT | | 1 | 137 | 21981 (2)| 00:04:24 | | |
| 1 | SORT ORDER BY | | 1 | 137 | 21981 (2)| 00:04:24 | | |
|* 2 | HASH JOIN OUTER | | 1 | 137 | 21980 (2)| 00:04:24 | | |
|* 3 | HASH JOIN OUTER | | 1 | 131 | 422 (4)| 00:00:06 | | |
| 4 | NESTED LOOPS | | | | | | | |
| 5 | NESTED LOOPS | | 1 | 125 | 107 (9)| 00:00:02 | | |
| 6 | NESTED LOOPS | | 20 | 1680 | 87 (11)| 00:00:02 | | |
|* 7 | HASH JOIN | | 1 | 64 | 86 (11)| 00:00:02 | | |
| 8 | VIEW | TIBEX_INSTRUMENTMICFEEDMAPVIEW | 1 | 34 | 84 (9)| 00:00:02 | | |
| 9 | HASH GROUP BY | | 1 | 166 | 84 (9)| 00:00:02 | | |
|* 10 | HASH JOIN RIGHT OUTER | | 267 | 44322 | 83 (8)| 00:00:01 | | |
| 11 | TABLE ACCESS FULL | TIBEX_BOARDFEEDMAP | 1 | 20 | 3 (0)| 00:00:01 | | |
| 12 | NESTED LOOPS OUTER | | 267 | 38982 | 80 (8)| 00:00:01 | | |
| 13 | NESTED LOOPS OUTER | | 267 | 21627 | 80 (8)| 00:00:01 | | |
|* 14 | HASH JOIN | | 267 | 17088 | 80 (8)| 00:00:01 | | |
| 15 | MERGE JOIN CARTESIAN | | 2004 | 88176 | 37 (0)| 00:00:01 | | |
| 16 | INDEX FULL SCAN | TIBEX_EDPDEFAULTFEED_PK | 1 | 3 | 1 (0)| 00:00:01 | | |
| 17 | BUFFER SORT | | 2004 | 82164 | 36 (0)| 00:00:01 | | |
|* 18 | TABLE ACCESS FULL | TIBEX_INSTRUMENT | 2004 | 82164 | 36 (0)| 00:00:01 | | |
| 19 | VIEW | TIBEX_EDPINSTRUMENTMARKETSVIEW | 22040 | 430K| 42 (12)| 00:00:01 | | |
| 20 | HASH GROUP BY | | 22040 | 430K| 42 (12)| 00:00:01 | | |
| 21 | VIEW | | 22040 | 430K| 41 (10)| 00:00:01 | | |
| 22 | SORT UNIQUE | | 22040 | 544K| 41 (57)| 00:00:01 | | |
| 23 | UNION-ALL | | | | | | | |
| 24 | INDEX FAST FULL SCAN| TIBEX_EDPFIXNETIXL1_R01 | 7578 | 162K| 18 (0)| 00:00:01 | | |
| 25 | TABLE ACCESS FULL | TIBEX_EDPIXSYMBOLS | 7494 | 197K| 12 (0)| 00:00:01 | | |
| 26 | TABLE ACCESS FULL | TIBEX_EDPRFALGOSUBSCRIPTION | 6968 | 183K| 7 (0)| 00:00:01 | | |
|* 27 | INDEX RANGE SCAN | TIBEX_MICFEEDMAP_PK | 1 | 17 | 0 (0)| 00:00:01 | | |
| 28 | TABLE ACCESS BY INDEX ROWID| TIBEX_INSTRUMENTFEEDMAP | 1 | 65 | 0 (0)| 00:00:01 | | |
|* 29 | INDEX UNIQUE SCAN | TIBEX_INSTRUMENTFEEDMAP_PK | 1 | | 0 (0)| 00:00:01 | | |
| 30 | VIEW | | 100 | 3000 | 1 (100)| 00:00:01 | | |
| 31 | REMOTE | | | | | | REFDA~ | R->S |
| 32 | REMOTE | UNIVERSE | 20 | 400 | 1 (0)| 00:00:01 | REFDA~ | R->S |
|* 33 | INDEX UNIQUE SCAN | XPKTIBEX_INSTRUMENT | 1 | | 0 (0)| 00:00:01 | | |
|* 34 | TABLE ACCESS BY INDEX ROWID | TIBEX_INSTRUMENT | 1 | 41 | 1 (0)| 00:00:01 | | |
| 35 | VIEW | TIBEX_MELASTEXPRICEINTVIEW | 36 | 216 | 314 (2)| 00:00:04 | | |
| 36 | HASH UNIQUE | | 36 | 1656 | 314 (2)| 00:00:04 | | |
|* 37 | HASH JOIN | | 36 | 1656 | 313 (1)| 00:00:04 | | |
| 38 | VIEW | VW_SQ_1 | 304 | 5776 | 157 (2)| 00:00:02 | | |
| 39 | HASH GROUP BY | | 304 | 7296 | 157 (2)| 00:00:02 | | |
|* 40 | TABLE ACCESS FULL | TIBEX_EXECUTION | 17462 | 409K| 156 (1)| 00:00:02 | | |
| 41 | TABLE ACCESS FULL | TIBEX_EXECUTION | 17463 | 460K| 156 (1)| 00:00:02 | | |
| 42 | VIEW | TIBEX_MSGSEQBYINSTRUMENT | 3908 | 23448 | 21558 (2)| 00:04:19 | | |
| 43 | HASH GROUP BY | | 3908 | 74252 | 21558 (2)| 00:04:19 | | |
| 44 | VIEW | | 11626 | 215K| 21556 (2)| 00:04:19 | | |
| 45 | UNION-ALL | | | | | | | |
| 46 | HASH GROUP BY | | 1460 | 26280 | 8906 (1)| 00:01:47 | | |
| 47 | TABLE ACCESS FULL | TIBEX_QUOTE | 1362K| 23M| 8866 (1)| 00:01:47 | | |
| 48 | HASH GROUP BY | | 677 | 12186 | 11750 (2)| 00:02:21 | | |
| 49 | TABLE ACCESS FULL | TIBEX_ORDER | 1790K| 30M| 11696 (1)| 00:02:21 | | |
| 50 | HASH GROUP BY | | 304 | 5472 | 157 (2)| 00:00:02 | | |
|* 51 | TABLE ACCESS FULL | TIBEX_EXECUTION | 17463 | 306K| 156 (1)| 00:00:02 | | |
| 52 | HASH GROUP BY | | 1 | 40 | 3 (34)| 00:00:01 | | |
|* 53 | TABLE ACCESS FULL | TIBEX_TSTRADE | 1 | 40 | 2 (0)| 00:00:01 | | |
| 54 | HASH GROUP BY | | 717 | 11472 | 229 (1)| 00:00:03 | | |
| 55 | INDEX FAST FULL SCAN | IX_BESTEXREL | 7323 | 114K| 228 (0)| 00:00:03 | | |
| 56 | HASH GROUP BY | | 1911 | 34398 | 13 (8)| 00:00:01 | | |
|* 57 | TABLE ACCESS FULL | TIBEX_MERESUMEPRDTRANSITION | 5216 | 93888 | 12 (0)| 00:00:01 | | |
PLAN_TABLE_OUTPUT
| 58 | HASH GROUP BY | | 3 | 51 | 5 (20)| 00:00:01 | | |
| 59 | TABLE ACCESS FULL | TIBEX_EDPUPDATEREJECT | 48 | 816 | 4 (0)| 00:00:01 | | |
| 60 | HASH GROUP BY | | 1587 | 46023 | 215 (2)| 00:00:03 | | |
|* 61 | HASH JOIN | | 35166 | 995K| 213 (1)| 00:00:03 | | |
| 62 | INDEX FULL SCAN | XPKTIBEX_CONFIGMEGROUP | 4 | 16 | 1 (0)| 00:00:01 | | |
| 63 | TABLE ACCESS FULL | TIBEX_INSTRUMENTADMIN | 87915 | 2146K| 212 (1)| 00:00:03 | | |
| 64 | HASH GROUP BY | | 6 | 102 | 5 (20)| 00:00:01 | | |
| 65 | TABLE ACCESS FULL | TIBEX_BESTEXECPRICELOG | 793 | 13481 | 4 (0)| 00:00:01 | | |
| 66 | HASH GROUP BY | | 1 | 40 | 3 (34)| 00:00:01 | | |
|* 67 | TABLE ACCESS FULL | TIBEX_AUCTIONPRICE | 1 | 40 | 2 (0)| 00:00:01 | | |
| 68 | HASH GROUP BY | | 1587 | 28566 | 236 (2)| 00:00:03 | | |
|* 69 | TABLE ACCESS FULL | TIBEX_ADMINACK | 87915 | 1545K| 233 (1)| 00:00:03 | | |
| 70 | HASH GROUP BY | | 1914 | 34452 | 26 (8)| 00:00:01 | | |
| 71 | INDEX FAST FULL SCAN | INSTRUMENTSTATEMSGSEQ | 23705 | 416K| 24 (0)| 00:00:01 | | |
| 72 | HASH GROUP BY | | 1458 | 26244 | 8 (13)| 00:00:01 | | |
| 73 | INDEX FAST FULL SCAN | TIBEX_FREEZEEOTPK | 5890 | 103K| 7 (0)| 00:00:01 | | |
Predicate Information (identified by operation id):
2 - access("A"."INSTRUMENTID"="C"."INSTRUMENTID"(+))
3 - access("A"."INSTRUMENTID"="B"."INSTRUMENTID"(+))
7 - access("OSDV"."FEEDID"="IMFM"."FEEDID")
10 - access("I"."PRIMARYSTATUSBOARDID"="BOARDFM"."BOARDID"(+))
14 - access("SUBSC"."ISIN"="I"."ISIN" AND "SUBSC"."CURRENCYCODE"="I"."CURRENCYCODE")
filter("SUBSC"."HOMEMARKET" IS NULL OR "SUBSC"."HOMEMARKET"="I"."HOME_MARKET")
18 - filter("I"."INSTRUMENTSTATUS"<>3)
27 - access("SUBSC"."MIC"="MICFM"."MIC"(+))
29 - access("I"."INSTRUMENTID"="INSTRFM"."INSTRUMENTID"(+))
33 - access("A"."INSTRUMENTID"="U"."INSTRUMENTID")
34 - filter("A"."INSTRUMENTSTATUS"<>3 AND TO_DATE("A"."FIRSTTRADINGDATE",'YYYYMMDD')<=SYSDATE@! AND "A"."ISIN"="IMFM"."ISIN"
AND "A"."CURRENCYCODE"="IMFM"."CURRENCYCODE" AND "A"."HOME_MARKET"="IMFM"."MIC")
37 - access("A"."MESSAGESEQUENCE"="MAX(B.MESSAGESEQUENCE)" AND "A"."INSTRUMENTID"="ITEM_0")
40 - filter(("B"."SELLENTITYTYPE"=0 OR "B"."SELLENTITYTYPE"=2) AND ("B"."BUYENTITYTYPE"=0 OR "B"."BUYENTITYTYPE"=2))
51 - filter("INSTRUMENTID" IS NOT NULL)
53 - filter("INSTRUMENTID" IS NOT NULL)
57 - filter("INSTRUMENTID" IS NOT NULL)
61 - access("ADMINUSER"="MEGROUPID")
67 - filter("INSTRUMENTID" IS NOT NULL)
69 - filter("INSTRUMENTID" IS NOT NULL)
Remote SQL Information (identified by operation id):
31 - EXPLAIN PLAN INTO PLAN_TABLE@! FOR SELECT "A1"."UNIVERSEID",DECODE("A1"."SYMBOLOGY",1,0,2,2,(-1)),"A1"."PRIMARYSYMBOL"
FROM (SELECT "A6"."SYMBOL" "SYMBOL","A6"."STARTDATE" "STARTDATE","A6"."ENDDATE" "ENDDATE","A3"."CURRENCYCODE"
"CURRENCYCODE","A6"."PRIMARYMARKET" "PRIMARYMARKET","A4"."SYMBOL" "PRIMARYSYMBOL","A6"."MIC" "MIC","A6"."UNIVERSEID"
"UNIVERSEID","A6"."SYMBOLOGY" "SYMBOLOGY" FROM "ONETICK_SYMBOL_DATA" "A6", (SELECT "A7"."SYMBOLOGY"
"SYMBOLOGY","A7"."UNIVERSEID" "UNIVERSEID","A7"."MIC" "MIC",MAX("A7"."ENDDATE") "ENDDATE" FROM "ONETICK_SYMBOL_DATA" "A7" GROUP
BY "A7"."SYMBOLOGY","A7"."UNIVERSEID","A7"."MIC") "A5","ONETICK_SYMBOL_DATA" "A4","ONETICK_ISINCUR_DATA" "A3", (SELECT
"A8"."UNIVERSEID" "UNIVERSEID",MAX("A8"."ENDDATE") "ENDDATE" FROM "ONETICK_ISINCUR_DATA" "A8" GROUP BY "A8"."UNIVERSEID") "A2"
WHERE "A3"."UNIVERSEID"="A2"."UNIVERSEID" AND "A3"."ENDDATE"="A2"."ENDDATE" AND "A6"."UNIVERSEID"="A3"."UNIVERSEID" AND
"A5"."ENDDATE"="A4"."ENDDATE"(+) AND "A5"."MIC"="A4"."MIC"(+) AND "A5"."UNIVERSEID"="A4"."UNIVERSEID"(+) AND
"A5"."SYMBOLOGY"="A4"."SYMBOLOGY"(+) AND "A5"."MIC"(+)="A6"."PRIMARYMARKET" AND "A5"."UNIVERSEID"(+)="A6"."UNIVERSEID" AND
"A5"."SYMBOLOGY"(+)="A6"."SYMBOLOGY" ORDER BY "A6"."UNIVERSEID","A6"."MIC","A6"."SYMBOLOGY","A6"."ENDDATE") "A1" GROUP BY
"A1"."UNIVERSEID","A1"."SYMBOLOGY","A1"."PRIMARYSYMBOL" (accessing 'REFDATA_LINK' )
32 - SELECT "INSTRUMENTID","UNIVERSEID" FROM "UNIVERSE" "U" WHERE "UNIVERSEID"=:1 (accessing 'REFDATA_LINK' )
127 rows selected.
For trace files
WAIT #18446741324892119016: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151855125079
WAIT #18446741324892119016: nam='SQL*Net message from client' ela= 182 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151855125694
=====================
PARSING IN CURSOR #18446741324892117968 len=52 dep=0 uid=474 oct=47 lid=474 tim=42151855125777 hv=1029988163 ad='af4d0890' sqlid='9babjv8yq8ru3'
BEGIN DBMS_OUTPUT.GET_LINES(:LINES, :NUMLINES); END;
END OF STMT
PARSE #18446741324892117968:c=0,e=42,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=1,plh=0,tim=42151855125769
WAIT #18446741324892117968: nam='SQL*Net message to client' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151855126145
EXEC #18446741324892117968:c=0,e=262,p=0,cr=0,cu=0,mis=0,r=1,dep=0,og=1,plh=0,tim=42151855126176
*** 2012-11-20 15:18:56.839
WAIT #18446741324892117968: nam='SQL*Net message from client' ela= 10252982 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151865379208
CLOSE #18446741324892119016:c=0,e=13,dep=0,type=1,tim=42151865379327
CLOSE #18446741324892117968:c=0,e=28,dep=0,type=3,tim=42151865379370
WAIT #18446741324892082152: nam='single-task message' ela= 47849 p1=0 p2=0 p3=0 obj#=-1 tim=42151865429221
WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 107 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151865429886
WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151865429945
WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 926 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151865430901
WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 2 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151865431578
WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 2525 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151865434125
WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670108
WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 58 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670178
WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 0 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670235
WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 60 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670310
WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670337
WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 59 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670407
WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 0 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670464
WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 60 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670539
WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670566
WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 59 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670636
WAIT #18446741324892082152: nam='SQL*Net message to dblink' ela= 1 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670693
WAIT #18446741324892082152: nam='SQL*Net message from dblink' ela= 60 driver id=1413697536 #bytes=1 p3=0 obj#=-1 tim=42151894670768Regards
NM -
No DBLinks in the the generated code
Hi guys,
I am facing a strange problem. The code generated for my mapping does NOT have the dblinks. My OWB version is 10.1.0.4
This is my problem in brief.
I have installed OWB recently and started to do a sample task. I created a very simple one to one table population mapping from source to the target schema. Both are in the same database. When i generated the code for the mapping, it gave a warning 'VLD-2771: System privileges may not allow extraction from source EMP'.
And the mapping gave an error when i deployed the code.
When i checked the code which was generated, i couldnot see any dblinks associated with my source table( which seems strange)
CURSOR "INGRP_c" IS
SELECT
"EMP_SRC_TRG_CONN"."EMPNO" "EMPNO",
"EMP_SRC_TRG_CONN"."ENAME" "ENAME",
"EMP_SRC_TRG_CONN"."JOB" "JOB",
"EMP_SRC_TRG_CONN"."MGR" "MGR",
"EMP_SRC_TRG_CONN"."HIREDATE" "HIREDATE",
"EMP_SRC_TRG_CONN"."SAL" "SAL",
"EMP_SRC_TRG_CONN"."COMM" "COMM",
"EMP_SRC_TRG_CONN"."DEPTNO" "DEPTNO"
FROM "SCOTT"."EMP" "EMP_SRC_TRG_CONN" ;
In brief this is the process i have done.
Source schema : SCOTT & Target schema : TRG_SCHEMA
1) I have created source (for SCOTT) and target(for TRG_SCHEMA) modules.
2) I have also created DBLinks, Locations and Connector from source to the target locations.
3) I registered both the source location and target locations.
4) Validated, Generated and Deployed the Connector from source to the target.
I was unable to trace the error. Did i miss anything in the configuration? or during the installation of OWB.
Though it is a very old post, i hope someone can help me out here.
Thanks in Advance,
Sri
Edited by: SriGP on Jul 2, 2009 6:34 AMIf they are in the same db then you don't need dblink and error you're getting says that schema from witch you're trying to fetch the data does not have select privlige set on emp table.
Grant select rights on the object, deploy it and see if it works. If it does, then just ignore this error. -
Tracing queries from abap to a custom database via dblink
I' m connecting to a database by dblink (name magiap).
I would like to know if somewhere I can trace all the queries from abap to oracle in this specific session , to dbs ='MAGIAP'.
For istance, i would like that the query "SELECT "DESPARTY1"
into :v_DESPARTY1
FROM "T040PARTY"
WHERE "CODPARTY" = '305142941' will be stored some where (in a file??).
I would like that parameters - w_CODPARTY- will be substituted and stored in the trace file with the value (305142941), as shown in the previous
Here is the piece of code ..(a very short example of course)..
DATA : dbs LIKE dbcon-con_name,
v_CODPARTY(15),
v_DESPARTY1(60).
data : w_CODPARTY(15) value '305142941'.
dbs = 'MAGIAP'.
TRY.
EXEC SQL.
CONNECT TO :dbs
ENDEXEC.
IF sy-subrc <> 0.
EXEC SQL.
CONNECT TO :dbs
ENDEXEC.
ENDIF.
IF sy-subrc <> 0.
* RAISE err_conn_aea.
ENDIF.
EXEC SQL.
set connection :dbs
ENDEXEC.
EXEC SQL .
SELECT "DESPARTY1"
into :v_DESPARTY1
FROM "T040PARTY"
WHERE "CODPARTY" = :w_CODPARTY
ENDEXEC.
IF sy-subrc NE 0.
* rc = 4.
ENDIF.
EXEC SQL.
DISCONNECT :dbs
ENDEXEC.
ENDTRY.Hi Silvana,
The SQL statements have been stored in the SQL Cursor Cache, on the database and they will be available until they have been invalidated. You can access the statements at the 'MAGIAP' side and see the last executed queries in the cache.
You can access bind variables by query on the V$SQL_BIND_CAPTURE table, also.
On the other hand, you can activate the trace by the statement, below;
ALTER SYSTEM SET sql_trace = true SCOPE=MEMORY;
Then, the sql statements will be available in the usertrace file. Please note that you should execute and investigate all the statements that I noted above, at the remote side. Plus, as far as I know that it is not able to distinguish the records by the "dblink name". You should check all the statements and try to figure out what queries have been executed remotely.
Best regards,
Orkun Gedik -
Performance problem with dblink
Hi!
I have 2 servers with a dblink join.
I push from server A to server B with an insert sentence 80 mb of data (blob datatype). It take between 4 to 5 hours to insert.
Server A and B are in the same office. (Windows 2000)
Somebody have an idea why it take this time to work?
Can I optimize the transfer ? If yes How!
thanks for your helpI strongly recommend you take the execution plan while running this activity or generate event 10048 trace and diagonse where the dealy is.
Once you get trace or execution plan, we could suggest you more realistic.
If you joins, you can use DRIVING_SITE hint.
SJH
OCP DBA -
Encoding conversion issue on dblink (Oracle - Postgresql)
I have sucessfully setup a dblink from Oracle to Postgresql.
The Postgresql database use UTF-8 encoding for all its data.
When I try this request SELECT * FROM "table"@Postgres , I receive this error :
ORA-00942: Table ou vue inexistante
[Generic Connectivity Using ODBC]DRV_DescribeTable: DB_ODBC_RECORD (1093): ; ERREUR: le caractère 0xc5a1 du codage « UTF8 » n'a pas d'équivalent dans « LATIN1 » (SQL State: HY000; SQL Code: 1)
ORA-02063: précédant 2 lines de RECORD
00942. 00000 - "table or view does not exist"
*Cause:
*Action:
Erreur à la ligne 2, colonne 5How can I get rid off of this error ?Do you get the same problem for all tables or if you run the select as -The problem is raised only on some tables not all.
select * from "owner"."tablename"@hsodbc ;On a failing select, adding the "owner" doesn't solve the problem.
Are there any error sin the trace file and if so could you post them here ?I perform this query : select * from "owner"."table"@POSTGRE
Here are the traces :
Oracle Corporation --- MONDAY FEB 27 2012 16:21:54.959
Version 10.2.0.1.0
hoagprd (2): ; hoagprd Entered.
HOACONN.C (244): ; [Generic Connectivity Using ODBC] version: 4.6.2.0.0070
HOACONN.C (295): ; Class version: 200
hoagprd (2): ; hoagprd Exited with retcode = 0.
hoainit (3): ; hoainit Entered.
(0): ; connect string is: defTdpName=Postgre;SYNTAX=(ORACLE8_HOA,
BASED_ON=ORACLE8, IDENTIFIER_QUOTE_CHAR="",
CASE_SENSITIVE=CASE_SENSITIVE_QUOTE);BINDING=<navobj><binding><datasources><da-
tasource name='Postgre' type='GENERIC_ODBC_FOR_HS'
connect='Postgre'><driverProperties/></datasource></datasources><remoteMachines-
/><environment><optimizer noFlattener='true'/><misc year2000Policy='-1'
consumerApi='1' sessionBehavior='4'/><queryProcessor parserDepth='2000'
tokenSize='1000' noInsertParameterization='true'
noThreadedReadAhead='true'
noCommandReuse='true'/><debug
generalTrace='true'/></environment></binding></navobj>
ORACLE GENERIC GATEWAY Log File Started at 2012-02-27T16:21:54
hoainit (3): ; hoainit Exited with retcode = 0.
hoalgon (7): ; hoalgon Entered. name = rec_lct.
Created new ODBC connection (136751296)
hoalgon (7): ; hoalgon Exited with retcode = 0.
hoaulcp (4): ; hoaulcp Entered.
hoaulcp (4): ; hoaulcp Exited with retcode = 0.
hoauldt (5): ; hoauldt Entered.
hoauldt (5): ; hoauldt Exited with retcode = 0.
hoabegn (9): ; hoabegn Entered. formatID = 306206, hoagttln = 29, hoagttid =
PDELTAA.286b8407.4.69.1747760, hoagtbln = 10, hoagtbid = ^D, tflag = 0, initial
= 1
hoabegn (9): ; hoabegn Exited with retcode = 0.
hoadtab (26): ; hoadtab Entered. count = 1
hoadtab (26): ; schema_name = owner, table_name = table
odbc_owner: select * from "owner"."table"
DB_ODBC_POSTGRE (1093): ; ERREUR: le caractère 0xc5a1 du codage « UTF8 » n'a
pas d'équivalent dans « LATIN1 » (SQL State: HY000; SQL Code: 1)
DRV_DescribeTable: DB_ODBC_POSTGRE (1093): ; ERREUR: le caractère 0xc5a1 du
codage « UTF8 » n'a pas d'équivalent dans « LATIN1 » (SQL State: HY000; SQL
Code: 1)
nvRETURN (drv_priv.c 948): -2202
hoadtab (26): ; hoadtab Exited with retcode = 0.
hoapars (15): ; hoapars Entered. stmtType = 0, id = 1.
nvOUT (qp_sqtxt.c 55): SELECT * FROM "owner"."table"
nvRETURN (qpsynon.c 1140): -1
odbc_owner: select * from "owner"."table"
DB_ODBC_POSTGRE (1093): ; ERREUR: le caractère 0xc5a1 du codage « UTF8 » n'a
pas d'équivalent dans « LATIN1 » (SQL State: HY000; SQL Code: 1)
DRV_DescribeTable: DB_ODBC_POSTGRE (1093): ; ERREUR: le caractère 0xc5a1 du
codage « UTF8 » n'a pas d'équivalent dans « LATIN1 » (SQL State: HY000; SQL
Code: 1)
nvRETURN (drv_priv.c 948): -2202
[A00D] Failed to open table Postgre:owner.table
nvRETURN (qpbldbtn.c 502): -2202
nvRETURN (qpbldbtn.c 382): -2202
nvRETURN (qp_seman.c 3153): -2202
nvRETURN (qp_yacc.c 1930): -2202
nvRETURN (qp_compl.c 515): -2202
nvRETURN (qp_compl.c 232): -2202
nvRETURN (qp_compl.c 200): -2202
hoapars (15): ; hoapars Exited with retcode = 942.
hoadtab (26): ; hoadtab Entered. count = 1
hoadtab (26): ; schema_name = owner, table_name = table
odbc_owner: select * from "owner"."table"
DB_ODBC_POSTGRE (1093): ; ERREUR: le caractère 0xc5a1 du codage « UTF8 » n'a
pas d'équivalent dans « LATIN1 » (SQL State: HY000; SQL Code: 1)
DRV_DescribeTable: DB_ODBC_POSTGRE (1093): ; ERREUR: le caractère 0xc5a1 du
codage « UTF8 » n'a pas d'équivalent dans « LATIN1 » (SQL State: HY000; SQL
Code: 1)
nvRETURN (drv_priv.c 948): -2202
hoadtab (26): ; hoadtab Exited with retcode = 0.
hoapars (15): ; hoapars Entered. stmtType = 0, id = 1.
nvOUT (qp_sqtxt.c 55): SELECT * FROM "owner"."table"
odbc_rec: select * from "owner"."table"
DB_ODBC_POSTGRE (1093): ; ERREUR: le caractère 0xc5a1 du codage « UTF8 » n'a
pas d'équivalent dans « LATIN1 » (SQL State: HY000; SQL Code: 1)
DRV_DescribeTable: DB_ODBC_POSTGRE (1093): ; ERREUR: le caractère 0xc5a1 du
codage « UTF8 » n'a pas d'équivalent dans « LATIN1 » (SQL State: HY000; SQL
Code: 1)
nvRETURN (drv_priv.c 948): -2202
[A00D] Failed to open table Postgre:owner.table
nvRETURN (qpbldbtn.c 502): -2202
nvRETURN (qpbldbtn.c 382): -2202
nvRETURN (qp_seman.c 3153): -2202
nvRETURN (qp_yacc.c 1930): -2202
nvRETURN (qp_compl.c 515): -2202
nvRETURN (qp_compl.c 232): -2202
nvRETURN (qp_compl.c 200): -2202
hoapars (15): ; hoapars Exited with retcode = 942. -
How to generate the trace files for remote db link session's?
User are complaining, the db link queries are performing slowness..
how to enable the sql trace session for db link's in remote database...
Is there any way to enable sqltrace for the dblink session ?
if not how to enable the sql trace for entire database level, rather than session based...An explain plan of the SQL being ran on the local database will review the SQL being passed to the remote db. You can then explain that SQL on the remote db.
I have had to tune a few distribued queries so more than likely the explain plan alone will be enough to allow you to tune the query to improve performance. If not then you can go to the trouble of trying to set up dual traces.
HTH -- Mark D Powell -- -
Error Ora-12500 when using dblink
Hi all,
I have a database that I can connect directly with no problem, but there's error when I try to connect to that db from another db by using dblink
(Select * from someTab@link_name)
The error is Ora-12500
(Sure that tnsname.ora file is OK, I meant SID that using in dblink)
What can I do to deal with this prob?
Thank you!Mr_what wrote:
Thank you guys! Of course I've known what Ora-12500 means, google is always the first thing I do when have to deal with any prob.Then you should have run across the cause of the problem..?
The client (in this case, the PL/SQL code using the db-link) uses a TNS alias to connect to an Oracle Listener. Part of the TNS alias is specifying the database the client wants to connect to (e.g. using SID or SERVICE_NAME).
The Listener confirms that it services this SID or service (it needs to be registered with the Listener). It then "+hands off+" the connection to that database. It can do this either as a dedicated or shared server process.
In your case, your TNS connection does not request a shared server connection. So the Listener needs to provide a dedicated server to service your client connection. It does so by executing +$ORACLE_HOME/bin/oracle+ - using the settings for that registered database (which includes the +$ORACLE_HOME+ dir). It passes command line parameters to this process (typically +(LOCAL=NO)+ ), and other data via the call (such as the socket handle this oracle executable needs to use to communicate with your client session).
This is the step that fails. The Listener fails to create this dedicated process. It uses a specific kernel call (differs from o/s to o/s) to create this dedicated server (a process on Linux/Unix, or thread on Windows). This call is usually what fails and results in the error you see on the client side.
There can be a number of reasons why this failed. The usual two suspects are:
- the kernel not allowing the Oracle o/s user to create more processes as it has reached it resource quota
- invalid +$ORACLE_HOME+ and the call fails to load the bin/oracle executable process
I would first eliminate these two as the cause of the problem. If it is not caused by these, then I would enable listener tracing and troubleshoot a connection that results in this error. There are various levels of diagnostics that can be enabled for tracing. At the lowest level one can trace the actual calls made by the listener, including the parameters values passed. -
Problem with reading data over dblink
Hi,
I have a dblink from Oracle 10.2.0.3 db(on windows) to Postgresql 8.3.3 (on centos 4) .
When trying reading data from Postgresql table , I cannot read varchar colums, in he result set there is no error message.
In the hs trace file it says "unrecognized data type" for the varchar colums.
I tried character,text data types, but the error message is the same.
With Oracle 9.2.0.8 ( on hp/ux platform) there is no problem reading that data types.
How can I handle this problem?
ThanksHi,
i had a similiar problem with 10.2.0.3 querying MS/SQL2000 and Oracle support told me it is a bug which was fixed in 10.2.0.4, however, i couldn't upgrade as SAP was not certified with this version so i had configured a workarround with Oracle support:
create a DB link from 10.2.0.3 to a 9.2.0.8 DB, in the 9.2.0.8 i have created synonyms through DB link (HS) to the MS/SQL and it solved the problem.
i know it is not a best solution but it works and production system continue to function.
dBarak.
Maybe you are looking for
-
I'm try to write a RMI application in linux I used the java sample code for beginning ! But It can't run normally.The error is as following : exception:java.rmi.ConnectException:Connection refused to host:0.0.0.0;nested exception is :java.net.Connect
-
Am I able to upgrade the powersupply and GPU on a Pavilion 500-424
I have a Pavilion 500-424 and I would like to upgrade my GPU. This pc only has a 65 watt power supply and I am wondering if this and the GPU are upgradeable.
-
Migrate to 5.0 to 6i and the exec_sql stop working
Hi, I4ve migrate my application from Forms 5.0... to 6i(6.0.8.17.1). I have a function that uses EXEC_SQL, and this funcionallity stops working. When I execute the following commands I have an ORA-306500 error. -- Open the cursor cursor_count := exec
-
How can I go about creating a mail to form which will email me for the data users enter? Thanks
-
I completed the iOS 7.0.2 update and now my screen is locked in the Connect to iTunes position. I am not near my home computer so I cannot connect to iTunes. Please let me know if there is a way to recover this without connecting to a computer.