Generate the tablespace clause for tables and indexes

How can I make Designer generate the tablespace clause for the create table and create index statements?
I assigned tables and indexes to Tablespaces objects in designer but they don't seem to have any effect on the generator.
I am using the latest version of Oracle Designer.
Thanks
Message was edited by:
bikerc

Guess I am not real clear what you want.
In the DB admin tab you will need to create the tablespace with the data file.
Then you need to assign the table space to the table.
You will need to generate from the DB Admin tab.
Hope this helps.
Michael

Similar Messages

Import dumpfile with seperate tablespaces for table and index

Hi,
We have a schema for which the its tables are stored in seperate tablespace and indexes are stored in different tablespace. Now we have take full schema export. Now we want to import it on another schema. Now I want to know if the we have difference in the tablespace name we use REMAP_TABLESPACE clause of the impdp command but what about the seperate tablespace for table and indexes. How would Oracle handle this.
Regards,
Abbasi

Hi,
I hope you created the same tablespace structure on the target side if not so remap_tablespace option you have to use for specifying different tablespaces.Oracle will take care of putting data and index.Any how if a index is moved from one tablespace to other you have to rebuild them,once you rebuild them than only stattistics are gathered otherwise you
might face some performance issue.
Better option is to keep same tablespace structures in source and target environment.
Best regards,
Rafi.
http://rafioracledba.blogspot.com
Edited by: Rafi (Oracle DBA) on May 9, 2011 7:07 AM

Can I use shrink for Tables and Indexes

Hi Experts,
I am planning to run shrink on large tables and indexes to reclaim space, I would like to know what are the dis-advantages or limitations of shrink on e-business suite.
Architecture
Four node application server (R12.1.1)
Four node rac db (11gr2)
HP OS.

Hi;
Please see:
Using SHRINK or DELETE on tables FND_LOG_MESSAGES, FND_TEMP_FILE_PARAMETERS, FND_LOBS in EBS [ID 1066580.1]
Regard
Helios

INI_TRANS for TABLE and INDEX

Hi,
My DB version is 10.2.0.3
As by default the INI_TRANS of tables is 1 and for indexes is 2. For some reasons I have to increase the INI_TRANS of a table to 5, then what value do I set for INI_TRANS of indexes on that table?
I have read somewhere that INI_TRANS of indexes to be set twice as of table's INI_TRANS. Means if tables INI_TRANS is 5 then index INI_TRANS must be set to 10. Is it true? If yes then what is the logic behind this?
Thanks,
Oratest
Edited by: oratest on Feb 4, 2013 3:26 PM

oratest wrote:
My DB version is 10.2.0.3
As by default the INI_TRANS of tables is 1 and for indexes is 2. For some reasons I have to increase the INI_TRANS of a table to 5, then what value do I set for INI_TRANS of indexes on that table?
I have read somewhere that INI_TRANS of indexes to be set twice as of table's INI_TRANS. Means if tables INI_TRANS is 5 then index INI_TRANS must be set to 10. Is it true? No.
There is no useful guideline for a generic setting. Consider the contradictory scenes:
a) Five sessions insert five separate rows into a single table block - taking up 5 ITL slots. There is an index on the table, but the five rows just inserted hold such different values that their index entries go to 5 different index leaf blocks: the index doesn't need initrans 5.
b) Using ASSM 80 different sessions insert a row each into a table - the nature of ASSM means that (on average) there will be 5 rows inserted into 16 different blocks - the table ASSM needs to be 5. However, the indexed column in this case is generated by a sequence and all 80 index entries ought to be inserted into the same leaf block, so you need initrans to be 80 on the index. (Except Oracle will do index leaf block splits to work around problems of initrans being too small on concurrent inserts.
You have to consider the nature of the indexes and the pattern of data change for every single index separately - and then you might set initrans on the index to NO MORE THAN the table initrans + 1 because (a) that won't waste too much space (b) it's probably not going to let too much contention happen (c) Oracle will dynamically extend the ITL in most cases, (d) if it's bad for one particular index you'll notice it pretty quickly - and there will be other problems (buffer busy waits) to deal with on that index anyway.
Regards
Jonathan Lewis

DB02 view is empty on Table and Index analyses DB2 9.7 after system copy

Dear All,
I did the Quality refresh by System copy export/import method. ECC6 on HP-UX DB29.7.
After Import Runstats status n Db02 for Table and Index analysis was empty and all value showing '-1'. Eventhough
a) all standard backgrnd job scheduled in sm36
b) Automatic runstats are enabled in db2 parameters
c) Reorgchk all scheduled periodically from db13 and already ran twice.
4) 'reorgchk update statistics on table all' was also ran on db2 level.
but Run stats staus in db02 was not getting updated. Its empty.
Please suggest.
Regards
Vinay

