Chaining in spatial enabled tables

SQL Analyze indicates in a tuning session that there are a considerable amount of chained rows in a table that has a spatial column in it. (47 000 chained rows, returned 712 000 rows)
However, when I analyze the chained rows in the table in an "old" way (analyze table alueet list chained rows;) I only get 11 rows.
Has this mismatch anything to do with Oracle Spatial? In general, should I try to remove chained rows in a spatially enabled table?
Regards,
Pirkko Laurila (dba)

Shawn
The following code snippet will achieve what you want -
create or replace view myviewForLatestInLIVE as
select g.*
from mytable_hist g
where g.workspace = 'LIVE' and
g.retireTime is null;
NOTE: The above view will show all the latest records in the
LIVE workspace i.e. the same records as:
exec dbms_wm.gotoWorkspace('LIVE');
select * from mytable;
Couple of points to note (regarding your view definition) :
With view_wo_overwrite, you can have multiple copies of a row IN
the SAME version. view_w_overwrite will keep only one copy of a
row in a version.
Retire time is NULL when a row is not retired. If a row is
retired, there will ALWAYS be another, newer version of the row
with a NULL for retire time.
For non-LIVE workspaces, to achieve what you want is a little
more involved. The code snippet below will do it -
create or replace view LatestDataFromW1 as
select g.*
from mytable_hist g,
(select i, max(createTime) ct
from mytable_hist
where version in (
select version from all_version_hview
start with version =
(select max(version)
from all_version_hview
where workspace = 'w1')
connect by prior parent_version = version)
group by i ) p
where g.i = p.i and g.createTime = p.ct;
Here the workspace name is w1.
Let me know if you have any other questions / suggestions.
regards
Arun

