Skip to Main Content

ODP.NET

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Oracle.ManagedDataAccess.Core BulkCopy Error

NatLCalMay 18 2021

I am encountering the following error when I call WriteToServer and I am not understanding why.
Oracle.ManagedDataAccess.Client.OracleException: 'ORA-01013: user requested cancel of current operation'

Here is the stacktrace:
at OracleInternal.ServiceObjects.OracleConnectionImpl.CheckForAnyErrorFromDB(TTCError ttcOER)
at OracleInternal.TTC.TTCDirectPathPrepare.ReadResponse(DirectPathContext& directPathContext)
at OracleInternal.ServiceObjects.OracleBulkCopyImpl.Prepare()
at Oracle.ManagedDataAccess.Client.OracleBulkCopy.WriteDataSourceToServer(IBulkCopyDataSource dataSource)
at Oracle.ManagedDataAccess.Client.OracleBulkCopy.WriteToServer(IDataReader reader)

Comments

Alex Keh-Oracle

An ORA-0103 can be indicative that the command is canceled. This can occur if the DB or user initiates an explicit command cancel or the command has a timeout that expired.

NatLCal

The timeout is set to 300, but the error is thrown immediately.
I can't follow the thread past when BulkCopy calls GetOrdinal() in my IDataReader class for each mapped column before the error is thrown.
Does DestinationPartitionName need to be set? I didn't set that property when I was using the older version of Oracle.DataAccess.

Alex Keh-Oracle

That is unusual that the command cancel is immediately initiated. Can you turn on tracing? It would tell us where internally the command was being cancelled. You can add the following two lines of code before opening the connection to enable tracing:
OracleConfiguration.TraceFileLocation = @"<Directory Location>";
OracleConfiguration.TraceLevel = 7;
You can either post the trace or email it to us dotnet_us(at)oracle.com.

NatLCal

MISCELLANEOUS.EXE_PID_22376_DATE_2021_05_21_TIME_10_53_08_539498.txt (165.75 KB)Here is the trace. Hope this helps.

NatLCal

@alex-keh-oracle, have you had a chance to review the trace file?

Alex Keh-Oracle

I and a dev team member reviewed the trace, but didn't see anything that helped us to understand why the cancel operation occurred.
My recommendation is to open an Oracle Support service request and collect the server side trace. The server side is issuing the cancel call for some reason. It's possible something from ODP.NET is triggering the DB to do that. The server side trace could identify what it is.

Alex Keh-Oracle

@natlcal I had another team member review the trace that has more expertise with Bulk Copy internals. It appears you are using the same table to bulk copy from and into, EES_RUN_DATA. Can you try changing the destination table name to another table and see if that works? If so, then the bug likely has to do with using the same table name.
Can you also help me understand the use case for bulk copying into the table that already has the data?

NatLCal

@alex-keh-oracle, I am using an IDataReader object as the data source. The data is being streamed from a file. I am uncertain how to set a source table name in this case. The Bulk Copy internals must be setting the source table name to the same value as the destination.

Alex Keh-Oracle

Try setting the destination table name to something different, such as:
blkCpy.DestinationTableName = "EES_RUN_DATA1";

NatLCal

Looks like server tracing is the next step.
Is the ManagedDataAccess client dependent on the server running a specific version (or newer)?

Alex Keh-Oracle

Setting the DestinationTableName didn't eliminate the error?

NatLCal

If I change the DestinationTableName, the data won't load into the correct database table....

Alex Keh-Oracle

That's correct. We're verifying whether the problem has something to do with the table names matching, at least internally in ODP.NET. If loading into EES_RUN_DATA1 is successful, then we know the problem is related to that area.

NatLCal

So create a new table named EES_RUN_DATA1 and try loading the data there?
I don't foresee that having a different result because I am still setting the DestinationTableName, but not the SourceTableName.
I am using an IDataReader object, so there is nowhere to set a SourceTableName.

Alex Keh-Oracle

Sorry, that other team member was looking at the wrong trace. Ignore the EES_RUN_DATA1 option.
Does this issue always happen when you use BulkCopy with the same data set or does it happen intermittently? If it always happens, we will likely need to give you a drop with enhanced tracing. What we see is ODP.NET able to read 5 columns of metadata info. Then, there's some problem parsing some follow on data that leads to the ORA-01013.
If you have some successful runs, turn on tracing and post the trace. We can then compare the traces and see what additional data follows and then figure out why it would cause that error.

NatLCal

