Commit after alter table statement or not?

Hi,
Is it necessary to put the a commit after the following statement or is it automatically committed:
Alter table tab_name drop column col_name;
Thanks

Khurram,
Isnt Eric you are , i mean isnt yours synonym :)Erm...simple answer. No. We are not the same person. I just know that Eric, like yourself, makes good contributions to these threads and then someone like that is coming on the forums and trying to make himself look better and put down the regular contributors which isn't really on is it, I think you'll agree.
CREATE PUBLIC SYNONYM Eric FOR Blushadow;
hehe.

Similar Messages

  • SAP HANA - How to run alter table statement in HANA procedure?

    I am trying to run alter table statement in a procedure. HANA gives error saying
    SAP DBTech JDBC: [257] (at 1338): sql syntax error: ALTER TABLE is not allowed in SQLScript: line 36 col 8 (at pos 1338)
    How to run alter table statements in procedure?
    Thanks,
    Suren.

    Hi Rich Heilman,
    Thanks for your response.  I have tried with dynamic SQL. I am trying to add partitions to a non portioned table.
    EXECUTE IMMEDIATE 'ALTER TABLE ' || :SCHEMA_NAME || '.TARGET_TABLE PARTITION BY RANGE (TARGET_TYPE_ID) (PARTITION VALUE = 1, PARTITION VALUE = 2, PARTITION VALUE = 3, PARTITION VALUE = 4, PARTITION OTHERS)';
    Execution fails with error
    Could not execute 'CALL PARTITION_TARGET_TABLE('SUREN_TEST')' in 1.160 seconds .
    [129]: transaction rolled back by an internal error:  [129] "SUREN_TEST"."PARTITION_TARGET_TABLE": line 53 col 3 (at pos 2173): [129] (range 3)
    Any reasons for this error?
    Thanks,
    Suren.

  • Performance for ALTER TABLE statements

    Hi,
    I'd like to improve performance for scripts running several ALTER TABLE statements. I have two questions regarding this.
    This is the original code:
    ALTER TABLE CUSTOMER_ORDER_DELIVERY_TAB ADD (
    QTY_TO_INVOICE NUMBER NULL );
    ALTER TABLE CUSTOMER_ORDER_DELIVERY_TAB ADD (
    QTY_INVOICED NUMBER NULL );
    1. Would I gain any performance by making the following changes?
    ALTER TABLE CUSTOMER_ORDER_DELIVERY_TAB ADD (
    QTY_TO_INVOICE NUMBER NULL,
    QTY_INVOICED NUMBER NULL );
    These columns are later on filled with values and then made NOT NULL.
    2. Would I gain anything by make these columns NOT NULL with a DEFAULT value in the first statement and then later on insert the values?
    /Roland Bali
    null

    1. It wud definitely increase the performance.
    2. You can only have NOT NULL columns added to an existing table if the table is empty.
    <BLOCKQUOTE><font size="1" face="Verdana, Arial, Helvetica">quote:</font><HR>Originally posted by Roland Bali ([email protected]):
    Hi,
    I'd like to improve performance for scripts running several ALTER TABLE statements. I have two questions regarding this.
    This is the original code:
    ALTER TABLE CUSTOMER_ORDER_DELIVERY_TAB ADD (
    QTY_TO_INVOICE NUMBER NULL );
    ALTER TABLE CUSTOMER_ORDER_DELIVERY_TAB ADD (
    QTY_INVOICED NUMBER NULL );
    1. Would I gain any performance by making the following changes?
    ALTER TABLE CUSTOMER_ORDER_DELIVERY_TAB ADD (
    QTY_TO_INVOICE NUMBER NULL,
    QTY_INVOICED NUMBER NULL );
    These columns are later on filled with values and then made NOT NULL.
    2. Would I gain anything by make these columns NOT NULL with a DEFAULT value in the first statement and then later on insert the values?
    /Roland Bali<HR></BLOCKQUOTE>
    Naveen

  • Alter Table Statements in Designer

    Hi Guys,
    Just wondering if anyone knows if it's possible to store Alter Table statements in Designer 9i?
    Anton

    Hi,
    The designer generate alter statements for you.
    e.g You have a table emp with empno number(8) in designer and in your application database. You cahnged empno to number(12) in designer. Generate ddl pointing to your application database. Designer generate an ALTER table script for you.

  • Why Oracle not using the correct indexes after running table stats

    I created an index on the table and ran the a sql statement. I found that via the explain plan that index is being used and is cheaper which I wanted.
    Latter I ran all tables stats and found out again via explain plan that the same sql is now using different index and more costly plan. I don't know what is going on. Why this is happening. Any suggestions.
    Thx

    I just wanted to know the cost using the index.
    To gather histograms use (method_opt is the one that causes the package to collect histograms)
    DBMS_STATS.GATHER_SCHEMA_STATS (
    ownname => 'SCHEMA',
    estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
    block_sample => TRUE,
    method_opt => 'FOR ALL COLUMNS SIZE AUTO',
    degree => 4,
    granularity => 'ALL',
    cascade => TRUE,
    options => 'GATHER'
    );

  • Alter Table Add column not null default value

    I want to add two columns to a table with not null and default as 0 for both columns
    Can i write the whole in one statement or do i have to split statement
    I tried this, but didn't work
    alter table DWSODS01.DWT00301_ORD_DTL_OMS add (
    COMB_ORD_FLG NUMBER(5,0) default 0 not null,
    COMB_ORD_NO NUMBER(12,0)
    default 0 not null);
    How can i modify the code?

    user10390682 wrote:
    I tried this, but didn't workSince you are specifying default values, it should work (regardless if table DWSODS01.DWT00301_ORD_DTL_OMS is empty or not):
    SQL> select count(*) from emp1
      2  /
      COUNT(*)
            14
    SQL> alter table emp1 add (
      2  COMB_ORD_FLG NUMBER(5,0) default 0 not null,
      3  COMB_ORD_NO NUMBER(12,0)
      4  default 0 not null);
    Table altered.
    SQL> desc emp1
    Name                                      Null?    Type
    EMPNO                                              NUMBER(4)
    ENAME                                              VARCHAR2(10)
    JOB                                                VARCHAR2(9)
    MGR                                                NUMBER(4)
    HIREDATE                                           DATE
    SAL                                                NUMBER(7,2)
    COMM                                               NUMBER(7,2)
    DEPTNO                                             NUMBER(2)
    COMB_ORD_FLG                              NOT NULL NUMBER(5)
    COMB_ORD_NO                               NOT NULL NUMBER(12)
    SQL> What error are you getting?
    SY.

  • Multiple Alter Table Statements in one batch

    Hi Team,
    We have in one of our upcoming release two columns being added to a table that has over 20 million records and 14 indexes.
    We needed to add two columns to the table both not null (bit). Because it was taking a while to add the columns, we thought that putting these two alter statements in one batch would speed up the operation significantly but to my surprise it did not.
    Conclusion from my test: individual alter statements or batch alter statements take the same time
    Here are me test and results - table Order1 and Order2 are exactly the same structure and data.
    Test case 1:
    ===================
    ALTER TABLE Order1
    ADD OR_N BIT DEFAULT 0 NOT NULL
    go
    ALTER TABLE AccountTradeConfirmation_Alter1
    ADD OR_S BIT DEFAULT 0 NOT NULL
    Go
    Elapsed Time: 2 hrs
                 Mar 18 2015 5:56PM
    (1 row affected)
    Non-clustered index (index id = 3) is being rebuilt.
    Non-clustered index (index id = 4) is being rebuilt.
    Non-clustered index (index id = 5) is being rebuilt.
    Non-clustered index (index id = 6) is being rebuilt.
    Non-clustered index (index id = 7) is being rebuilt.
    Non-clustered index (index id = 8) is being rebuilt.
    Non-clustered index (index id = 9) is being rebuilt.
    Non-clustered index (index id = 10) is being rebuilt.
    Non-clustered index (index id = 11) is being rebuilt.
    Non-clustered index (index id = 12) is being rebuilt.
    Non-clustered index (index id = 13) is being rebuilt.
    Non-clustered index (index id = 14) is being rebuilt.
    (21777920 rows affected)
    Non-clustered index (index id = 3) is being rebuilt.
    Non-clustered index (index id = 4) is being rebuilt.
    Non-clustered index (index id = 5) is being rebuilt.
    Non-clustered index (index id = 6) is being rebuilt.
    Non-clustered index (index id = 7) is being rebuilt.
    Non-clustered index (index id = 8) is being rebuilt.
    Non-clustered index (index id = 9) is being rebuilt.
    Non-clustered index (index id = 10) is being rebuilt.
    Non-clustered index (index id = 11) is being rebuilt.
    Non-clustered index (index id = 12) is being rebuilt.
    Non-clustered index (index id = 13) is being rebuilt.
    Non-clustered index (index id = 14) is being rebuilt.
    (21777920 rows affected)
                 Mar 18 2015 7:52PM
    Test case 2:
    ===================
    ALTER TABLE Order2
    ADD OR_N BIT DEFAULT 0 NOT NULL, OR_S BIT DEFAULT 0 NOT NULL
    go
    2 hrs elapsed time
                 Mar 20 2015 11:10AM
    (1 row affected)
    Non-clustered index (index id = 3) is being rebuilt.
    Non-clustered index (index id = 4) is being rebuilt.
    Non-clustered index (index id = 5) is being rebuilt.
    Non-clustered index (index id = 6) is being rebuilt.
    Non-clustered index (index id = 7) is being rebuilt.
    Non-clustered index (index id = 8) is being rebuilt.
    Non-clustered index (index id = 9) is being rebuilt.
    Non-clustered index (index id = 10) is being rebuilt.
    Non-clustered index (index id = 11) is being rebuilt.
    Non-clustered index (index id = 12) is being rebuilt.
    Non-clustered index (index id = 13) is being rebuilt.
    Non-clustered index (index id = 14) is being rebuilt.
    (21777920 rows affected)
                 Mar 20 2015 1:12PM

    Hi Kiran,
    I have read your response a few times and I was not able to understand your angle. I assume based on the results of my test that Sybase does the following in processing the alter statements
    ALTER TABLE Order2
    ADD OR_N BIT DEFAULT 0 NOT NULL, OR_S BIT DEFAULT 0 NOT NULL
    go
    process alter ADD OR_N BIT
    -- > make copy of table
    ---> alter original table
    --> put data back in
    process alterOR_S BIT
    -- > make copy of table
    ---> alter original table
    --> put data back in
    rebuild index
    my expectation was that it would make a copy of the table only once and process the two alter statements. Also when doing the alter separately (test1) it rebuilt the index twice, however using the batch the index was rebuilt once (at least only one message displayed).
    Regards.

  • Poor performance after altering tables to InnoDB

    I have an application using CF MX, IIS, and MySQL 5.0.37
    running on Microsoft Windows Server 2003.
    When I originally built the application, access from login to
    start page and page to page was very good. But, I started getting
    errors because tables were sometimes getting records added or
    deleted and sometimes not. I thought the "cftransaction" statements
    were protecting my transactions. Then I found out about MyISAM (the
    default) vs InnoDB.
    So, using MySQLAdmin, I altered the tables to InnoDB. Now,
    the transactions work correctly on commits and rollbacks, but the
    performance of the application stinks. It now takes 20 seconds to
    log in.
    The first page involves a fairly involved select statement,
    but it hasn't changed at all. It just runs very slowly. Updates
    also run slowly.
    Is there something else I was supposed to do in addition to
    the "alter table" in this environment? The data tables used to be
    in /data/saf_data. Now the ibdata file and log files are in /data
    and only the ".frm" files are still in saf_data.
    I realize I'm asking this question in a CF forum. But, people
    here are usually very knowledgable and helpful and I'm desperate.
    This is a CF application. Is there anything I need to do for a CF
    app to work well with MySQL InnoDB tables? Any configuration or
    location stuff to know about?
    Help, and Thanks!

    The programs was ported also in earlier versions 1,5 year ago we use forte 6.2 and the performance was o.k.
    Possibly the program design was based on Windows
    features that are inappropriate for Unix. So the principal design didn't change, the only thing is, that we switch to the boost libraries, where we use the thread, regex, filesystem and date-time libraries
    Have you tried any other Unix-like system? Linux, AIX, HPUX,
    etc? If so, how does the performance compare to
    Solaris?Not at the moment, because the order is customer driven, but HP and Linux is also an option.
    Also consider machine differences. For example, your
    old Ultra-80 system at 450Mhz will not keep up with a
    modern x86 or x64 system at 3+ GHz. The clock speed
    could account for a factor of 6. That was my first thought, but how I have wrote in an earlier post, the performance testcase need the same time on a 6x1GHz (some Sun-Fire-T1000) machine
    Also, how much realmemory does the sparc system have? 4 GB! And during the testrun the machine use less than 30% of this memory.
    If the program is not multithreaded, the additional
    processors on the Ultra-80 won't help. But it is!
    If it is multithreaded, the default libthread or libpthread on
    Solaris 8 does not give the best performance. You can
    link with the alternative lwp-based thread library on
    Solaris 8 by adding the link-time option
    -R /usr/lib/lwp (for 32-bit applications)
    -R /usr/lib/lwp/64 (for 64-bit applications)The running application use both, the thread and the pthread library can that be a problem? Is it right, that the lwp path include only the normal thread library?
    Is there a particular reason why you are using the
    obsolete Solaris 8 and the old Sun Studio 10?Because we have customer which do not upgrade? Can we develop on Solaris 10 with SunStudio 11and deploy on 5.8 without risk?
    regards
    Arno

  • Difference between alter table statements to add primary keys

    Hi,
    Can someone explain what the difference between these 2 statements are and if & when one should be used over the other?
    Also, are the brackets around the column name necessary?
    Thanks!
    ALTER TABLE xyz ADD CONSTRAINT id_pk PRIMARY KEY (id);
    ALTER TABLE xyz ADD PRIMARY KEY (id);

    Hi,
    As every one has explained that there is no difference in the actual functioning of the two constraints except that the first statement will create Primary Key constraint with user defined name as id_pk whereas in the second statement Primary key will be created with system generated name like SYS....
    Normally name for the constraints are needed when you are working on constraints like need to enable or disable the constraints or need to drop the constraints.
    We can say that names for primary key are least required when it comes to the usage except better recognization.
    Because we can drop primary key, disable primary key,enable primary key without giving the name for the primary key as there can only be one primary key in the table. So not much an issue with the name.
    But as earlier post say its better than nothing,, i will add to it that its almost same as that with names constrained in case of Primary Keys taking into account the usage of the named primary key.
    Regards

  • Hello experts read table statement is not working properly

    Hello Experts.
    my code is like this.
    sort it_matnr by matnr.
    loop at itab_result.
    read table it_matnr with key matnr = itab_result-matnr  binary search.
    endloop.
    there are nearly 2000 records in it_matnr . The records which satisfy the above condition is there here in this internal table. But it is unable to read the record which matches the condition. One thing is that , there are more than one record with the same material. ie mblnr is different but material is the same. In it_matnr table i have only 1 field ie matnr ,so i need to compare only with the matnr.I also tried by sorting it_result by matnr but of no use. Then finally I used loop at where matnr = it_result-matnr , it is working fine. But due to performance reasons we should not use this. so please tell me what to do and correct the code.

    1. Make sure that the table IT_MATNR is not getting updated inside the loop. Because it will then destroy the sorting.
    2. Secondly, if there are multiple records in IT_MATNR for the same material then it will search for the first record encountered in binary algo. So it is advisable that you may provide further filter criteria if possible. check if ITAB_RESULT & IT_MATNR have any other matching field that can be put in filter criteria.
    3.Thirdly, check if your requirement can be achieved by STABLE SORT.
    <b>SORT <itab> ... STABLE BY <f1>[ASCENDING/DESCENDING].</b>
    It will allows you to perform a stable sort, that is, the relative sequence of lines that are unchanged by the sort is not changed. If you do not use the STABLE option, the sort sequence is not preserved. If you sort a table several times by the same key, the sequence of the table entries will change in each sort. However, a stable sort takes longer than an unstable sort.
    4. Lastly, you can use parallel cursor technique of multiple loops which is given below:
    LOOP AT itab_result.
      READ TABLE it_matnr
        WITH KEY matnr = itab_result-matnr
        BINARY SEARCH.
    Process record
      LOOP AT it_matnr FROM sy-tabix.
        IF it_matnr <> itab_result-matnr.
          EXIT.
        ENDIF.
    Process record based on yuor condition
      ENDLOOP.
    ENDLOOP.

  • Table compression and alter table statement

    Friends
    I am trying to add columns to a table which is compressed. Since Oracle treats compressed tables as Object tables, I cannot add columns directly so I tried to uncompress table first and then add columns. This doesnt seems to work.
    What could be issue.
    Thanks
    Vishal V.
    Script to test is here and results are below.
    -- Test1 => add columns to uncompressed table -> Success
    DROP TABLE TAB_COMP;
    CREATE TABLE TAB_COMP(ID NUMBER) NOCOMPRESS;
    ALTER TABLE TAB_COMP ADD (NAME VARCHAR2(10));
    -- Test2 =. try adding columns to compressed tables, uncompress it and then try again -> Fails
    DROP TABLE TAB_COMP;
    CREATE TABLE TAB_COMP(ID NUMBER) COMPRESS;
    ALTER TABLE TAB_COMP ADD (NAME VARCHAR2(10));
    ALTER TABLE TAB_COMP move NOCOMPRESS;
    ALTER TABLE TAB_COMP ADD (NAME VARCHAR2(10));
    SQL> -- Test1 => add columns to uncompressed table -> Success
    SQL> DROP TABLE TAB_COMP;
    Table dropped.
    SQL> CREATE TABLE TAB_COMP(ID NUMBER) NOCOMPRESS;
    Table created.
    SQL> ALTER TABLE TAB_COMP ADD (NAME VARCHAR2(10));
    Table altered.
    SQL>
    SQL> -- Test2 =. try adding columns to compressed tables, uncompress it and then try again -> Fails
    SQL> DROP TABLE TAB_COMP;
    Table dropped.
    SQL> CREATE TABLE TAB_COMP(ID NUMBER) COMPRESS;
    Table created.
    SQL> ALTER TABLE TAB_COMP ADD (NAME VARCHAR2(10));
    ALTER TABLE TAB_COMP ADD (NAME VARCHAR2(10))
    ERROR at line 1:
    ORA-22856: cannot add columns to object tables
    SQL> ALTER TABLE TAB_COMP move NOCOMPRESS;
    Table altered.
    SQL> ALTER TABLE TAB_COMP ADD (NAME VARCHAR2(10));
    ALTER TABLE TAB_COMP ADD (NAME VARCHAR2(10))
    ERROR at line 1:
    ORA-22856: cannot add columns to object tables

    Which version of oracle you are using?
    1* create table test1234(a number) compress
    SQL> /
    Table created.
    Elapsed: 00:00:00.02
    SQL> alter table test1234 add(b varchar2(200));
    Table altered.
    Elapsed: 00:00:00.02

  • Problem with alter table in execute immediate

    We have PL/SQL scripts which modify the data structure, add data etc to en existing database. These scripts basically ensure that the db is compatible with what the software expects.
    The reason for doing it in PL/SQL rather than SQL script is A) The scripts are launched using GUI so that they are more user friendly. sqlplus is launched as a background process which executes these scripts. All the scripts have EXIT FAILURE WHENEVER SQLERROR as first line to ensure that the control does not hang in the sqlplus background process.
    Going from one version to other, we have added a few tables to the database and also modified a few tables. since (i think) DDL is not allowed in PL/SQL block, we had to resort to putting them in EXECUTE IMMEDIATE enclosures.
    Now for the real question,
    If I create a table using EXECUTE IMMEDIATE clause, I can immediately have insert as a next statement to insert data in this table. but, if I alter the table and add a column to the existing table, I cannot immediately add data to that column, it throws an error saying 'invalid identifier'
    At code level, the following is allowed :
    EXECUTE IMMEDIATE 'CREATE TABLE SP_TEST_TABLE
                             ID     NUMBER,
                             NAME     Varchar2(40)
    INSERT INTO SP_TEST_TABLE(ID, NAME) Values(1, 'SP');
    but I get error for the following :
    EXECUTE IMMEDIATE 'ALTER TABLE SP_TEST_TWO ADD
                        ANOTHER_COLUMN     number
    UPDATE     SP_TEST_TWO SET          ANOTHER_COLUMN = 1;
    In this case, it says ANOTHER_COLUMN invalid identifier
    Does anybody know why?
    any workaround will be greatly appreciated.
    --SP                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       

    Friends,
    Thanks to all of you for your help. The spelling mistakes might have occurred becuase i changed the actual script to something 'short and complete' to show the problem.
    I could solve the problem by having more than one PL/SQL block within my file. something like :
    BEGIN
    --alter table statements here
    END;
    BEGIN
    --insert the values in column here.
    END;
    I am still not sure why the error is presented only on alter table statement and not for create table statement. Probably somebody with the knowledge of oracle internals will be able to throw more light on it. I am trying to get the naswers, if I get the answer, I'll surely post it here.
    Regards,
    --Saurabh                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           

  • Why there is implicit commit before and after executing DDL Statements

    Hi Guys,
    Please let me know why there is implicit commit before and after executing DDL Statements ?
    Regards,
    sushmita

    Helyos wrote:
    This is because Oracle has design it like this.Come on Helyos, that's a bit of a weak answer. :)
    The reason is that it makes no sense to update the structure of the database whilst there is outstanding data updates that have not been committed.
    Imagine having a column that is VARCHAR2(50) that currently only has data that is up to 20 characters in size.
    Someone (person A) decides that it would make sense to alter the table and reduce the size of the column to varchar2(20) instead.
    Before they do that, someone else (person B) has inserted data that is 30 characters in size, but not yet committed it.
    As far as person B is concerned that insert statement has been successful as they received no error, and they are continuing on with their process until they reach a suitable point to commit.
    Person A then attempts to alter the database to make it varchar2(20).
    If the database allowed that to happen then the column would be varchar2(20) and the uncommitted data would no longer fit, even though the insert was successful. When is Person B going to find out about this? It would be wrong to tell them when they try and commit, because all their transactions were successful, so why should a commit fail.
    In this case, because it's two different people, then the database will recognise there is uncommitted transactions on that table and not let person B alter it.
    If it was just one person doing both things in the same session, then the data would be automatically committed, the alter statement executed and the person informed that they can't alter the database because there is (now) data exceeding the size they want to set it to.
    It makes perfect sense to have the database in a data consistent state before any alterations are made to it, hence why a commit is issued beforehand.
    Here's something I wrote the other day on the subject...
    DDL's issue a commit before carrying out the actual action
    As long as the DDL is syntactically ok (i.e. the parser is happy with it) then the commit is issued, even if the actual DDL cannot be executed for another reason.
    Example...
    We have a table with some data in it...
    SQL> create table xtest as select rownum rn from dual;
    Table created.
    SQL> select * from xtest;
            RN
             1We then delete the data but don't commit (demonstrated by the fact we can roll it back)
    SQL> delete from xtest;
    1 row deleted.
    SQL> select * from xtest;
    no rows selected
    SQL> rollback;
    Rollback complete.
    SQL> select * from xtest;
            RN
             1
    SQL> delete from xtest;
    1 row deleted.
    SQL> select * from xtest;
    no rows selectedSo now our data is deleted, but not committed, what if we issue a DDL that is syntactically incorrect...
    SQL> alter tab xtest blah;
    alter tab xtest blah
    ERROR at line 1:
    ORA-00940: invalid ALTER command
    SQL> rollback;
    Rollback complete.
    SQL> select * from xtest;
            RN
             1... the data can still be rolled back. This is because the parser was not happy with the syntax of the DDL statement.
    So let's delete the data again, without committing it, and issue a DDL that is syntactically correct, but cannot execute for another reason (i.e. the database object it refers to doesn't exist)...
    SQL> delete from xtest;
    1 row deleted.
    SQL> select * from xtest;
    no rows selected
    SQL> truncate table bob;
    truncate table bob
    ERROR at line 1:
    ORA-00942: table or view does not exist
    SQL> rollback;
    Rollback complete.
    SQL> select * from xtest;
    no rows selectedSo, there we have it. Just because the statement was syntactically correct, the deletion of the data was committed, even though the DDL couldn't be performed.
    This makes sense really, because if we are planning on altering the definition of the database where the data is stored, it can only really take place if the database is in a state where the data is where it should be rather than being in limbo. For example, imagine the confusion if you updated some data on a column and then altered that columns datatype to be a different size e.g. reducing a varchar2 column from 50 character down to 20 characters. If you had data that you'd just updated to larger than 20 characters whereas previously there wasn't, then the alter table command would not know about it, would alter the column size and then the data wouldn't be valid to fit whereas the update statement at the time didn't fail.
    Example...
    We have a table that only allows 20 characters in a column. If we try and insert more into that column we get an error for our insert statement as expected...
    SQL> create table xtest (x varchar2(20));
    Table created.
    SQL> insert into xtest values ('012345678901234567890123456789');
    insert into xtest values ('012345678901234567890123456789')
    ERROR at line 1:
    ORA-12899: value too large for column "SCOTT"."XTEST"."X" (actual: 30, maximum: 20)Now if our table allowed more characters our insert statement is successful. As far as our "application" goes we believe, nay, we have been told by the database, we have successfully inserted our data...
    SQL> alter table xtest modify (x varchar2(50));
    Table altered.
    SQL> insert into xtest values ('012345678901234567890123456789');
    1 row created.Now if we tried to alter our database column back to 20 characters and it didn't automatically commit the data beforehand then it would be happy to alter the column, but then when the data was committed it wouldn't fit. However the database has already told us that the data was inserted, so it can't go back on that now.
    Instead we can see that the data is committed first because the alter command returns an error telling us that the data in the table is too big, and also we cannot rollback the insert after the attempted alter statement...
    SQL> alter table xtest modify (x varchar2(20));
    alter table xtest modify (x varchar2(20))
    ERROR at line 1:
    ORA-01441: cannot decrease column length because some value is too big
    SQL> rollback;
    Rollback complete.
    SQL> select * from xtest;
    X
    012345678901234567890123456789
    SQL>Obviously, because a commit statement is for the existing session, if we had tried to alter the table column from another session we would have got
    SQL> alter table xtest modify (x varchar2(20));
    alter table xtest modify (x varchar2(20))
    ERROR at line 1:
    ORA-00054: resource busy and acquire with NOWAIT specified
    SQL>... which is basically saying that we can't alter the table because someone else is using it and they haven't committed their data yet.
    Once the other session has committed the data we get the expected error...
    ORA-01441: cannot decrease column length because some value is too bigHope that explains it

  • Will alter table table_name move statement change the storage parammeter

    Hi there,
    I have a question about table reorgnization. Will alter table
    table_name move SQL statment change the table's storage parameter
    or keep the same as the original one? If I want to use alter
    table statement to do table defragmentation and change the
    initial and next storage parameter, how will I write this SQL
    statement?
    Thanks in advance.

    Thanks. My table has 5000 extents each of which is 64k, so I
    think I need to do table defragmentation to improve performance.
    If I use alter table table_name move without storage parameter
    and tablespace name, I will relocate this table in current
    tablespace and adopt the current tablespace's storage parameter
    as my table's new storage paramater which is still 64k. After
    that, if I issue alter
    table table_name storage (initial 50M next=50M) command, will it
    change this table's storage parameter and decrease the totoal
    extents number? I ask this question because I use OEM2.2 tuning
    pack reorg wizard to generate the job script to do table
    defragmentation, but in the job script there is no new storage
    parameter. It only generate alter table table_name move
    statement, so I wonder if I don't need to modify this job scripts
    and after it executes this job script, I issue alter table
    table_name storage parameter command manaully. Will this solve
    my problem or I must modify the job script and add new storage
    parameter in the job script?

  • Commit after a select query

    Do we need to commit after a select statement in any case (in any transaction mode)?
    Why do we need to commit after selecting from a table from another databse using a DB link?
    If I execute a SQL query, does it really start a transaction in the database?
    I could not find any entry in v$transaction after executing a select statement which implies no transactions are started.
    Regards,
    Sandeep

    Welcome to the forum!
    >
    Do we need to commit after a select statement in any case (in any transaction mode)?
    >
    Yes you need to issue COMMIT or ROLLBACK but only if you issue a 'SELECT .... FOR UPDATE' because that locks the rows selected and they will remain locked until released. Other sessions trying to update one of your locked rows will hang until released or will get
    >
    ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired
    >
    In DB2 a SELECT will create share locks on the rows and updates of those rows by other sessions could be blocked by the share locks. So there the custom is to COMMIT or ROLLBACK after a select.
    >
    Why do we need to commit after selecting from a table from another databse using a DB link
    >
    See Hooper's explanation of this at http://hoopercharles.wordpress.com/2010/01/27/neat-tricks/
    And see the 'Remote PL/SQL section of this - http://psoug.org/reference/db_link.html
    A quote from it
    >
    Why does it seem that a SELECT over a db_link requires a commit after execution ?
    Because it does! When Oracle performs a distributed SQL statement Oracle reserves an entry in the rollback segment area for the two-phase commit processing. This entry is held until the SQL statement is committed even if the SQL statement is a query.
    If the application code fails to issue a commit after the remote or distributed select statement then the rollback segment entry is not released. If the program stays connected to Oracle but goes inactive for a significant period of time (such as a daemon, wait for alert, wait for mailbox entry, etc...) then when Oracle needs to wrap around and reuse the extent, Oracle has to extend the rollback segment because the remote transaction is still holding its extent. This can result in the rollback segments extending to either their maximum extent limit or consuming all free space in the rbs tablespace even where there are no large transactions in the application. When the rollback segment tablespace is created using extendable files then the files can end up growing well beyond any reasonable size necessary to support the transaction load of the database. Developers are often unaware of the need to commit distributed queries and as a result often create distributed applications that cause, experience, or contribute to rollback segment related problems like ORA-01650 (unable to extend rollback). The requirement to commit distributed SQL exists even with automated undo management available with version 9 and newer. If the segment is busy with an uncommitted distributed transaction Oracle will either have to create a new undo segment to hold new transactions or extend an existing one. Eventually undo space could be exhausted, but prior to this it is likely that data would have to be discarded before the undo_retention period has expired.
    Note that per the Distributed manual that a remote SQL statement is one that references all its objects at a remote database so that the statement is sent to this site to be processed and only the result is returned to the submitting instance, while a distributed transaction is one that references objects at multiple databases. For the purposes of this FAQ there is no difference, as both need to commit after issuing any form of distributed query.

Maybe you are looking for