Hi Deepak,
Yes, that is possible (but only offline backup). But for the new features like reclaimable tablespace (to lower the high watermark)
it's better to export/import with systemcopy.
Also with systemcopy you can use index compression.
After backup and restore you can have also reclaimable tablespace, but you have to create new tablespaces
and then work with db6conv and online table move to move one tablespace online to the new one.
Best regards,
Joachim

Reorganization of tablespaces, tables and indexes.

Hello Experts,
What is the concept of tablespaces, statistics , tables and indexes in SAP/Oracle ? Where are they used and what are they meant for ?
Wt is the concept and procedure of performing Reorganization of tablespaces, tables and indexes ? why do we need it for ?
Requested to revertb at earliest as its urgent . points guaranteed .
Regards,
Somya

Hello Somya,
Probably difficult to explain entire information in this thread. But you definately get good information in the following link
http://help.sap.com/saphelp_47x200/helpdata/en/0d/d2fafd4a0c11d182b80000e829fbfe/frameset.htm
Please drill down through menus, and you will be able to get good information.
Also you can check the following SAP notes
666061     FAQ: Database objects, segments and extents
912620     FAQ: Oracle indexes
588668     FAQ: Database statistics
592393     FAQ: Oracle
541538     FAQ: Reorganizations
Regards,
Madhukar

Script to find out table and index candidates to keep in the buffer pool

I am looking for a script to find out tables and indexes to keep in the buffer pool.
Could you help me on this ?
thanks...
Markus

this is more of a open question. As you know ur data well. We do not know whats ur data. cachin tables in buffer pool is okay, but it might age out after not being used...instead you can use the KEEP POOL...to cache small tables/popular tables into the keep pool...as keep pool guarantees full caching .....
here are some links on keep pool cacheing
http://download.oracle.com/docs/cd/B19306_01/server.102/b14211/memory.htm#sthref410
http://www.dba-oracle.com/oracle_tips_cache_small_fts.htm
http://www.dba-oracle.com/t_script_automate_keep_pool_tables_indexes.htm
http://www.dba-oracle.com/oracle_news/news_caching_keep_pool_large_objects_clob_blob.htm
Edited by: user630084 on Apr 8, 2009 5:48 AM

My requirement is to update 3 valuesets daily based on data coming to my staging table. What is the API used for this and how to map any API to our staging table? I am totally new to oracle and apps. Please help. Thanks!

My requirement is to update 3 valuesets daily based on data coming to my staging table. What is the API used for this and how to map any API to our staging table? I am totally new to oracle and apps. Please help. Thanks!

Hi,
You could use FND_FLEX_LOADER_APIS.UP_VALUE_SET_VALUE to upload them from staging table (I suppose you mean value set values...).
You can find a sample scripts if you google around.
What do you mean "how to map any API to our staging table" ?
You should do at least the following mapping (which column(s) in the staging table will provide these information):
- the 3 value sets name which you're going to update/upload (I suppose these are existing value sets or which have been already created)
- the value set values and description
Try to start with something and if there is any issues the community could then help... but for the time being with the description of the problem you have provided, that's the best I can do...

After move tables and index another tablespace, indexes got unusable?

Hi,
I moved table and indexes another tablespace. After move many indexes got unusable state. I couldn't understand thiis?
How can I make them again usable?
regards and thanks?

hi,
check this query below
create table test (id number(10));
create table succeeded.
insert into test values (10);
1 rows inserted
commit;
create index test_indx on test(id);
select index_name, status from user_indexes
where table_name = 'TEST';
INDEX_NAME STATUS
TEST_INDX VALID
alter table test move tablespace users;
select index_name, status from dba_indexes
where table_name = 'TEST';
INDEX_NAME STATUS
TEST_INDX UNUSABLE
rebuliding index
alter index test_indx rebuild
alter index test_indx succeeded.
then check
select index_name, status from user_indexes
where table_name = 'TEST';
INDEX_NAME STATUS
TEST_INDX VALID

Cannot INSERT records into Partitioned Spatial Table and Index