@alex-keh-oracle, do these server-side trace files help?
The error occurs every time.

Alex Keh-Oracle

Thanks. My team will review the traces.
Can you answer my question on whether this issue always happen when you use BulkCopy with the same data set or does it happen intermittently?

Alex Keh-Oracle

We took a quick look at the server traces, they are not the right type of traces we need. Can set “trace_level_server=16” in sqlnet.ora file on the DB side? That will produce the type of trace we need.

NatLCal

@alex-keh-oracle, are these files for the right type of trace?

NatLCal

@alex-keh-oracle, any updates?

Alex Keh-Oracle

Those files look like a performance trace (tkprof), an alert.log, and some kind of dump. What my ODP.NET team needs is the network trace file, which can be configured in the server side sqlnet.ora with the following settings:
TRACE_LEVEL_SERVER = 16
TRACE_FILE_SERVER = <name of trace file>
TRACE_DIRECTORY_SERVER = <full directory path>
Finally, bounce the DB so that the settings take effect.

NatLCal

@Alex Keh-Oracle
The trace generated many files and I am not sure which your team needs....
I zipped the files and uploaded them all.
Hope these help.
trace.zip (350.72 KB)

Alex Keh-Oracle

@natlcal
The traces do not have any further indication of what's causing the cancel request. A couple questions:
Did you use unmanaged ODP.NET Bulk Copy in the same scenario, but this error never occurred?
Can you send us a reproducible test case? The simpler the test case, the better.
You can post the test case here or you can email it to us: dotnet_us(at)oracle.com.
With an in-house test case, we hope to run enhanced diagnostics to find the problem source.

NatLCal

@Alex Keh-Oracle,
Do have the link for the unmanaged ODP.NET Core library?
I only see the managed ODP.NET for .NET Core....

Alex Keh-Oracle

There is no unmanaged ODP.NET Core, only ODP.NET Core. My assumption was that you were taking a .NET FW ODP.NET app and porting it to Core and ODP.NET Core. Seeing that we introduced Bulk Copy in ODP.NET Core not too long ago, many developers are now porting their Bulk Copy code to .NET Core now. However, it sounds like you are building a new app and not porting an existing unmanaged ODP.NET app.

NatLCal

@Alex Keh-Oracle,
Sorry, I misunderstood.
Yes I have a program that successfully runs with the unmanaged ODP.NET using .NET framework 4.0
I can put together a test case for you. Do you need a project file for my code files?

Alex Keh-Oracle

It's good to know that you have an unmanaged ODP.NET app that successfully used Bulk Copy. Assuming that it was minimally modified, but still is running against the same DB instance, that does likely point to a problem in the ODP.NET Core Bulk Copy implementation.
The test case we'd like is the ODP.NET Core Bulk Copy code. We just need the C# source if to reproduce the problem doesn't require any special environment settings that your project file has.
Since it's ODP.NET Core, it does introduce the possibility there could be an OS quirk. Which OS are you using ODP.NET Core on and which version?

NatLCal

@Alex Keh-Oracle,
My PC is running Windows 10 Pro, version 21H1, build 19043.1110
TestCase.zip (146.63 KB)

Alex Keh-Oracle

I found the problem. The column names are mismatched. The bulk copy will be successful if you use the following string for your column names instead of the current line of code:
var columns = new string[] { "SNOMED_CID", "SNOMED_FSN", "SNOMED_CNCPT_STATS", "UMLS_CUI", "OCCURRENCE", "USAGE", "FIRSTINSUBSET", "RETIREDFROMSUBSET", "LASTINSUBSET", "REPLACEDSNOMED_CID" };
When Oracle executes DDL, it will capitalize all column names. Lower case letters are only preserved when names are in quotes. Thus, the DDL CREATE TABLE statement created column names all upper case.
Once the columns names match, the bulk copy appears to go through fine.
I did reproduce your ORA-01013 when running your app unchanged. I've filed a enhancement request to see if we can get an error message that better describes the true error source.

Alex Keh-Oracle

I filed bug 33117071 to track this error.

NatLCal

@alex-keh-oracle, thanks for your help!
That is interesting, I didn't realize the mapping is case sensitive.

Alex Keh-Oracle

This bug has been fixed in ODP.NET 21.3, which will be released soon.

Geraldo Peralta

It is fixed on version 2.19.130 of Oracle.ManagedDataAccess.Core

1 - 33

Post Details

Added on May 18 2021
33 comments
1,731 views