Best Practice to Copy Table to Different Schema?

This is what I tried:
1. Create USER2 new user that uses TBS2 as default Tablespace
2. Perform exp (resides on TBS1 Tablespace)
3. Perform imp using fromuser and touser parameter to USER2
What I noticed is that the table that was imported to USER2 still resides on the same tablespace which suppose to be on TBS2.
Can someone help me perform this steps?

mrp wrote:
will this option recreate index?The best way to find answers of such questions would be to test it yourself.
SQL> conn aman/aman
Connected.
SQL> create table test as select * from scott.dept;
Table created.
SQL> create index tidx on test(deptno);
Index created.
SQL> select object_name, object_type from user_objects;
OBJECT_NAME
--------------------------------------------------------------------------------OBJECT_TYPE
TIDX
INDEX
TEST
TABLE
SQL> create table test2 as select * from test;
Table created.
SQL> column object_name format a40
SQL> select object_name, object_type from user_objects;
OBJECT_NAME                              OBJECT_TYPE
TIDX                                     INDEX
TEST                                     TABLE
TEST2                                    TABLE
SQL>So did the index get created for the 2nd table or not?
Aman....

Similar Messages

  • Accessing tables from different schema in CDS and AMDP

    Hi All,
    We are working on a HANA system which has several schema replicated from SAP R/3/Non SAP systems. We have BW 7.4 SP9 deployed on the same system and accessing the HANA views using latest BW virtual objects such as Open ODS , Composite providers etc.
    We are also using the BW system for few ABAP based data processing developments. We are currently accessing HANA views in ABAP programs by creating dictionary views based on external HANA views.
    We would like to however use recent possibilities of CDS and AMDP for better life cycle management of ABAP based solutions. The open SAP course on this subject was of very good help. Thanks a lot "open SAP team" for that. I would however have few open questions,
    As I understand AMDP gives us full flexibility of writing sql procedures within ABAP development environment, but can we access tables from different schema into AMDP code. If yes, then sample code would help.
    If the answer of first question is yes, then how do we manage transports between development and production systems where the schema names would be different. Currently in open HANA developments, such transport is manged using Schema mapping.
    Can I also use different schema tables in CDS views.
    We are updating few tables in ABAP dictionary after applying processing logic in ABAP program as detailed in step 1. With the new approach using AMDP, can we directly update database schema tables which will give us an optimization advantage.
    New ABAP HANA program interfaces are quite promising and we would like to use them to optimize many data intensive applications.
    Thanks & Regards,
    Anil

    Hi Anil,
    I can only answer 1. and 2. (and would be interested into 3. as well):
    1.
    Yes you can access tables from a different schema and also HANA views. In this case no 'using' is needed.
    Examples:
        RESULT = SELECT
        FROM
              "SAP_ECC"."T441V" AS t,
              "_SYS_BIC"."tmp.package/AFPO" AS a.
        WHERE ...
    2. In this case, if you need schema mapping: You could use HANA (projection) views which just forward to a different schema, also see example.
    Best regards,
    Christoph

  • How can we copy table from one schema to other schema

    Hi,
    I have create one table in one schema and i want to copy it to other schema.How we can copy table from one schema to other schema

    Hi,
    You can try something like this :-
    SQL> CONNECT SYS/SYS123@SERVER AS SYSDBA
    Connected.
    SQL> CREATE USER TEST_1 IDENTIFIED BY TEST_1;
    User created.
    SQL> CREATE USER TEST_2 IDENTIFIED BY TEST_2;
    User created.
    SQL> GRANT CONNECT,RESOURCE,DBA TO TEST_1;
    Grant succeeded.
    SQL> GRANT CONNECT,RESOURCE,DBA TO TEST_2;
    Grant succeeded.
    SQL> CONNECT TEST_1/TEST_1@SERVER
    Connected.
    SQL> CREATE TABLE TEST_COPY ( TEST_COL NUMBER );
    Table created.
    SQL> INSERT INTO TEST_COPY VALUES ( 1 );
    1 row created.
    SQL> INSERT INTO TEST_COPY VALUES ( 2 );
    1 row created.
    SQL> COMMIT;
    Commit complete.
    SQL> GRANT ALL ON TEST_COPY TO TEST_2;
    Grant succeeded.
    SQL>  CONNECT TEST_2/TEST_2@SERVER
    Connected.
    SQL> CREATE TABLE TEST_COPY AS SELECT * FROM TEST_1.TEST_COPY;
    Table created.
    SQL>  SELECT * FROM TEST_COPY;
      TEST_COL
             1
             2Regards,
    Sandeep

  • Best Practice of copying Production to Development

      Hi everyone.  My management would like some documentation  on the Best Practice of copying Production systems to Development. 
    1. In the past, we've setup the clients and connections/interfaces and shrink the database by deleting unneeded production data. Now that there is note 130906, saving the ABAP versions may be easier. 
    2. Every two or three years we copy our BIW Production to Development.  This is also labor intensive to set up the development system again with source systems.
    3. We've copied our PI 70 system to a sandbox, and again this is labor intensive to reset the PI object names, since the system names are imbedded in the object names.
    4. I've done java systems to, so I'm not to concerned about these.
    5. There is talk of copying the following Production systems to Development systems - SLD, PI 7.1, Solution Manager, SAP R/3, BIW, MII...some of these make sense, others we question if it is worth it.
      As a note, we copy our SAP R/3 Production instance to our QA environment about twice a year and to another QA system monthly.  We also copy our CRM Production to our QA environment twice a year and BIW Production to QA environment once a year.  We can leverage what we know about copying to PRD to QA, but we want to give them alternatives about copying PRD to DEV.
    We'd like to use SAP's TDMS to move data from PRD to DEV.  But unfortunately, that project has not gotten management  attention as being a high priority (yet).
    Rather than take my  word for it, is there any SAP provided documentation that would give my management a set of alternatives on their desire to copy our Production systems to Development.
    Thanks...Scott B.

    From a E2E200 perspective SAP recommends the following landscape:
    Maint = Dev -> QA -> Pre-Prod -> Prod
    N+1 =  Dev2 -> QA2 -> Pre-Prod -> Prod
    Maint is all object versions to remain ideally the same versions, and only transports to fix a short dumping Prod system.  N+1 is where you have implementation/upgrade projects worked on and allow you import the entire project of transports.
    Another consideration, when you restore a Prod system to a Dev or new Dev system; you are destroying all of your version info which means your developers can't view or revert changes for the objects.

  • No Easy Way to Join on Tables from Different Schemas

    Hi,
    The company policy does not allow to join on tables from different schemas or use db links...
    I'm tasked to come up with a Perl script that does exactly that - allows for the SELECT statement to do several joins on 3 different schemas. In addition 1 of the schemas is on the different host altogether.
    Upping the privileges for my user and allowing db links is not an option...Can someone, please help me to understand on a conceptual level how would I use Perl and what logic would it have and what would it (perl) do?
    Thank you,

    Court in the wrong job... ;)
    It's like a librarian who is a hard rock artist maintaining the silence in the premises. ;)
    My dear friend, i don't think this is the right place for your requirement. This is the PL/SQL forum. If you have any problem related PL/SQL or SQL you can place that here.
    Regards.
    Satyaki De.

  • Performance with having tables in different schema's

    Hi all,
    We have a requirement to segregate tables into different schema's based on the sources. But everything is going to be on the same instance and database.
    Is there a performance hit (querying between tables) by having tables in different schema as apposed to having them in the same schema?
    Thanks
    Narasimha

    Most likely there is bit of performance impact if your application refers the tables from different schemas. You need to use database link to access the other schemas. Even you schemas may in instance but when you use database link the network also comes into picture. even queries on same instance will routed through network connect and get the data. Distributed transaction also have issues some time. So as far as possible the distribution of objects should be avoided into diffrent schemas.

  • Create a View from tables of different schemas

    hi all,
    can u pls give solution to create a View from tables of different schemas.
    i have to bring data from one DB Server A,
    which contains different schemas and tables in the schemas...
    i need to insert that data in another DBServer B.
    i made a procedure for this...
    but when the connection fails from A, then i could not get data...
    please suggest some solution..
    thanks,
    neelima

    I don't know what database system you use, but in the most I know it is done that way:
    SELECT
    A.COL1,A.COL2.....
    FROM
    SCHEMA_NAME.TABLENAME A,
    SCHEMA_NAME.TABLE_NAME B
    WHERE
    A.COL1 = B.COL2
    ...

  • Package Error!  join to tables in different schemas

    Hi
    I get an error whwn I want to put my query into package
    I have two tables in different schemas and I joined them and it works when I compile it
    but in the SP it doesn't works
    Is anbody help me? please
    Table1 in Schema1
    Table2 in Schema2
    TableID is the column which I join two tables (Table1.TableID=Table2.TableID)
    User1 has Select grant to both tables (it works when I run the query but in the sp which is in the package it doesn't work)
    Package1 in Schema1

    query is working
    but when I put that query in to package, Package is giving error like "table or view does not exist"
    Table1 in Schema1
    Table2 in Schema2
    TableID is the column which I join two tables (Table1.TableID=Table2.TableID)
    User1 has Select grant to both tables (it works when I run the query but in the sp which is in the package it doesn't work)
    Package1 in Schema1
    Select * from Schema1.Table1
    Inner join Schema2.Table2 on Table1.TableID=Table2.TableID
    is working in editor but
    CREATE OR REPLACE PACKAGE Schema1.PCKG_packagename AS
    PROCEDURE SP_procedurename
    Select * from Schema1.Table1
    Inner join Schema2.Table2 on Table1.TableID=Table2.TableID;
    END SP_procedurename;
    END PCKG_packagename ;
    is not working
    Must I give grant to Package?
    Edited by: 874779 on 25.Tem.2011 03:37
    Edited by: 874779 on 25.Tem.2011 03:51

  • Best practices in Queue table maintenance

    Hi Fellow AQ Users,
    I am looking to hear from the community about best practices in queue table maintenance.
    I have been mining through metalink about various Oracle recommendations and putting
    together a set of recommendations as a starting point for my DBAs.
    I am looking to answer questions like these --
    How often (in relation to messaging load) would you coalesce and rebuild the indexes?
    How often would you rebuild the table itself to get rid of the high water mark issues ?
    and what procedure would you use to do that?
    Would really love to learn from your experiences in this area. We are using 9.2.0.7
    64 bit DB and have plans to go to 10g over the next year. So, I am looking at 9i related
    stuff and then 10g.
    Thanks
    Vijay

    Hello,
    In general you coalesce once per day ideally during a quiet time to avoid ORA-54 errors as per <Note:271855.1>. Some customers do it more often than that but once per day is a good starting point.
    In terms of shrinking the queue tables you can use the procedure in <Note:304522.1> with a null 3rd parameter. This is an offline procedure so you could only run it during a maintenance window. In 10.2 onwards you can dynamically shrink the queue table and IOTS. Again it depends on exactly what you are doing with your queue tables how often you might need to do this.
    Thanks
    Peter

  • Best practices in Internal table naming convention GT ,  GS , LT  ,  LS  ??

    Hi Gurus,
         Are GT_ ,  GS_ ,  LT_  ,  LS_  --- the  Best practices in Internal table naming convention ????
         I  have  seen this  naming convetions adhered in standard programs .
         What each one  of  the  below  signify
         GT_ ,  GS_ ,  LT_  ,  LS_   ??????? 
    Regards
    Jaman
    Message was edited by:
            ABAP Techie

    Hello
    I use the following naming conventions:
    - G = global variable
    - L = local variable
    - T = internal table
    - S = structure
    - D = field
    That's how the combinations look like:
    - GT_ITAB     = global itab
    - GS_STRUC = global structure
    - GD_FIELD   = global field
    - LT_ITAB     = local itab
    - LS_STRUC = local structure
    - LD_FIELD   = local field
    Function module parameters have to stick to the following rules:
    - I = importing
    - E = exporting
    - [C = changing -> never used]
    - IT_ITAB = imported table type (itab)
    - IS_STRUC = imported structure
    - ID_FIELD   = imported field
    - ET_ITAB = exported table type (itab)
    - ES_STRUC = exported structure
    - ED_FIELD   = exported field
    Depending on their semantics TABLES parameters look like:
    - IT_ITAB = imported data
    - ET_ITAB = exported data
    - XT_ITAB = changing data (import & export)
    Here are the conventions for FORM routine parameters:
    - UT_ITAB = using itab (data are usually treated like constants; no changes will be transfer - although possible - to the calling program)
    - CT_ITAB = changing itab (if it is semantically an exporting itab then one of the very
    first statements in the routine is: REFRESH ct_itab. )
    - US_STRUCT
    - UD_FIELD
    - CS_STRUCT
    - CS_FIELD
    Conventions for class/interface parameters:
    - IT_ITAB = importing table type
    - IS_STRUC = importing structure
    - ID_FIELD = importing field
    - ET_ITAB = exporting table type
    - ES_STRUC = exporting structure
    - ED_FIELD = exporting field
    - RT_ITAB = returning table type
    - RS_STRUC = returning structure
    - RD_FIELD = returning field
    Conventions for class/interface attributes:
    - MT_ITAB = table type
    - MS_STRUC = structure
    - MD_FIELD = field
    - MC_CONST = constant
    <b>Question</b>: Are there any advantages of such elaborated naming conventions?
    My answer to this question is: Yes, definitively.
    I believe that the advantage of semantically differentiating TABLES parameters of function modules is quite obvious:
      CALL FUNCTION 'Z_BAD_NAMING'
        TABLES
           itab1 = ...
           itab2 = ...
           itab3 = ... .
      CALL FUNCTION 'Z_GOOD_NAMING'
        TABLES
           it_itab1 = ...
           et_itab2 = ...
           xt_itab3 = ... .
    I also believe that my naming conventions clearly enhance <b>readability </b>and <b>maintainability </b>of my programs.
    Regards
      Uwe

  • How to copy data, table rows between tables in different schema

    how do I copy rows from one table in one schema into another table in another schema in same database?

    Hi,
    Give an Access to the respective table in Source Schema to Destinations Schema. If table does not exits in the destination schema use CTAS else Insert into..etc., with your select Query.
    - Pavan Kumar N

  • Code and core tables in different schemas

    Hi,
    My db version : Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
    I would like to understand, the pros and cons of the following situation:
    We have a single application.
    The db design for this application has 44 tables out of which 28 are core tables related by PK and FK relationships. The remaining 16 are look up and reference tables which are not related to any.
    The team decided to place the 28 core tables in one schema A and the remaining 16 in another schema B within same database. (The reason for this is..since it is done in other projects lets do it here too).
    Now comming to the code (stored procs, functions, packages etc). The teams wants to place most of the code in the schema B that has the 16 ref tables. (the reason again being the same).
    What are the pros and cons doing this???
    Please advice.
    PS:
    I have googled and found sth on these lines:
    cons: 
    o harder to manage
    o harder to upgrade
    o harder to patch
    o harder to maintain
    o causes your shared pool size to increase 1,000 times (shared sql goes down the tubes)
    o takes more space
    o queries against the dictionary will be impacted
    o latching on the shared pool goes WAY up (latching = locks = serialization device =
    slows you down)
    pros:
    o none that I can think of.

    >
    I would like to understand, the pros and cons of the following situation:
    Yes I am straining to find more points (was not good at it though).
    >
    You just want to understand? Are you sure? Your thread reads more like you just want to do things your way and are looking for support.
    >
    The team decided to place the 28 core tables in one schema A and the remaining 16 in another schema B within same database. (The reason for this is..since it is done in other projects lets do it here too).
    Now comming to the code (stored procs, functions, packages etc). The teams wants to place most of the code in the schema B that has the 16 ref tables. (the reason again being the same).
    >
    My question to you is: what PROBLEM are you trying to solve? If the 'team' already uses this approach and there haven't been any substantive problems then why try to change things now? Why have you chosen to fight this battle?
    Your 'team' has already decided and now, after that decision, you want to argue about it with them? The time to present arguments for/against a given plan is BEFORE the decisions are made, not after. Once a decision is made you need to be a team player and implement that decision to the best of your ability.
    One thing I'm certain of. If you try to support your argument using things like that 'AskTom' link you posted any credibility you had will go out the window. That link, as you already hinted yourself, is not your use case at all. All it takes is for one of your 'team' members to point that out and everyone will pretty much stop listening to any other arguments you make.
    People are generally not going to 'change their ways' unless you can show them:
    a) there is something seriously wrong with the way they are now doing things or
    b) a new way of doing things provides some substantial benefits
    Choice 'a' above is where you need to start but you haven't provided ANY information in this post that you have identified any serious issues with the status quo.
    The main task for Oracle is to be able to FIND the objects being referenced. So, in my opinion, that is what you should focus on when looking for PRO/CON arguments.
    That is: What issues are there if an object being referenced is in a different schema than the session that needs to use the object?
    1. objects may need to be prefixed with the schema name
    2. public or private synonyms may need to be created/maintained to avoid having to deal with item #1 above
    3. new grants may be needed to implement/maintain the proper security
    4. new roles may need to be created to maintain proper security (see item #3 above)
    5. additional work will be needed to maintain the new roles in item #4 above
    6. PL/SQL code may not be able to reference the object or may reference the wrong object
    7. Roles are disabled in PL/SQL (see item #6 above) - this means that the new grants (see item #3) may need to be granted directly to the schema users that need access instead of to roles. That can make it harder to create and maintain a role-base security schema.
    If I were you I would spend my time on other more important thingsd. But if I chose to fight this particular battle then I would make a list of problems that occured in the past with the current method of doing things and also problems related to the above list of items and then show how many of those problems will 'disappear' if the new method is used.

  • Best Practice to copy IT0758 subtype ABC to subtype DEF

    What is the best practice to create an infotype record with a specific subtype in a same infotype but different subtype? Let's say copy IT0758 subtype ABC to subtype DEF. Thanks!

    Call FM HR_INFOTYPE_OPERATION to create any new infotype record

  • Best practice of metadata table in data warehouse environment ?

    Hi guru's,
    In datawarehouse, we have 1. Stage schema 2. DWH(Data warehouse reporting schema). In stageing we have about 300 source tables. In DWH schema, we are creating the tables which are only required from reporting prespective . some of the tables in stageing schema, have been created in DWH schema as well with different table name and column names. The naming convention for these same tables and columns in DWH schema is more based on business names.
    In order to keep track of these tables we are creating metadata table in DWH schema say for example
    Stage                DWH_schema
    Table_1             Table_A         
    Table_2             Table_b
    Table_3             Table_c
    Table_4              Table_DMy question is how do we handle the column names in each of these tables. The stage_1, stage_2 and stage_3 column names have been renamed in DWH_schema which are part of Table_A, Table_B, Table_c.
    As said earlier, we have about 300 tables in stage and may be around 200 tables in DWH schema. Lot of the column names have been renamed in DWH schema from stage tables. In some of the tables we have 200 column's
    so my concern is how do we handle the column names in metadata table ? Do we need to keep only table names in metadata table not column names ?
    Any idea will be greatly appriciated.
    Thanks!

    hi
    seems quite a buzzing question.
    In our project we designed a hub and spoke like architecture.
    Thus we have 3 layer, L0 is the one closest to the source and L0 table's name are linked to the corresponding sources names by mean of naming standard (like tabA EXT_tabA tabA_OK1 so on based on implementation of load procedures).
    At L1 we have the ODS , normalized model , we use business names for table there and standard names for temporary structures and artifacts
    Both L0 an L1 keep source's column names as general rule, new columns like calculated one are business driven and metadata are standard driven.
    Datamodeler fits perfect for modelling L1 purpose.
    L2 is the dimensional schema business names take place for tables and columns eventually rewritten at presentation layer ( front end tool )
    hope this helps D.

  • Materialized view with tables in different schemas

    Hello,
    I want to create a materialized view with a table from a different schema in the SELECT statement. For materialized view I would like to apply the "REFRESH COMPLETE ON COMMIT" option.
    Here the code:
    CREATE MATERIALIZED VIEW S1.MV_EXAMPLE
    TABLESPACE TS1
    PCTFREE 0
    BUILD IMMEDIATE
    REFRESH COMPLETE ON COMMIT
    AS
    SELECT T.COLUMN1 COLUMN
    FROM S2.TABLE1 T
    I can't execute this SQL because I get an "insufficient privileges" error to this table:
    FROM S2.TABLE1 T
    FEHLER in Zeile 9:
    ORA-01031: Insufficient privileges
    User S1 has the following privileges:
    CREATE SESSION
    CREATE SNAPSHOT
    CREATE TABLE
    CREATE QUERY REWRITE
    SELECT ANY TABLE
    User S2 has the following privileges:
    CREATE SESSION
    CREATE SNAPSHOT
    CREATE TABLE
    CREATE QUERY REWRITE
    ALTER ANY SNAPSHOT
    Which privileges are missing?
    Thanks, Mathias

    Thanks Kamal for your answer!
    S1 has the grant select directly. But I solveld the problem. The system privilege "ON COMMIT REFRESH" was missing for S1. This has to be set if any of the tables are outside the owner's schema of the materialized view (ORACLE documentation - Data Warehouse Guide).
    But one thing is not clear to me yet and the ORACLE documentation doesn't give me an answer. I can set the refresh-attribute ON COMMIT on a materialized view containing only joins when a group by clause is set. If the group by clause is missing I can't! Why?
    Regards, Mathias

Maybe you are looking for

  • CUCM 8.6.2.20000-2 update to SU3

    Dear All, I'm planning to upgrade CUCM from version 8.6.2.20000-2 to SU3 and my question is do i need to use the COP file named ciscocm.refresh_upgrade_v1.1.cop.sgn. Thank you,

  • Calendar App is missing "list" icon

    After upgrading to IOS 7.1.2 the Calendar App on my iPhone it does not have the "list" icon anymore, but three icons on the top right hand side:  A screen with lines underneath, the magnifying glass and the plus sign. Before upgrade the "screen with

  • How do I update the substring of a string value?

    UPDATE table1 SET  SUBSTR  (TO_CHAR(field_value),3,2) = ' 50'  and SUBSTR (TO_CHAR(field_value),5,2)  =  '50' where  ( SUBSTR(TO_CHAR(field_value), 3, 2) =  '100' ) or ( SUBSTR(TO_CHAR(field_value), 5, 2) =  '100' )tried the above in TOAD and I got "

  • Adobe acrobat xi pro student/teacher edition install?

    I recently purchased the adobe acrobat xi pro student/teacher edition from local bestbuy...I went online and activated product even got serial number however, maybe its me but darn program wont run when in insert cd into drive...I have no idea whats

  • Is it possible to call Normal function Module from WD4A , Not RFCs

    Is it possible to call Normal function Module(FM) from WebDynPro for ABAP , Not RFCs