I am trying to tune our Spatial Storage by creating partitioning our spatial_entity table and index. I used the World Geographic Reference System (GEOREF) creating a partition for each 15 x 15 degree grid square assigning a partition key of decimal longitude, decimal_latitude. The build went OK, however when trying to insert a data record I receive an ORA-14400: Inserted partition key does not map to any partition.
I validated the CREATE(s), and all appears correct, but obviously something is not correct, which is prompting for expert help in this forum.
I would be very grateful for your help.
Below are the code snippets for the table and index, and an insert statement.
CREATE TABLE spatial_entity
     geoloc_type VARCHAR2 (60 BYTE) NOT NULL
,entity_id NUMBER NOT NULL
,metadata_xml_uuid VARCHAR2 (40 BYTE) NOT NULL
,geoloc MDSYS.sdo_geometry NOT NULL
,nee_method CHAR (1 BYTE) NOT NULL
,nee_status CHAR (1 BYTE) NOT NULL
,decimal_latitude NUMBER (15, 6) NOT NULL
,decimal_longitude NUMBER (15, 6) NOT NULL
PARTITION BY RANGE (decimal_longitude, decimal_latitude)
     PARTITION p_lt_0_90s
          VALUES LESS THAN (1, -90)
     ,PARTITION p_lt_0_75s
          VALUES LESS THAN (1, -75)
     ,PARTITION p_lt_0_60s
          VALUES LESS THAN (1, -60)
     ,PARTITION p_lt_0_45s
          VALUES LESS THAN (1, -45)
     ,PARTITION p_lt_0_30s
          VALUES LESS THAN (1, -30)
     ,PARTITION p_lt_0_15s
          VALUES LESS THAN (1, -15)
     ,PARTITION p_lt_0_0
          VALUES LESS THAN (1, 0)
     ,PARTITION p_lt_0_15n
          VALUES LESS THAN (1, 15)
     ,PARTITION p_lt_0_30n
          VALUES LESS THAN (1, 30)
     ,PARTITION p_lt_0_45n
          VALUES LESS THAN (1, 45)
     ,PARTITION p_lt_0_60n
          VALUES LESS THAN (1, 60)
     ,PARTITION p_lt_0_75n
          VALUES LESS THAN (1, 75)
     ,PARTITION p_lt_0_90n
          VALUES LESS THAN (1, maxvalue)
