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Å¡Ãk

Hi,
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

Similar Messages

Re: Transactions and Locking Rows for Update

Dale,
Sounds like you either need an "optimistic locking" scheme, usually
implemented with timestamps at the database level, or a concurrency manager.
A concurrency manager registers objects that may be of interest to multiple
users in a central location. It takes care of notifying interested parties
(i.e., clients,) of changes made to those objects, using a "notifier" pattern.
The optimistic locking scheme is relatively easy to implement at the
database level, but introduces several problems. One problem is that the
first person to save their changes "wins" - every one else has to discard
their changes. Also, you now have business policy effectively embedded in
the database.
The concurrency manager is much more flexible, and keeps the policy where
it probably belongs. However, it is more complex, and there are some
implications to performance when you get to the multiple-thousand-user
range because of its event-based nature.
Another pattern of lock management that has been implemented is a
"key-based" lock manager that does not use events, and may be more
effective at managing this type of concurrency for large numbers of users.
There are too many details to go into here, but I may be able to give you
more ideas in a separate note, if you want.
Don
At 04:48 PM 6/5/97 PDT, Dale "V." Georg wrote:
I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save'button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for any ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
>
>
>
>
====================================
Don Nelson
Senior Consultant
Forte Software, Inc.
Denver, CO
Corporate voice mail: 510-986-3810
aka: [email protected]
====================================
"I think nighttime is dark so you can imagine your fears with less
distraction." - Calvin

We have taken an optimistic data locking approach. Retrieved values are
stored as initial values; changes are stored seperately. During update, key
value(s) or the entire retieved set is used in a where criteria to validate
that the data set is still in the initial state. This allows good decoupling
of the data access layer. However, optimistic locking allows multiple users
to access the same data set at the same time, but then only one can save
changes, the rest would get an error message that the data had changed. We
haven't had any need to use a pessimistic lock.
Pessimistic locking usually involves some form of open session or DBMS level
lock, which we haven't implemented for performance reasons. If we do find the
need for a pessimistic lock, we will probably use cached data sets that are
checked first, and returned as read-only if already in the cache.
-DFR
Dale V. Georg <[email protected]> on 06/05/97 03:25:02 PM
To: Forte User Group <[email protected]> @ INTERNET
cc: Richards* Debbie <[email protected]> @ INTERNET, Gardner*
Steve <[email protected]> @ INTERNET
Subject: Transactions and Locking Rows for Update
I have a problem in the application I am currently working on, which it
seems to me should be easily solvable via appropriate use of transactions
and database locking, but I'm having trouble figuring out exactly how to
do it. The database we are using is Oracle 7.2.
The scenario is as follows: We have a window where the user picks an
object from a dropdown list. Some of the object's attributes are then
displayed in that window, and the user then has the option of editing
those attributes, and at some point hitting the equivalent of a 'save' button
to write the changes back to the database. So far, so good. Now
introduce a second user. If user #1 and user #2 both happen to pull up
the same object and start making changes to it, user #1 could write back
to the database and then 15 seconds later user #2 could write back to the
database, completely overlaying user #1's changes without ever knowing
they had happened. This is not good, particularly for our application
where editing the object causes it to progress from one state to the next,
and multiple users trying to edit it at the same time spells disaster.
The first thing that came to mind was to do a select with intent to update,
i.e. 'select * from table where key = 'somevalue' with update'. This way
the next user to try to select from the table using the same key would not
be able to get it. This would prevent multiple users from being able to
pull the same object up on their screens at the same time. Unfortunately,
I can think of a number of problems with this approach.
For one thing, the lock is only held for the duration of the transaction, so
I would have to open a Forte transaction, do the select with intent to
update, let the user modify the object, then when they saved it back again
end the transaction. Since a window is driven by the event loop I can't
think of any way to start a transaction, let the user interact with the
window, then end the transaction, short of closing and re-opening the
window. This would imply having a separate window specifically for
updating the object, and then wrapping the whole of that window's event
loop in a transaction. This would be a different interface than we wanted
to present to the users, but it might still work if not for the next issue.
The second problem is that we are using a pooled DBSession approach
to connecting to the database. There is a single Oracle login account
which none of the users know the password to, and thus the users
simply share DBSession resources. If one user starts a transaction
and does a select with intent to update on one DBSession, then another
user starts a transaction and tries to do the same thing on the same
DBSession, then the second user will get an error out of Oracle because
there's already an open transaction on that DBSession.
At this point, I am still tossing ideas around in my head, but after
speaking with our Oracle/Forte admin here, we came to the conclusion
that somebody must have had to address these issues before, so I
thought I'd toss it out and see what came back.
Thanks in advance for
any
ideas!
Dale V. Georg
Indus Consultancy Services [email protected]
Mack Trucks, Inc. [email protected]
------ Message Header Follows ------
Received: from pebble.Sagesoln.com by notes.bsginc.com
(PostalUnion/SMTP(tm) v2.1.9c for Windows NT(tm))
id AA-1997Jun05.162418.1771.334203; Thu, 05 Jun 1997 16:24:19 -0500
Received: (from sync@localhost) by pebble.Sagesoln.com (8.6.10/8.6.9) id
NAA11825 for forte-users-outgoing; Thu, 5 Jun 1997 13:47:58 -0700
Received: (from uucp@localhost) by pebble.Sagesoln.com (8.6.10/8.6.9) id
NAA11819 for <[email protected]>; Thu, 5 Jun 1997 13:47:56 -0700
Received: from unknown(207.159.84.4) by pebble.sagesoln.com via smap (V1.3)
id sma011817; Thu Jun 5 13:47:43 1997
Received: from tes0001.macktrucks.com by relay.macktrucks.com
via smtpd (for pebble.sagesoln.com [206.80.24.108]) with SMTP; 5 Jun
1997 19:35:31 UT
Received: from dale by tes0001.macktrucks.com (SMI-8.6/SMI-SVR4)
id QAA04637; Thu, 5 Jun 1997 16:45:51 -0400
Message-ID: <[email protected]>
Priority: Normal
To: Forte User Group <[email protected]>
Cc: "Richards," Debbie <[email protected]>,
"Gardner," Steve <[email protected]>
MIME-Version: 1.0
From: Dale "V." Georg <[email protected]>
Subject: Transactions and Locking Rows for Update
Date: Thu, 05 Jun 97 16:48:37 PDT
Content-Type: text/plain; charset=US-ASCII; X-MAPIextension=".TXT"
Content-Transfer-Encoding: quoted-printable
Sender: [email protected]
Precedence: bulk
Reply-To: Dale "V." Georg <[email protected]>

