HS_TRANSACTION_MODEL / Is DG4ODBC capable of SQL_DATA_SOURCE_READ_ONLY?

Question

We're currently using READ_ONLY_AUTOCOMMIT as setting for HS_TRANSACTION_MODEL in attempt to minimize potential for locking in remote database. Nevertheless, read locks are created with DG4ODBC use by default and persist within remote database for duration of long-running queries which makes use of READ_ONLY_AUTOCOMMIT prohibitive in our environment. Is there a way to totally disable use of transaction model for DG4ODBC to achieve "pure read only" access. In other words, is it possible to change interaction between DG4ODBC agent and ODBC driver in a way that prevents creation of read locks within remote UniVerse 10.1 database?
It would be ideal for interaction between DG4ODBC agent and ODBC driver to emulate MS Excel/ MS Query interaction that occurs using same ODBC driver as is used for DG4ODBC configuration. When accessing remote data source using MS Excel / MS Query, there is no locking on remote server whatsoever. I've performed a couple different types of ODBC traces and some differences that seem relevant/noteworthy between Excel and DG4ODBC are listed below:
Excerpts from Excel / MS Query ODBC trace:
===========================
SQLSetConnectOption
     0x01010000
     SQL_LOGIN_TIMEOUT
     0x2D000000
     SQL_SUCCESS
SQLDriverConnect
     0x01010000
     0xF8070200
     [16]DSN=dsn.ODBC;
     SQL_NTS
     [16]DSN=dsn.ODBC;
     1024
     16
     SQL_DRIVER_COMPLETE
     SQL_SUCCESS
SQLGetInfo
     0x01010000
     SQL_DATA_SOURCE_READ_ONLY
     [1]N
     2048
     1
     SQL_SUCCESS
Reference to "SQL_DATA_SOURCE_READ_ONLY above seems indicative of behavior I would like DG4ODBC to emulate. There is no such reference within ODBC trace output for DG4ODBC test:
Excerpts from DG4ODBC trace:
===================
SQLSetConnectOption
     0x01010000
     SQL_AUTOCOMMIT
     SQL_AUTOCOMMIT_ON
     SQL_SUCCESS
SQLDriverConnect
     0x01010000
     0x00000000
     [36]DSN=dsn.ODBC;UID=userid;PWD=password;
     SQL_NTS
     [36]DSN=dsn.ODBC;UID=userid;PWD=password;
     1024
     36
     SQL_DRIVER_NOPROMPT
     SQL_SUCCESS
References above to "SQL_AUTOCOMMIT" and "SQL_AUTOCOMMIT_ON" in the case of DG4ODBC seem in line with current READ_ONLY_AUTOCOMMIT setting for HS_TRANSACTION_MODEL and default DG4ODBC behavior where a transaction is set even for "read only" access to FDS (foreign data source).
In one other ODBC trace I performed the following error is reported which seems related to DG4ODBC default behavior / HS_TRANSACTION_MODEL:
UCI SQLExecute() returned -1
SQLSTATE : S1000 Native Error : 950151 [U2][SQL Client][UNIVERSE]UniVerse/SQL: Isolation levels are not supported for file types 1, 19 and 25
Facility: DBCAPERR Severity: ERROR Error ID: 46 Extern error: 950151 Message: UCI Error. Func: SQLExecute(); State: S1000; uniVerse code: 950151; Msg: [U2][SQL Client][UNIVERSE]UniVerse/SQL: Isolation levels are not supported for file types 1, 19 and 25.
So while nature and effect of locking that occurs in FDS may be largely dependent on architecture and conventions associated with foreign data source, it certainly seems possible to achieve "pure read only" access to remote data source with ODBC driver we're using by altering behavior/calls to driver issued by client/agent. MS Excel / MS Query as client/agent exhibits desired behavior. Is it possible to alter behavior of DG4ODBC agent in some way to achieve same end result?
Overall, results of DG4ODBC tests so far have been very promising but this issue of locking is turning out to be a real problem for large files and, hence, long running queries for our environment in the way of making this a viable/practical option for production use.
Any help with achieving SQL_DATA_SOURCE_READ_ONLY with DG4ODBC would be greatly appreciated!!
Thread containing additional relevant background info: https://forums.oracle.com/forums/thread.jspa?threadID=2313253
Regards, Glenn
Edited by: WileyCoyote on Dec 19, 2011 10:46 AM
Edited by: WileyCoyote on Mar 8, 2012 11:00 AM

