Row locking issue with version enabled tables
I've been testing the effect of locking in version enabled tables in order to assess workspace manager restrictions when updating records in different workspaces and I have encountered a locking problem where I can't seem to update different records of the same table in different sessions if these same records have been previously updated & committed in another workspace.
I'm running the tests on 11.2.0.3. I have ROW_LEVEL_LOCKING set to ON.
Here's a simple test case (I have many other test cases which fail as well but understanding why this one causes a locking problem will help me understand the results from my other test cases):
--Change tablespace names as required
create table t1 (id varchar2(36) not null, name varchar2(50) not null) tablespace XXX;
alter table t1 add constraint t1_pk primary key (id) using index tablespace XXX;
exec dbms_wm.gotoworkspace('LIVE');
insert into t1 values ('1', 'name1');
insert into t1 values ('2', 'name2');
insert into t1 values ('3', 'name3');
commit;
exec dbms_wm.enableversioning('t1');
exec dbms_wm.gotoworkspace('LIVE');
exec dbms_wm.createworkspace('TESTWSM1');
exec dbms_wm.gotoworkspace('TESTWSM1');
--update 2 records in a non-LIVE workspace in preparation for updating in different workspaces later
update t1 set name = name||'changed' where id in ('1', '2');
commit;
quit;
--Now in a separate session (called session 1 for this example) run the following without committing the changes:
exec dbms_wm.gotoworkspace('LIVE');
update t1 set name = 'changed' where id = '1';
--Now in another session (session 2) update a different record from the same table. The below update will hang waiting on the transaction in session 1 to complete (via commit/rollback):
exec dbms_wm.gotoworkspace('LIVE');
update t1 set name = 'changed' where id = '2';
I'm surprised records of different ids can't be updated in different sessions i.e. why does session 1 lock the update of record 2 which is not being updated anywhere else. I've tried this using different non-LIVE workspaces with similar results. I've tried changing table properties e.g. initrans with and still get a lock. The changes to table properties are successfully propagated to the _LT tables but not all the related workspace manager tables created for table T1 above. I'm not sure if this is the issue.
Note an example of the background workspace manager query that may create the lock is something like:
UPDATE TESTWSM.T1_LT SET LTLOCK = WMSYS.LT_CTX_PKG.CHECKNGETLOCK(:B6 , LTLOCK, NEXTVER, :B3 , 0,'UPDATE', VERSION, DELSTATUS, :B5 ), NEXTVER = WMSYS.LT_CTX_PKG.GETNEXTVER(NEXTVER,:B4 ,VERSION,:B3 ,:B2 ,683) WHERE ROWID = :B1
Any help with this will be appreciated. Thanks in advance.
Hi Ben,
Thanks for your quick response.
I've tested your suggestion and it does work with 2 workspaces but the same problem is enountered when additional workspaces are created.
It seems if multiple workspaces are used in a multi user environment, locks will be inevitable which will degrade performance especially if a long transaction is used.
Deadlocks can also be encountered where eventually one of the sessions is rolled back by the database.
Is there a way of avoiding this e.g. by controlling the creation of workspaces and table updates?
I've updated my test case below to demonstrate the extra workspace locking issue.
--change tablespace name as required
create table t1 (id varchar2(36) not null, name varchar2(50) not null) tablespace XXX;
alter table t1 add constraint t1_pk primary key (id) using index tablespace XXX;
exec dbms_wm.gotoworkspace('LIVE');
insert into t1 values ('1', 'name1');
insert into t1 values ('2', 'name2');
insert into t1 values ('3', 'name3');
commit;
exec dbms_wm.enableversioning('t1');
exec dbms_wm.gotoworkspace('LIVE');
exec dbms_wm.createworkspace('TESTWSM1');
exec dbms_wm.gotoworkspace('TESTWSM1');
update t1 set name = name||'changed' where id in ('1', '2');
commit;
Session 1:
exec dbms_wm.gotoworkspace('LIVE');
update t1 set name = 'changed' where id = '1';
session 2:
exec dbms_wm.gotoworkspace('LIVE');
update t1 set name = 'changed' where id = '2';
--end of original test case, start of additional workspace locking issue:
Session 1:
rollback;
Session 2:
rollback;
--update record in both workspaces
exec dbms_wm.gotoworkspace('LIVE');
update t1 set name = 'changed' where id = '3';
commit;
exec dbms_wm.gotoworkspace('TESTWSM1');
update t1 set name = 'changed' where id = '3';
commit;
Session 1:
exec dbms_wm.gotoworkspace('LIVE');
update t1 set name = 'changed' where id = '1';
session 2:
exec dbms_wm.gotoworkspace('LIVE');
update t1 set name = 'changed' where id = '2';
Session 1:
rollback;
Session 2:
rollback;
exec dbms_wm.gotoworkspace('LIVE');
exec dbms_wm.createworkspace('TESTWSM2');
exec dbms_wm.gotoworkspace('TESTWSM2');
update t1 set name = name||'changed2' where id in ('1', '2');
commit;
Session 1:
exec dbms_wm.gotoworkspace('LIVE');
update t1 set name = 'changed' where id = '1';
--this now gets locked out by session 1
session 2:
exec dbms_wm.gotoworkspace('LIVE');
update t1 set name = 'changed' where id = '2';
Session 1:
rollback;
Session 2:
rollback;
--update record 3 in TESTWSM2
exec dbms_wm.gotoworkspace('TESTWSM2');
update t1 set name = 'changed' where id = '3';
commit;
Session 1:
exec dbms_wm.gotoworkspace('LIVE');
update t1 set name = 'changed' where id = '1';
--this is still locked out by session 1
session 2:
exec dbms_wm.gotoworkspace('LIVE');
update t1 set name = 'changed' where id = '2';
Session 1:
rollback;
Session 2:
rollback;
--try updating LIVE
exec dbms_wm.gotoworkspace('LIVE');
update t1 set name = 'changed' where id = '3';
commit;
Session 1:
exec dbms_wm.gotoworkspace('LIVE');
update t1 set name = 'changed' where id = '1';
--this is still locked out by session 1
session 2:
exec dbms_wm.gotoworkspace('LIVE');
update t1 set name = 'changed' where id = '2';
Session 1:
rollback;
Session 2:
rollback;
--try updating TESTWSM1 workspace too - so all have been updated since TESTWSM2 was created
exec dbms_wm.gotoworkspace('TESTWSM1');
update t1 set name = 'changed' where id = '3';
commit;
Session 1:
exec dbms_wm.gotoworkspace('LIVE');
update t1 set name = 'changed' where id = '1';
--this is still locked out by session 1
session 2:
exec dbms_wm.gotoworkspace('LIVE');
update t1 set name = 'changed' where id = '2';
Session 1:
rollback;
Session 2:
rollback;
--try updating every workspace afresh
exec dbms_wm.gotoworkspace('LIVE');
update t1 set name = 'changedA' where id = '3';
commit;
exec dbms_wm.gotoworkspace('TESTWSM1');
update t1 set name = 'changedB' where id = '3';
commit;
exec dbms_wm.gotoworkspace('TESTWSM2');
update t1 set name = 'changedC' where id = '3';
commit;
Session 1:
exec dbms_wm.gotoworkspace('LIVE');
update t1 set name = 'changed' where id = '1';
--this is still locked out by session 1
session 2:
exec dbms_wm.gotoworkspace('LIVE');
update t1 set name = 'changed' where id = '2';
Session 1:
rollback;
Session 2:
rollback;
Similar Messages
-
Performance issues with version enable partitioned tables?
Hi all,
Are there any known performance issues with version enable partitioned tables?
Ive been doing some performance testes with a large version enable partitioned table and it seems that OCB optimiser is choosing very expensive plans during merge operations.
Tanks in advance,
Vitor
Example:
Object Name Rows Bytes Cost Object Node In/Out PStart PStop
UPDATE STATEMENT Optimizer Mode=CHOOSE 1 249
UPDATE SIG.SIG_QUA_IMG_LT
NESTED LOOPS SEMI 1 266 249
PARTITION RANGE ALL 1 9
TABLE ACCESS FULL SIG.SIG_QUA_IMG_LT 1 259 2 1 9
VIEW SYS.VW_NSO_1 1 7 247
NESTED LOOPS 1 739 247
NESTED LOOPS 1 677 247
NESTED LOOPS 1 412 246
NESTED LOOPS 1 114 244
INDEX RANGE SCAN WMSYS.MODIFIED_TABLES_PK 1 62 2
INDEX RANGE SCAN SIG.QIM_PK 1 52 243
TABLE ACCESS BY GLOBAL INDEX ROWID SIG.SIG_QUA_IMG_LT 1 298 2 ROWID ROW L
INDEX RANGE SCAN SIG.SIG_QUA_IMG_PKI$ 1 1
INDEX RANGE SCAN WMSYS.WM$NEXTVER_TABLE_NV_INDX 1 265 1
INDEX UNIQUE SCAN WMSYS.MODIFIED_TABLES_PK 1 62
/* Formatted on 2004/04/19 18:57 (Formatter Plus v4.8.0) */
UPDATE /*+ USE_NL(Z1) ROWID(Z1) */sig.sig_qua_img_lt z1
SET z1.nextver =
SYS.ltutil.subsversion
(z1.nextver,
SYS.ltutil.getcontainedverinrange (z1.nextver,
'SIG.SIG_QUA_IMG',
'NpCyPCX3dkOAHSuBMjGioQ==',
4574,
4575
4574
WHERE z1.ROWID IN (
(SELECT /*+ ORDERED USE_NL(T1) USE_NL(T2) USE_NL(J2) USE_NL(J3)
INDEX(T1 QIM_PK) INDEX(T2 SIG_QUA_IMG_PKI$)
INDEX(J2 WM$NEXTVER_TABLE_NV_INDX) INDEX(J3 MODIFIED_TABLES_PK) */
t2.ROWID
FROM (SELECT /*+ INDEX(WM$MODIFIED_TABLES MODIFIED_TABLES_PK) */
UNIQUE VERSION
FROM wmsys.wm$modified_tables
WHERE table_name = 'SIG.SIG_QUA_IMG'
AND workspace = 'NpCyPCX3dkOAHSuBMjGioQ=='
AND VERSION > 4574
AND VERSION <= 4575) j1,
sig.sig_qua_img_lt t1,
sig.sig_qua_img_lt t2,
wmsys.wm$nextver_table j2,
(SELECT /*+ INDEX(WM$MODIFIED_TABLES MODIFIED_TABLES_PK) */
UNIQUE VERSION
FROM wmsys.wm$modified_tables
WHERE table_name = 'SIG.SIG_QUA_IMG'
AND workspace = 'NpCyPCX3dkOAHSuBMjGioQ=='
AND VERSION > 4574
AND VERSION <= 4575) j3
WHERE t1.VERSION = j1.VERSION
AND t1.ima_id = t2.ima_id
AND t1.qim_inf_esq_x_tile = t2.qim_inf_esq_x_tile
AND t1.qim_inf_esq_y_tile = t2.qim_inf_esq_y_tile
AND t2.nextver != '-1'
AND t2.nextver = j2.next_vers
AND j2.VERSION = j3.VERSION))Hello Vitor,
There are currently no known issues with version enabled tables that are partitioned. The merge operation may need to access all of the partitions of a table depending on the data that needs to be moved/copied from the child to the parent. This is the reason for the 'Partition Range All' step in the plan that you provided. The majority of the remaining steps are due to the hints that have been added, since this plan has provided the best performance for us in the past for this particular statement. If this is not the case for you, and you feel that another plan would yield better performance, then please let me know and I will take a look at it.
One suggestion would be to make sure that the table was been recently analyzed so that the optimizer has the most current data about the table.
Performance issues are very hard to fix without a reproducible test case, so it may be advisable to file a TAR if you continue to have significant performance issues with the mergeWorkspace operation.
Thank You,
Ben -
Applying the 10.2.0.4 database patchset with version-enabled tables
We recently applied the 10.2.0.4 database patchset to a database where we had a few version-enabled tables. Applying the patchset took a bit longer than expected and looking through the log, it took about 30 minutes to upgrade Workspace Manager.
1) I know in the past that Workspace Manager patches were separate from database patches. Metalink NOTE:341353.1 "Why does the Workspace Manager version differ from the current RDBMS patchset version" seems to indicate that this is no longer the case,
>
From patchset release V10.2.0.4 onwards, the Oracle Workspace Manager updates are integrated with the generic RDBMS patchsets.
>
But that statement seems to be an afterthought in a document clarifying a separate behavior. Is there another document (Metalink or otherwise) that discusses this change directly?
2) Does anyone have a good feeling for how long applying this and future patchsets should take when there are potentially large version-enabled tables in the system? I am hoping/ assuming that it is not a linear relationship, because the version-enabled tables we have at the moment are rather small. But I don't know whether the upgrade time is basically a constant or whether there is a dependency on the size of the version-enabled tables, the number of version-enabled tables, etc.
I am concerned that we may end up with very large version-enabled tables which would require substantial downtime when we apply future patchsets whether or not we needed the Workspace Manager fixes. I hope/ expect that this is not the case, but thought I would double-check.
JustinHi Justin,
#1. I could not find another document that discusses this, but I may just be missing it. I will see if there is something else, and let you know if I find something.
#2. There is a fixed and variable part of the upgrade for Workspace Manager. The fixed potion recompiles all of the packages/views, modifies metadata tables, etc used directly by Workspace Manager. The other potion is done for each version enabled table. First, the view and triggers maintained by Workspace Manager are rebuilt. This is generally a quick operation as it is not dependent on the size of the table. There is also the potential for data migration for each of the rows of the versioned table. If needed, this would take much longer to complete, but this type of migration has not been needed since about version 9.2. If you are upgrading from a version newer than this, then this part of the migration wold not be necessary.
Regards,
Ben -
Problem with version enabling tables with ric.
Hello,
i have the a problem when i want to version enable tables having ref. int. constraits having delete rule cascade or set null.
Is it possible that i can't version enable the tables because of these constraints? How i could solve this problem if i want to keep the delete rule?
thanks,
Orsi GyulaiHi,
We are internally creating a <table_name>_g procedure that transfers privileges to the necessary users. If you have a table with that name, it would explain the error.
When using ignore_last_error, it will skip the statement that is selected from the all_wm_vt_errors view. Sometimes, the statement can be safely skipped, while in other cases it cannot be. This procedure will always eventually complete when it is repeatedly called with ignore_last_error set to true. However in doing so, some required objects or privileges may not exist or be in an invalid state.
In your case, you most likely had to skip the 3 or so statements that dealt with the <table_name>_g procedure. Typically, these statements should not be skipped, but you may or may not see a problem with it due to a number of factors.
The best course of action may be to drop the trigger in a beginDDL/commitDDL session, and then recreate it in a separate session. Of course, only do this after renaming the <table_name>_g table that you have. Unfortunately, there is currently no way of getting around this naming convention.
Thanks,
Ben -
[ADF-11.1.2] Locking issue with SQL 92
I see one Locking issue with SQL92 Oracle ADF Application.
ADF Version: [ADF-11.1.2]
Database: Oracle 10g Express Edition
Situation 1:
With Following setting:
File: Application Resource > Description > ADF META-INF > adf-config.xml
<startup>
<amconfig-overrides>
<config:Database jbo.SQLBuilder="SQL92" jbo.locking.mode="optimistic"/>
</amconfig-overrides>
</startup>I have a page showing record 'x' of view object. I open same record on another page. Now I have same record showing on two different tabs of browser.
1. I modify first record and save it. It worked... Got commited to database.
2. I goto second tab and modify same record and tried to same it. It throws me an error - Another user has changed the row with primary key oracle.jbo.Key[38 ] . As expected...
3. I then, reopen the same record on 3rd tab of browser. Modify it and tried to save it. It just hang... as if it is processing the record endlessly.
If I see the Log:
<BaseSQLBuilderImpl> <doEntitySelectForAltKey> [312] BaseSQLBuilderImpl Executing doEntitySelect ... (true)
<BaseSQLBuilderImpl> <doEntitySelectForAltKey> [313] Generating new LOCK statement
<BaseSQLBuilderImpl> <buildSelectString> [314] Built select: 'SELECT ID, CI_ID, COLUMN_NAME, DISPLAY_COLUMN_NAME, COLUMN_VALUE, CREATE_DATE, CREATE_BY FROM ESUSER.CI_AUDIT'
<BaseSQLBuilderImpl> <doEntitySelectForAltKey> [315] Executing LOCK "SELECT ID, CI_ID, COLUMN_NAME, DISPLAY_COLUMN_NAME, COLUMN_VALUE, CREATE_DATE, CREATE_BY FROM ESUSER.CI_AUDIT WHERE ID=? FOR UPDATE"
<BaseSQLBuilderImpl> <bindWhereAttrValue> [316] Where binding param 1: 38
That's it.. nothing happens further.. If I execute above query on SQL Worksheet, it doesn't come up with the result. Just hang for something...
SELECT ID, CI_ID, COLUMN_NAME, DISPLAY_COLUMN_NAME, COLUMN_VALUE, CREATE_DATE, CREATE_BY FROM ESUSER.CI_AUDIT WHERE ID='38' FOR UPDATE I can execute above query for other record of same table but not '38'. Even if I fire commit command to database, it is not working.
I have to restart the database services to bring everything to normal state.
Situation 2:
With Oracle as Database :
<startup>
<amconfig-overrides>
<config:Database jbo.SQLBuilder="Oracle" jbo.locking.mode="optimistic"/>
</amconfig-overrides>
</startup>Everything is working file. i.e. at step 3, record is getting modified successfully with following log:
<OracleSQLBuilderImpl> <doEntitySelectForAltKey> [27] OracleSQLBuilder Executing doEntitySelect on: ESUSER.CI_AUDIT (true)
<ADFLogger> <begin> Entity read all attributes
<OracleSQLBuilderImpl> <buildSelectString> [28] Built select: 'SELECT ID, CI_ID, COLUMN_NAME, DISPLAY_COLUMN_NAME, COLUMN_VALUE, CREATE_DATE, CREATE_BY FROM ESUSER.CI_AUDIT CIAudit'
<OracleSQLBuilderImpl> <doEntitySelectForAltKey> [29] Executing LOCK...SELECT ID, CI_ID, COLUMN_NAME, DISPLAY_COLUMN_NAME, COLUMN_VALUE, CREATE_DATE, CREATE_BY FROM ESUSER.CI_AUDIT CIAudit WHERE ID=? FOR UPDATE NOWAIT
<ADFLogger> <addContextData> Entity read all attributes
<OracleSQLBuilderImpl> <bindWhereAttrValue> [30] Where binding param 1: 38
<ADFLogger> <addContextData> Entity read all attributes
<ADFLogger> <end> Entity read all attributes
<ADFLogger> <end> Lock Entity
<ADFLogger> <begin> Before posting the entity's changes
<ADFLogger> <begin> Updating audit columns
<ADFLogger> <end> Updating audit columns
<ADFLogger> <end> Before posting the entity's changes
<OracleSQLBuilderImpl> <doEntityDML> [31] OracleSQLBuilder Executing, Lock 2 DML on: ESUSER.CI_AUDIT (Update)
<OracleSQLBuilderImpl> <buildUpdateStatement> [32] UPDATE buf CIAudit>#u SQLStmtBufLen: 210, actual=60
<OracleSQLBuilderImpl> <doEntityDML> [33] UPDATE ESUSER.CI_AUDIT CIAudit SET COLUMN_VALUE=? WHERE ID=?
<ADFLogger> <begin> Entity DML
<OracleSQLBuilderImpl> <bindUpdateStatement> [34] Update binding param 1: cip7ri1
<OracleSQLBuilderImpl> <bindWhereAttrValue> [35] Where binding param 2: 38
<ADFLogger> <addContextData> Entity DML
<ADFLogger> <end> Entity DML
Can any one please tell me, what is the issue with SQL92 setting ?
Edited by: Anandsagar Sah on Mar 11, 2012 8:10 AMThe framework works correctly in the Situation #1. Please, note that the locking statement in this case is "SELECT ... FOR UPDATE", but not "SELECT ... FOR UPDATE NOWAIT" (as it is in the Situation #2). When you entered the 2nd tab and tried to update the row, then the framework executed the locking statement and the row was locked (and it remained locked because the framework detected that another user had modified the row, so it stopped the processing and no COMMIT operation was executed). When you entered the 3rd tab and tried to update the row, then the framework tried to lock the row againg, but the locking statement was blocked by the existign lock and it started waiting on the lock from the 2nd tab. So this is expected behaviour.
The interesting question is why you do not get any error in the Situation #2. In my opinion you should get an error because the locking statement from the 3rd tab should fail immediately (because the row should have been locked from the 2nd tab and the locking statement is with NOWAIT option). I suspect that when the DB is Oracle and you use Oracle SQLBuilder, then the ADF issues a DB savepoint at the beginning of the DML operation and rolls back to the savepoint is a case of some failure, so the 2nd tab has not left any lock. You can check this by setting on SQL trace on the DB server.
Dimitar -
Serializable transactions and initrans parameter for version enabled tables
Hi,
we want to use serializable transactions when using version enabled tables, so we need to set initrans parameter >= 3 for such tables.
Change made during BEGINDDL - COMMITDDL process is not done for LT table. I think that initrans parameter is not checked at all during BEGINDDL-COMMITDDL process, because skeleton table has initrans=1 even if LT table has different value of this parameter.
-- table GRST_K3_LT has initrans = 1
exec dbms_wm.beginddl('GRST_K3');
alter table grst_k3_lts initrans 3;
exec dbms_wm.commitddl('GRST_K3');
-- table GRST_K3_LT has initrans = 1
During enableversioning this parameter is not changed, so this script succesfully set initrans for versioned tables.
-- table GRST_K3 has initrans = 1
alter table grst_k3 initrans 3;
exec dbms_wm.enableversioning('GRST_K3','VIEW_WO_OVERWRITE');
-- table GRST_K3_LT has initrans = 3
We use OWM 10.1.0.3 version.
We cannot version disable tables. I understand that change can be done after manually disabling trigger NO_WM_ALTER.
Are there any problems with using serializable transactions when reading data in version enabled tables? We will not use serializable transactions for changing data in version enabled tables.
thanks for Your help
Jan VeleÅ¡ÃkHi,
You are correct. We do not currently support the initrans parameter during beginDDL/commitDDL. However, as you indicated, we will maintain any value that is set before enableversioning. If this is a critical issue for you, then please file a TAR and we can look into adding support for it in a future release.
Also, there are no known issues involving serializable transactions on versioned tables.
Thanks,
Ben -
Unable to drop foreign key on a version-enabled table
Hi,
We're using Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit and I'm trying to delete a foreign key from a version-enabled table.
The constraint shows in ALL_WM_RIC_INFO view. I run exec dbms_wm.beginddl('tablename'), when I inspect the generated <tablename>_LTS I don't see any referential integrity constraints generated on that table ? The constraint i'm trying to delete is from a version-enabled table to a non-version enabled table if that makes a difference.
From what I understand the referential integrity constraint would be generated and I would be able to run something like:
ALTER TABLE <tablename>_LTS DROP CONSTRAINT <constraintname>.
I tried running the above statement using the RIC_NAME from ALL_WM_RIC_INFO view but it fails predictably with:
ORA-02443: Cannot drop constraint - nonexistent constraint
Cause: alter table drop constraint <constraint_name>
Action: make sure you supply correct constraint name.as I ran into this today as well I feel like answering this question, as I suppose that the thread opener did the same mistake as I did, and maybe
some others do it as well :)
of course you need to open a DDL session on the parent table as well in order to drop foreign key constraints, just as you do when you add them.
so the correct order to make it work would be:
EXECUTE DBMS_WM.BeginDDL('PARENT_TABLE');
EXECUTE DBMS_WM.BeginDDL('CHILD_TABLE');
ALTER TABLE CHILD_TABLE_LTS
DROP CONSTRAINT FOREIGN_KEY_NAME
EXECUTE DBMS_WM.CommitDDL('CHILD_TABLE');
EXECUTE DBMS_WM.CommitDDL('PARENT_TABLE');I felt kind of stupid that it took me 1 hour to figure this out ;)
regards,
Andreas -
Issue with Update of Table VARINUM
Hi,
I am getting waiting Issues with Update of table VARINUM. Has anybody faced such an issue.
I have a lot of Jobs which are running in background. I am submitting it through a report. what can be the issue.
Regards,
Abhishek jollyThisi is quite old, but not answered properly yet, so there you go:
SAP generates a new job and temporary variant on report RSDBSPJS, for each HTTP call,which creates database locks on table VARINUM .
This causes any heavyweight BSP application to hang and give timeout errors.
The problem is fixed applying OSS note 1791958, which is not included in any service pack. -
Unique constraint violation on version enabled table
hi!
we're facing a strange problem with a version enabled table that has an unique constraint on one column. if we rename an object stored in the table (the name-attribute of the object is the one that has a unique constraint on the respective column) and rename it back to the old name again, we get an ORA-00001 unique constraint violation on the execution of an update trigger.
if the constraint is simply applied as before to the now version enabled table, I understand that this happens, but shouldn't workspace manager take care of something like that when a table with unique constraints is version enabled? (the documentation also says that) because taking versioning into account it's not that we try to insert another object with the same name, it's the same object at another point in time now getting back it's old name.
we somewhat assume that to be a pretty standard scenario when using versioned data.
is this some kind of bug or do we just miss something important here?
more information:
- versioning is enabled on all tables with VIEW_WO_OVERWRITE and no valid time support
- database version is 10.2.0.1.0
- wm installation output:
ALLOW_CAPTURE_EVENTS OFF
ALLOW_MULTI_PARENT_WORKSPACES OFF
ALLOW_NESTED_TABLE_COLUMNS OFF
CR_WORKSPACE_MODE OPTIMISTIC_LOCKING
FIRE_TRIGGERS_FOR_NONDML_EVENTS ON
NONCR_WORKSPACE_MODE OPTIMISTIC_LOCKING
NUMBER_OF_COMPRESS_BATCHES 50
OWM_VERSION 10.2.0.1.0
UNDO_SPACE UNLIMITED
USE_TIMESTAMP_TYPE_FOR_HISTORY ON
- all operations are done on LIVE workspace
any help is appreciated.
EDIT: we found out the following: the table we are talking about is the only table where the unique constraint is left. so there must have been a problem during version enabling. on another oracle installation we did everything the same way and the unique constraint wasn't left there, so everything works fine.
regards,
Andreas Schilling
Message was edited by:
aschillinghi!
we're facing a strange problem with a version enabled table that has an unique constraint on one column. if we rename an object stored in the table (the name-attribute of the object is the one that has a unique constraint on the respective column) and rename it back to the old name again, we get an ORA-00001 unique constraint violation on the execution of an update trigger.
if the constraint is simply applied as before to the now version enabled table, I understand that this happens, but shouldn't workspace manager take care of something like that when a table with unique constraints is version enabled? (the documentation also says that) because taking versioning into account it's not that we try to insert another object with the same name, it's the same object at another point in time now getting back it's old name.
we somewhat assume that to be a pretty standard scenario when using versioned data.
is this some kind of bug or do we just miss something important here?
more information:
- versioning is enabled on all tables with VIEW_WO_OVERWRITE and no valid time support
- database version is 10.2.0.1.0
- wm installation output:
ALLOW_CAPTURE_EVENTS OFF
ALLOW_MULTI_PARENT_WORKSPACES OFF
ALLOW_NESTED_TABLE_COLUMNS OFF
CR_WORKSPACE_MODE OPTIMISTIC_LOCKING
FIRE_TRIGGERS_FOR_NONDML_EVENTS ON
NONCR_WORKSPACE_MODE OPTIMISTIC_LOCKING
NUMBER_OF_COMPRESS_BATCHES 50
OWM_VERSION 10.2.0.1.0
UNDO_SPACE UNLIMITED
USE_TIMESTAMP_TYPE_FOR_HISTORY ON
- all operations are done on LIVE workspace
any help is appreciated.
EDIT: we found out the following: the table we are talking about is the only table where the unique constraint is left. so there must have been a problem during version enabling. on another oracle installation we did everything the same way and the unique constraint wasn't left there, so everything works fine.
regards,
Andreas Schilling
Message was edited by:
aschilling -
Problem by adding one spatial column to the version-enabled table
Hello, I'm trying to modify one version-enabled table T1 like this:
--table definition
create table T1
(ID NUMBER NOT NULL PRIMARY KEY,
NAME VARCHAR2 (256),
FUNCTION VARCHAR2 (256));
--enable versioning
EXECUTE DBMS_WM.EnableVersioning('T1','VIEW_WO_OVERWRITE');
I'd like to add one spatial column to this table by:
-- modify metada view for spatial indexing
INSERT INTO USER_SDO_GEOM_METADATA (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID)
VALUES ('T1_LT', 'ANCHOR',
MDSYS.SDO_DIM_ARRAY
(MDSYS.SDO_DIM_ELEMENT('X', 0.000, 100000.000, 0.0005),
MDSYS.SDO_DIM_ELEMENT('Y', 0.000, 100000.000, 0.0005),
MDSYS.SDO_DIM_ELEMENT('Z', -100, 1000, 0.0005)) , 81989002);
-- table modification - add a column and create a spatial index
EXECUTE DBMS_WM.BeginDDL('T1');
ALTER TABLE T1_LTS ADD ("ANCHOR" MDSYS.SDO_GEOMETRY);
CREATE INDEX T1_SPX on T1_LTS(ANCHOR) INDEXTYPE is MDSYS.SPATIAL_INDEX;
EXECUTE DBMS_WM.CommitDDL('T1');
By finishing of the DDL operation with EXECUTE DBMS_WM.CommitDDL('T1') I get an error message:
"SQL> EXECUTE DBMS_WM.CommitDDL('T1');
BEGIN DBMS_WM.CommitDDL('T1'); END;
ERROR at line 1:
ORA-20171: WM error: 'CREATE TABLE' and 'CREATE SEQUENCE' privileges needed.
ORA-06512: at "SYS.WM_ERROR", line 342
ORA-06512: at "SYS.WM_ERROR", line 359
ORA-06512: at "SYS.LTUTIL", line 8016
ORA-06512: at "SYS.LT", line 11925
ORA-06512: at line 1
What is wrong here? The Oracle 10g DB is installed on Windows 2003 Server, OWM_VERSION - 10.2.0.1.0.
Regards,
ViktorHi,
You need to explicitly grant the create table and create sequence privileges to the user owning the table. It is not enough for these to be granted by using a role. This restriction is documented in the user guide.
Also, you should add the entry in the user_sdo_geom_metadata view on the t1_lts table, which is the table to which you are actually adding the geometry column, after calling beginDDL. CommitDDL will make the necessary changes, which in this case would be to add an entry for both t1 and t1_lt.
Regards,
Ben -
Altering Version enabled tables
Hallo,
i was wondering what happens when you alter an version-enabled table?
I don't find anything about it in the Oracle Workspace Manager infopapers
For instance: I have an table with colums A B C
i add a row1 at time1
Then i delete colum C and add a colum D
i add a row2 at time 2
What do i get when i query the table at time1 and time2 ?
gotodate(time1) -> row1 with ABC ? AB ? ABD? ABCD ? ...
gotodate(time2) -> row2 with ABD ? ABCD ? ...
How does Oracle store this information?
Thanks,
BartHi,
You can't alter versioned tables directly. You need to use the beginDDL/commitDDL procedures. DDL changes are not themselves versioned, so once a change is done, it will apply for all time periods and historical records. So, in your example the table will show columns ABD for all time periods, with either null or default values used for the time periods when the columns did not yet exist. The data from the dropped B column is lost after committing the DDL change.
Regards,
Ben -
Unable to run BeginDDL on a version enabled table on OWM 9.2.0.8
Hello,
We running Oracle 9i with OWM 9.2.0.8
We are trying to run BeginDDL on a version enabled table with approx 2.8 million records
in it. And when we try running the statment:
BEGIN
DBMS_WM.BeginDDL('PFS_SPOT_SHOTS');
END;
We get the following error:
ORA-20203: enable/disable versioning or begin/commitDDL is being executed on PFSDB.PFS_SPOT_SHOTS
ORA-06512: at "WMSYS.OWM_DDL_PKG" line 3378
ORA-06512: at "WMSYS.LT", line 11827
ORA-06512: at line 2
We also try running BeginDDL on another version enabled table with no data in it
BEGIN
DBMS_WM.BeginDDL('PFS_DUMMY_POINT');
END;
then we are getting the following error:
ORA-25150: ALTERING of extent parameters not permitted
ORA-06512: at "WMSYS.OWM_DDL_PKG", line 3378
ORA-06512: at "WMSYS.LT", line 11827
ORA-06512: at line 2
Any suggestions in regards to this problem?
Thanks
Gary1) For the first table PFS_SPOT_SHOTS that we are having trouble with, the query return the following:
select * from wmsys.all_wm_versioned_tables t
where table_name = 'PFS_SPOT_SHOTS';
TABLE_NAME OWNER STATE HISTORY NOTIFICATION NOTIFYWORKSPACES CONFLICT DIFF VALIDTIME
PFS_SPOT_SHOTS PFSDB RB_IND VIEW_WO_OVERWRITE NO NO NO YES
2) For the second table PFS_DUMMY_POINT table, the query return the following:
select * from wmsys.all_wm_versioned_tables t
where table_name = 'PFS_DUMMY_POINT';
TABLE_NAME OWNER STATE HISTORY NOTIFICATION NOTIFYWORKSPACES CONFLICT DIFF VALIDTIME
PFS_DUMMY_POINT PFSDB VERSIONED VIEW_WO_OVERWRITE NO NO NO YES
Other than the PFS_DUMMY_POINT table, the query for other version enabled table also return STATE:VERSIONED except the PFS_SPOT_SHOTS table
We have filed a SR, and the number is : 7599412994
Thank you for your response. -
Issue with data dictionary -Table maintanance generator
Hi all,
I have an issue with Data dictionary, table maintenance generator. I have entered some records in a custom table (ZBCSECROLETOGRP) and changed the delivery class from C to A. When I create the table maintainance generator, I am encountered with the following errors:
1)Field ZBCSECROLETOGRP-PORTALGROUP shortened (new visible length: 000032)
2)0012 could not be generated
3)In TCTRL_ZBCSECROLETOGRP field LENGTH has the invalid value 01
My main motto is to create the table maintainace generator and transport to the furthur systems .
Please help.
ThnX in advance,
Vishal..HI,
Regenerate the table maintenance by selecting the checkbox of "Modified field structure" => new entry & then save.
Also ensure that the new changes are not affecting old data bcz of data type changes. If that is the case, then delete the old records, regenerate table maint. & re-enter those records which you had deleted.
Thanks,
Best regards,
Prashant -
CVC creation - Strange issue with Master data table of 9AMATNR
Hi Experts,
We have encountered a strange issue with Master data table (/BI0/9APMATNR) of info object 9AMATNR.
We have a BADI implemented for checking the valid Characteristic before creation of the CVC using transaction /SAPAPO/MC62. This BADI puts a select on master data tab of material /BI0/9APMATNR and returns no value. But the material actually exists in the table (checked through SE16).
Now we go inside the info object 9AMATNR and go to the Master data Tab. There we go inside the master table
/BI0/9APMATNR and activate that. After activating the table it is read by the select statement inside BADI (Strange) and allows the CVC to be created.
Ideally it should not allow us to activate the SAP standard table /BI0/9APMATNR. I observed that in technical settings of this table it has single record buffering as switched on. (But as per my knowledge buffer gets refreshed every 2 to 4 mins and not in 2 days or something).
Your expert comment is valuable to us. Thanks.
Best Regards,
Chandan DubeyHi Chandan,
Try to use a WAIT statment with 5 seconds before your select statment.
I'm not sure whether this will work. Anyway check it and let me know the result.
Regards,
Siva. -
Serious locking issues with Main Stage 3
Having serious locking issues with main stage 3. I just did a music gig over the weekend with main stage 3, and the application locked up 8 times during my performance. There were also several times where there was a delay between the time I struck a key on the midi controller and the time sound actually came out of the audio interface. Has anyone else ran into this problem??
10.
I am running mountain lion 10.8.5, on a 2009 Macbook 2.53 GHz Intel Core 2 Duo. w 8 GB Ram.
Anyone know how to fix this, if even possible?Just read some reviews. There seems to be a lot of problems with the latest main stage update. I didn't notice these latency problems until did the latest update..
Apple please fix this quickly!!!
Maybe you are looking for
-
I have developed a program using GPIB calls in a multi-threaded environment(max. of 4 threads) using win32 SDK(Labwindows ver 5.5). I am running it as a stand alone application. The application runs fine in a Win-98 system wheras the same application
-
PCI wireless possible? RAM location for 233MHz Power Mac G3?
Hello All! I just added a free Power Mac G3 233MHz to my collection! For fun, I want to install 10.2.8, add 768 MB RAM, 40GB HD, PCI USB 2.0, PCI ATI 9200 and a PCI Macwireless or Aria wireless card. I want to keep the 233MHz CPU! My first question i
-
Function Body Returning Query - Questioning my Approach
Application Express 3.2.0.00.27 Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production I have some concerns that I am not using this in the optimal manner. Essentially I have all my queries in a package body and I call each report as
-
How to combine two or more adobe forms in Java web dynpro
Hi All, I have a scenario where I have few screens each - a separate adobe form. For e.g. One adobe form for item creation, one fore details, one for planning. I need to combine all this into one and save a copy of the PDF. Save PDF option
-
If i update a book in iAuthor, will it automatically update online?
I have shared the book through email - will it automatically update once I make changes for my students?