CREATE INDEX geo_spatial_ind ON spatial_entity (geoloc)
INDEXTYPE IS mdsys.spatial_index
PARAMETERS ('layer_gtype=MULTIPOINT TABLESPACE=GEO_SPATIAL_IND') LOCAL
(PARTITION p_lt_0_90s,
PARTITION p_lt_0_75s,
PARTITION p_lt_0_60s,
PARTITION p_lt_0_45s,
PARTITION p_lt_0_30s,
PARTITION p_lt_0_15s,
PARTITION p_lt_0_0,
PARTITION p_lt_0_15n,
PARTITION p_lt_0_30n,
PARTITION p_lt_0_45n,
PARTITION p_lt_0_60n,
PARTITION p_lt_0_75n,
PARTITION p_lt_0_90n,
INSERT INTO spatial_entity
     geoloc_type
     ,entity_id
     ,metadata_xml_uuid
     ,geoloc
     ,nee_method
     ,nee_status
     ,decimal_latitude
     ,decimal_longitude
VALUES
               'BATCH'
               ,0
               ,'6EC25B76-8482-4F95-E0440003BAD57EDF'
               ,"MDSYS"."SDO_GEOMETRY"
                    2001
                    ,8307
                    ,"MDSYS"."SDO_POINT_TYPE" (32.915286, 44.337902, NULL)
                    ,NULL
                    ,NULL
               ,'M'
               ,'U'
               ,32.915286
               ,44.337902
Thank you for you help.
Dave

Thank you for your quick reply. I did not post the entire CREATE script as it is quite long. The portion of the script that is applicable to the INSERT is:
,PARTITION p_lt_45e_90s
          VALUES LESS THAN (23, -90)
     ,PARTITION p_lt_45e_75s
          VALUES LESS THAN (23, -75)
     ,PARTITION p_lt_45e_60s
          VALUES LESS THAN (23, -60)
     ,PARTITION p_lt_45e_45s
          VALUES LESS THAN (23, -45)
     ,PARTITION p_lt_45e_30s
          VALUES LESS THAN (23, -30)
     ,PARTITION p_lt_45e_15s
          VALUES LESS THAN (23, -15)
     ,PARTITION p_lt_45e_0
          VALUES LESS THAN (23, 0)
     ,PARTITION p_lt_45e_15n
          VALUES LESS THAN (23, 15)
     ,PARTITION p_lt_45e_30n
          VALUES LESS THAN (23, 30)
     ,PARTITION p_lt_45e_45n
          VALUES LESS THAN (23, 45)
     ,PARTITION p_lt_45e_60n
          VALUES LESS THAN (23, 60)
     ,PARTITION p_lt_45e_75n
          VALUES LESS THAN (23, 75)
     ,PARTITION p_lt_45e_90n
          VALUES LESS THAN (23, maxvalue)
Or, I do not fully understand. Are you indicating that I must explcitly state the longitude in each clause,
e.g ,PARTITION p_lt_45e_45n
          VALUES LESS THAN (45, 45)
,PARTITION p_lt_45w_45n
          VALUES LESS THAN (-45, 45)
If so, that answers the question of why it cannot find a partition, however an Oracle White Paper "Oracle Spatial Partitioning Best Practices" Sept 2004, discusses multi column partitioning such as represented by this problem, and gives an INSERT statement example of :
CREATE TABLE multi_partn_table (in_date DATE,
geom SDO_GEOMETRY, x_value NUMBER, y_value NUMBER)
PARTITION BY RANGE (X_VALUE,Y_VALUE)
PARTITION P_LT_90W_45S VALUES LESS THAN (1,-45),
PARTITION P_LT_90W_0 VALUES LESS THAN (1,0),
PARTITION P_LT_90W_45N VALUES LESS THAN (1,45),
PARTITION P_LT_90W_90N VALUES LESS THAN (1,MAXVALUE
and as I am writing this I am seeing that I failed to include the longitude and latitude in the SDO_GEOMETRY clause, so it does appear tht I need to explicitly state the longitude valuues.
What is your judgement sir?
Dave

Separate table and index data in RAC database

Hi Experts,
Our database is Oracle11g RAC database. I need your expertise on this
Do we need to retain the table and index data in two different tablespaces for performance perspective in RAC database too?
Please share your practical experience…Thanks in advance.
Regards
Richard

g777 wrote:
In my opinion, if there is striping implemented then performance shouldn't degrade even if the index and table blocks are in one tablespace. Exactly.. striping is NOT a good idea at tablespace level as a tablespace is a logical storage device. It is very difficult to stripe comprehensively/correctly at that level, if not impossible.
Striping is a function of the actual storage system and need to happen at physical level. A proper RAID0 implementation.
So the question about multiple tablespaces for a performance increase should not be about striping - but about issues such as data management, block sizes, transportable tablespaces and so on.
Thus my question (at the OP) - what performance problems are expected and are these relevant to the number of tablespaces?

Fragmentation in tables and indexes with 9.2.0.5

Hi guys ,
I need of query to identified fragmentation in tables and indexes using Oracle 9i,someone could help me send that's querys
tks
spaulonci

Fragmentation by itself at the tablespace level doesn't mean any thing from the performance point of view, only from the storage capacity perspective, and this just in case fragments are not necessarily the same size as in the case of dictionary manged tablespaces.
You may be concerned about block density, which actually could lead to performance degradation. I suggest you to consider using coalesce instead of rebuilding in the case of indexes, and in the case of tables you should perform a segment reorganization. In the case of 9iR2 the coalesce command for table segments is not available so you will have to perform another segment reorganization strategy. If there are meaningful differences with the high water mark, average number of rows per block and chained rows then you will notice performance differences.
I suggest you to take metrics for block usage prior to perform an index coalesce operation, as well as prior to perform a data segment reorganization to assess if the reorganization effort is useful.
~ Madrid
http://hrivera99.blogspot.com/

How Find space Used by Tables and Indexes

Dear All(s)
How i check space used (and number of rows) by each table and index in schema. ( can i check current space utilization and sysdate-date past in time)
How i can check used, and free space for each database and tablespace.
Thanks

You can always use the search feature
anyway
how to calculate the percentage of free space for a table in Oracle
Re: incorrect free space in dba_free_space
These links could give you all the necessary info

When rebuild table and index

Hi,
how to know if for a table we should rebuild table and index ?
Many thanks.

Safi, I would be less sure than that. There were many many very long threads in database general forum about that subject. If you observed that fact once, that is not very often the case.
@OP,
Assuming the question was not about performance, but more on AppDesigner side (because of rebuild table), what I can say is :
1. Peoplesoft store all the storage definition for all the objects in its own metamodel tables
2. when you are changing field definition (column's definition) or indexes definition, the new definition is stored in the Peoplesoft metamodel tables
3. On the table/index build, AppDesigner compare the Peoplesoft metamodel definition for that particular object with in the Oracle (or what ever else database you are using) definition of that same object.
4. If the defintions reported on step 3 are different, then AppDesigner will fill a file with all the (re)build statements of the objects you are rebuilding (and different).
5. Finally, you just have to run the generated script.
Of course, you can bypass the comparison by enforcing AppDesigner the (re)build the record/index in all cases, however, it is not always (do not say never) recommanded.
Now, when you have to rebuild table (or record in AppDesigner's word) or indexes ? Basically, by the previous explanation I gave above, you could understand this is when you are changing a field/table/index definition through AppDesigner.
Nicolas.

How to partition tables and indexes in this scenario?

So our situation is pretty simple. We have 3 tables.
A, B and C
the model is A->>B->>C
Currently A, B and C are range partitioned on a key created_date however it's typical that only C is every qualfied with created date. There is a foreign key from B -> A and C -> B
we have many queries where the data is identified by state that is indexed currently non partitioned on columns in A ... there are also indexes on the foreign keys that get from C -> B -> A. Again these are non partitioned indexes at this time.
It is typical that we qualify A on either account or user or both. There are indexes (non partitioned) on these
We have a problem now because many of the queries use leading wildcards ie. account like '%ACCOUNT' etc. This often results in large full table scans. Our solution has been to remove the leading wildcard but this isn't always possible.
We are wondering how we can benefit from partitioning and or sub partitioning table A. since it's partitioned on created_date but rarely qualify by that.
We are also wondering where and how we can benefit from either global partitioned index or local partitioned indexes on tables A. We suspect that the index on the foreign key from C to B could be a local partitioned index.
I am also wondering what impact pushing the state from A that's used to qualify A down to C would have any advantage.
C is the table that currently we qualify with the partition key so I figure if you also pushed down the state from A that's used to qualify the set of C's we want based on the set of B's we want based on the set of A thru qualfying on columns within A.
If we push down some of those values to C and simply use C when filtering I'm wondering what the plans will look like compared to having to work all the way up from the bottom to the top before it begins qualifying A.
Edited by: steffi on Jan 14, 2011 11:36 PM

We are wondering how we can benefit from partitioning and or sub partitioning table A. since it's partitioned on >created_date but rarely qualify by that. Very good question. Why did you partition on it? You will never have INSERTS on these partitions, but maybe deletes and updates? The only advantage (I can think of) would be to set these partitions in a read only tablespace to ease backup... but that's a weired reason.
we have many queries where the data is identified by state that is indexed currently non partitioned on columns in >A ... there are also indexes on the foreign keys that get from C -> B -> A. Again these are non partitioned indexes at >this time.Of course. Why should they be partitioned by Create_date?
It is typical that we qualify A on either account or user or both. There are indexes (non partitioned) on these
We have a problem now because many of the queries use leading wildcards ie. account like '%ACCOUNT' etc. This >often results in large full table scans. Our solution has been to remove the leading wildcard but this isn't always possible.I would suspect full index scan. Isn't it?
We are also wondering where and how we can benefit from either global partitioned index or local partitioned >indexes on tables A. We suspect that the index on the foreign key from C to B could be a local partitioned index.As A is not accessed by any partition, why should C and B profit? You should look to partition by the key you are using to access. But, you are looking to tune your SQLs where the access is like '%ACCOUNT' on A. Then when there is a match. ORACLE joins via your index and nested loop (right?) to B and C.
I am also wondering what impact pushing the state from A that's used to qualify A down to C would have any >advantage.Why should it. It just makes the table and indexes larger => more IO.
C is the table that currently we qualify with the partition key so I figure if you also pushed down the state from A >that's used to qualify the set of C's we want based on the set of B's we want based on the set of A thru qualfying >on columns within A.If the access from A to C would be .. AND A.CREATE_DATE =C.CREATE_DATE and c.key like '%what I want%' which does not qualifify for a FK ;-) then, as that could be resulting in a partition scan, you could "profit". But, I'm sure that's not your model.
If we push down some of those values to C and simply use C when filtering I'm wondering what the plans will look >like compared to having to work all the way up from the bottom to the top before it begins qualifying A.So you want to denormalize A,B,C and into one table? With the same access is like '%ACCOUNT' you would get a full scan on an index as before, just the objects would be larger due to redundance and harder to maintain. In the end you would have a bad and slower design.
Maybe you explain what the problem is.
Full index scan can not be avoided, but that can be made faster by e.g. parallel query, and then the join to B and C should be a "snip" if you just identify a small subset of rows in these tables.

Generate the tablespace clause for tables and indexes

Similar Messages

Maybe you are looking for