Answer 1

This bit of output from remote AIX based UniVerse 10.1 system illustrates the locks being created as a result of DG4ODBC based access:
LIST-READU EVERY
Active File Locks:
Device.... Inode.... Netnode Userno Lmode Pid Login Id
3014661 4263309 0 65417 7 FS 81396 root
Active Group Locks: Record Group Group Group
Device.... Inode.... Netnode Userno Lmode G-Address. Locks ...RD ...SH ...EX
3014661 4263309 0 65417 4 IN A00 1 0 0 0
3014661 4263309 0 65417 5 IN 2E00 1 0 0 0
3014661 1968116 0 61273 9 IN 25600 1 0 0 0
Active Record Locks:
Device.... Inode.... Netnode Userno Lmode Pid Login Id Item-ID.............
3014661 4263309 0 65417 4 RL 81396 root 01907474001
3014661 4263309 0 65417 5 RL 81396 root 01606473001
3014661 4263309 0 65417 10 RL 81396 root 01693774001
3014661 4263309 0 65417 11 RL 81396 root 01392773001Statements executed connected to Oracle XE 11gR2 database for purpose of extracting data from remote UniVerse tables for transfer to corresponding Oracle tables that cause locks such as those shown above:
insert into target_table select * from source_table@dg4odbc_sid;
create table target_table as (select * from source_table@dg4odbc_sid);However, this is the general form currently in use for daily ETL operation that executes automatically via crontab, shell & sql/plus scripts for a number of tables scheduled thus far:
begin
etl_&1;
end;
/Anonymous PL/SQL block of form shown above executes stored procedure for respective source/target table identified by parameter &1 passed to SQL/Plus script. Assuming a value for parameter &1 of "target_table", for instance, the definition for procedure etl_target_table referenced as etl_&1 above would be:
create or replace
procedure etl_target_table as
begin
insert into target_table select * from target_table@dg4odbc_sid;
commit;
end;I adopted this convention at present to eliminate code redundancy and to provide additional control needed in the case of a couple tables that call for additional filtering via a WHERE clause to exclude problematic rows or that require explicit list of items on SELECT as opposed to '*' to eliminate columns on remote system containing problematic data. I'm pointing this out because I suspect use of PL/SQL here may have a bearing on ability to accomplish stated objective prompting this thread. Most important thing is to somehow eliminate locking on remote system. I would rework structure of programming and scripting in whatever way is necessary to accomodate a purely read-only transaction model and DG4ODBC behavior that eliminates creation of transaction and, hence, locks created in remote UniVerse database.
General approach outlined above is in place and working ok for a series of smaller tables each of which only takes seconds or a few minutes to extract into corresponding Oracle tables. There are a number of larger tables in remote system that take much longer to scan for extraction. Locking invariably occurs for these larger tables and persists for duration of statement execution causing production users/processes of remote system to wait.
Also, if locks already exist for any of the remote tables at the time DG4ODBC extraction begins then the DG4ODBC process may fail with this error:
ERROR at line 1:
ORA-28500: connection from ORACLE to a non-Oracle system returned this message:
[Rocket U2][UVODBC][2701121]Error ID: 39 Severity: ERROR Facility: DBCAPERR -
Serialization failure. {40001,NativeErr = 950261}
ORA-02063: preceding 2 lines from DSNThis excerpt is provided from UniVerse ODBC guide which seems to explain "serialization" error above:
"Serialization failure. The transaction to which the prepared statement belonged was terminated to prevent
deadlock. Error ID: 39, Severity: ERROR, Facility: DBCAPERR"So hopefully this provides additional insight into complexion of problem we're having and why we wish to change default behavior of DG4ODBC in this context; ie., prevent setting transaction that in turn causes locks in remote database when all we wish to do is retrieve data from FDS as is performed by other client tools such as Excel or MS Query using same ODBC DSN on which DG4ODBC configuration is based.
Use of DG4ODBC is actually working out better than any other alternative I've tried thus far for extraction to perform more complex data analysis business calls for than UniVerse "multivalue" datastore allows so I hope there's something that can be done that allows us to continue using Oracle and DG4ODBC approach. Thanks for your assistance!
Regards, Glenn
Edited by: WileyCoyote on Dec 20, 2011 11:01 AM
Edited by: WileyCoyote on Mar 8, 2012 11:03 AM