How set and get parameter for a session of a portlet (Java)

I would like get parameter and set parameter for a portlet in portal 9.02. This parameter must be availbale during the session of the portal.
With Java Servlet
// I retrieve my session
HttpServletRequest httpreq = (HttpServletRequest)req;
HttpServletResponse httpresp = (HttpServletResponse)resp;
HttpSession session = httpreq.getSession();
//And after i can get or set some parameter for this servlet
//Example
session.setAttribute("MyEmployeeNumber","600000");
String id = (String)session.getAttribute("MyEmployeeNumber");
// But with Portlet in portal, i can't do it.
PortletRenderRequest pr= (PortletRenderRequest)httpreq.getAttribute(HttpCommonConstants.PORTLET_RENDER_REQUEST);
String sUser=pr.getUser().getName();
ProviderSession session=pr.getSession();
// But after if i want get or set a value in this session i have a internal error 500
session.setAttribute("MyEmployeeNumber","600000");
I would like my parameter is avalaible during a session for a user in each page of the portal, because my portlet is on each page.

I have almost the same problem. I tried as you suggested, but it doesn't work yet.
provider.xml
<session>true</session>
<passAllUrlParams>true</passAllUrlParams>
My code in my jsp-portlet is
<%@page contentType="text/html; charset=windows-1252"
import="oracle.portal.provider.v2.render.PortletRenderRequest"
import="oracle.portal.provider.v2.render.PortletRendererUtil"
import="oracle.portal.provider.v2.http.HttpCommonConstants"
import="oracle.portal.provider.v2.ParameterDefinition"
import="oracle.portal.provider.v2.render.http.HttpPortletRendererUtil"
%>
<%@page session="true"%>
<%
PortletRenderRequest pReq = (PortletRenderRequest)request.getAttribute(HttpCommonConstants.PORTLET_RENDER_REQUEST);
String valueSession = (String)pReq.getAttribute("sesion");
if (valueSession != null) {
pReq.setAttribute("session", "value1");
out.println("<br>(1)valueSession != null");
out.println("<br>(1)valueSession : " + pReq.getAttribute("session"));
} else {
pReq.setAttribute("session", "value2");
out.println("<br>(2)valueSession == null");
out.println("<br>(2)valueSession : " + pReq.getAttribute("session"));
%>
And i always get as result:
(2)valueSession == null
(2)valueSession : value2
Even when i send values (post) at the same page or browsing between tabs:
I check my provider registration and it has the value "once per session"
I have portal 9.0.2.2.14
Thanks

Can we hav call transaction and session method for an application

can we hav call transaction and session method for an application ?if yes how?

Hi ,
You can. If Call Transaction fails, a batch input session can be created.
Check this example-
Call the transaction. Messages from Call Transaction are stored in the
internal table messtab
CALL TRANSACTION 'LT01' USING bdc_tab MODE 'N' UPDATE 'S'
      MESSAGES INTO messtab.
IF sy-subrc = 0.
Call transaction successfull, get the number of the Transfer Order that
was created
    LOOP AT messtab.
      IF messtab-dynumb = '0104' AND messtab-msgnr = '016'.
        w_transportorderno = messtab-msgv1.
      ENDIF.
    ENDLOOP.
ELSE.
Call transaction failed, create a batch input session instead.
    PERFORM open_group.
    PERFORM bdc_insert USING 'LT01'.
    PERFORM close_group.
ENDIF.
Regards,
Sookshma

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;

Creation of a generic extractor and data source for the FAGLFLEXA table

Hi All,
Need to create a generic extractor and data source for the FAGLFLEXA table to support AR reporting. This table contains the necessary profit center information to perform LOB reporting against the AR data.
Please advice on how to do this.
Regards, Vishal

Hi Vishal,
Its seems a simple a work out.
1.Go to RSO2 & choose the relevant option ie. whether you want to create Transactional DS, Master Data DS or Text DS.
2. Name it accordingly & then create.
3. Give description to it & then give table name FAGLFLEXA.
4. Save it & activate. If you need it to be delta enabled then click over Delta & you can choose accordingly.
If you still face some problem then do mail me at [email protected]
Assign points if helpful
Regards,
Himanshu

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,
Viktor

Hi,
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

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.
Justin

Hi 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

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,
Bart

Hi,
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
Gary

1) 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.

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

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:
aschilling

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:
aschilling