Similar Messages

  • 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

  • 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

  • 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;

  • Performance issue when inserting into spatial indexed table with JDBC

    We have a table named 'feature' which has a "sdo_geometry" column, and we created spatial index on that column,
    CREATE TABLE feature ( id number, desc varchar, oshape sdo_gemotry)
    CREATE INDEX feature_sp_idx ON feature(oshape) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
    Then we executed the following SQL to insert about 800 records into that table(We tried this by using DB visualizer and
    our Java application, both of them were using JDBC driver to connect to the oracle 11gR2 database) .
    insert into feature(id,desc,oshape) values (1001,xxx,xxxxx);
    insert into feature (id,desc,oshape) values (1002,xxx,xxxxx);
    insert into feature (id,desc,oshape) values (1800,xxx,xxxxx);
    We encoutered the same problem as this topic
    Performance of insert with spatial index
    It takes nearly 1 secs for inserting one record,compare to 50 records inserted per sec without spatial index,
    which is 50x drop in peformance when doing insertion with spatial index.
    However, when we copy and paste those insertion scripts into Oracle Client(same test and same table with spatial index), we got a totally different performance result:
    more than 50 records inserted in 1 secs, just as fast as the insertion without building spatial index.
    Is it because Oracle Client is not using JDBC? Perhaps JDBC was got something wrong when updating those spatial indexed tables.
    Edited by: 860605 on 19/09/2011 18:57
    Edited by: 860605 on 19/09/2011 18:58
    Edited by: 860605 on 19/09/2011 19:00

    Normally JDBC use auto-commit. So each insert can causes a commit.
    I don't know about Oracle Client. In sqlplus, insert is just a insert,
    and you execute "commit" to explicitly commit your changes.
    So maybe this is the reason.

  • 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

  • How to debug "pipelined parallel enable table function" ?

    Dear All,
    Normally we can retrieve output from a "pipelined parallel enable table function " by using SQL statement, such as
    select output from table(pipelined_function(arg1));
    Can anyone alight me how to call this function purely using PL/SQL statement?
    Reason for this : We have third party developer develooped a complicate "pipelined parallel enable table function" and this function is currently calling by SQL (select output from table(pipelined_function(arg1));
    ), I will like to debug this function, but unable to do so, so far I have done :
    1) compile function with debug option
    2) using Procedure Builder to debug, if I execute the above statement (select output from table(pipelined_function(arg1)); I believe, Procedure Builder will not debug a function from a SQL statement
    3) try to build up a PL/SQL block, but don't know how to it.
    basically I want to debug this "pipelined parallel enable table function " and don't know how to do it, any example will be greate!

    user2302827 wrote:
    Using dbms_output is fine but too tedious. I was looking for a PL/SQL procedure builder that can help to debug a statement like this:
    select output from table(pipelined_function(arg1));
    Any suggestion?I don't know about any procedure builders.
    There is a debugger you can use, though I'd have to think about how to invoke it to use with a pipelined function. The debugger is available in GUI tools like SQL*Developer and TOAD and can be used to walk through a program and set values

  • 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

  • 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

  • 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

  • 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

  • Partioning spatially indexed tables

    I am a complete novice when it comes to partitioning, so can someone tell me any advantages/disadvantages/problems in partitioning a large RTREE spatially indexed table (using an SDO_GEOMETRY column) containing several million rows?

    Just to make sure you understand what is and isn't possible:
    When partitioning a table with spatial data, you cannot partition based on the geometry column.
    Spatial index partitioning is only available on a table that has been partitioned by range.
    All of the manageability benefits associated with partitioning data applies to data with a spatial column as well. If the index has been built using partitioning, you can do things like store different index partitions in different tablespaces, index partition rebuilds, index partition archives, exchange, split, merge partitions, etc.
    In terms of performance, there are several benefits that can be achieved:
    If the partition key can be specified as a predicate on the query, then there can be a large performance improvement.
    If you can't specify a partition key in the query, then if the index is stored across different tablespaces then concurrency can improve if multiple sessions are accessing the index.
    Single stream performance can be improved through the use of parallelism as well.
    Most of the above is available in 9iR1, although exchange partition and parallelism both were available as of 9iR2.
    If there is no parallelism, and no partition key predicate can be specified in spatial queries, and there is only single session access to the database, and you don't need the manageability benefits, then partitioning probably isn't for you.

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

  • How to backup flashback data archive enabled tables -oracle 11g?

    1) Whether the flashback data archive can be backed up using the following options in oracle? Any pointer from the documentation would be much appreciated.
         RMAN
         Data pump
    2) How to move the flashback data archive table from one database to another? The reason why I am asking this question is that the history data for flashback data archive table is managed by undo tablespace. In this case, if I simply export the flashback data archive enabled tables to another database, will I able to view the history information?
    Regards,
    Richard

    Hi Morgan,
    Thanks for your response. Our intention is that to configure the total recall feature in the reporting instance for historical data view. Let's say , we are mining the changed data from the OLTP instance to reporting instance via logical standby. In this case, the history data will be maintained in the reporting instance?
    Regards,
    Richard

  • History Enabled Table

    How do I create a History enabled table via the HANA Script. I went through the development guide and do not find any mention of a parameter to enable History ? Is this functionality available via the SQL Console Only ?

    How do I create a History enabled table via the HANA Script. I went through the development guide and do not find any mention of a parameter to enable History ? Is this functionality available via the SQL Console Only ?

Maybe you are looking for

  • ERROR: DF024: Adobe Media Encoder CS6

    I Have a 2012 Mac Pro running Mavericks.  I started having issues with Premiere Pro after video card upgrade.  I get the following error message when trying to reinstall CS6 Production Premium: Exit Code: 6 Please see specific errors below for troubl

  • Problem with Safari being blocked by ***.a2ztech.us

    Safari is blocked, getting msg: ***.a2ztech.us Warning ! Your email account has been temporary suspended due to suspicious activity. This may be due to infections on your computer. Please call 0800-610-1013 for immediate support! Tried to reset Safar

  • New Logic Board = Significanlty Slower Mac

    Recently I had my Macbook Pro shipped off for repairs for a number of problems I've had with it, and they ended up replacing the battery, superdrive, logic board, and display wiring. Since I've gotten back, my mac is noticeably slower. Boot up time h

  • Passing parameter in report for order by clause

    how can we pass the name of the column on which we want the order by clause to sort as a parameter through parameter from in a report??

  • IPod has different dates than iCal

    I have a problem with how my 4th Gen iPod and Nano sync with iCal. Some - not all - of the appointments get moved around. I have a series of recurring appointments on Thursday in iCal that show up on Wednesday on both iPods. I have synce'ed the iPods