Error in database parameter for star schema table in RSRV

Hi Experts,
In RSRV, I executed the following checks in my cube and it is showing me the following error:-
1) Check database parameter for star schema table for InfoCube ZMM_MVAL
564971 units missing from fact table /BIC/FZMM_MVAL; see details
Message no. RSRV134
Diagnosis
In the fact table /BIC/FZMM_MVAL records have been found that contain values other than zero for key figures that have units, but that have no value for the unit of the key figure. Since the value of the unit has to correspond to the value of the key figure, this inidicates an error when the data was loaded. The values of the units have not been loaded into BW correctly. Choose Details to display the incorrect records.
2) Consistency of time dimension of InfoCube ZMM_MVAL
/BIC/FZMM_MVAL PARTITIONED 1878 ( 30 - 50 )
Please advise me on this.
Thanks in Advance.
Aparna

As mentioned in the log, check the Unit KFs in your cube and make sure that unit is populated for all such values.
e.g. if Qty is 5 KG, then unit KF will have 5 and unit info object should have KF.
Regards,
Gaurav

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 Gyulai

Hi,
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

How to find unsued Transfer Rules and Data Sources for a Master Table...??

How to find unsued Transfer Rules and Data Sources for a Master Table...?? My requirement is i need to delete those Transfer rules and Data Sources which are not in use

Hi
Go to manage of the Text or attirbute of the master data object, see what are being loaded daily from there and delete the remaining.
Cheer
Ans as expected, Please reward

Serializable transactions and initrans parameter for version enabled tables

Similar Messages

Maybe you are looking for