Indexes to a Different Filegroup

hi Experts,
please could you tell me, is there any advantage if we move all indexes to another filegroup?
thanks in advance
Cheers, Vinod Mallolu

Hello,
Do you know that if you have 2 filegroups in two different drives and you move a clustered index from one filegroup to
another you will be migrating a table from one disk to another? You may have to use “WITH DROP EXISTING ON” on that case.
Hope this helps.
Regards,
Alberto Morillo
SQLCoffee.com

Similar Messages

Moving indexes to a different tablespace in siebel.

Hi,
While installation we gave same SIEBEL tablespace as default tablespace for indexes also , now I would like to move all indexes to a different tablespace. Is there any specifis utility / procedure available to move (or) recreate indexes .. or can we do it in Database using alter index <index_name> command...
Thank You,
Sunil.

You do not move constraints.
You can use the command:
ALTER INDEX index_name REBUILD TABLESPACE new_tablespace;

Move indexes to a different tablespace

What is the best and easiest method to move all indexes/constraints to a different tablespace. I have 2 tablespaces one for data and the other for the indexes. At present, I have all data and indexes all in one tablespace. I would like to separate the indexes to another tablespace(which is reserved specifically for the indexes)
Thanks

You do not move constraints.
You can use the command:
ALTER INDEX index_name REBUILD TABLESPACE new_tablespace;

Getting same index size despite different table size

Hello,
this question arose from a different thread, but touches a different problem, which is why I have decided to post it as a separate thread.
I have several tables of 3D points.
The points roughly describe the same area but in different densities, which means the tables are of different sizes. The smallest contains around 3million entries and the largest around 37 million entries.
I applied an index with
CREATE INDEX <index name>
ON <table name>(<column name>)
INDEXTYPE is MDSYS.SPATIAL_INDEX
PARAMETERS('sdo_indx_dims=3');
My problem is that I am trying to see how much space the index occupies for each table.
I used the following syntax to get the answer to this:
SELECT usim.sdo_index_name segment_name, bytes/1024/1024 segment_size_mb
FROM user_segments us, user_sdo_index_metadata usim
WHERE usim.SDO_INDEX_NAME = <spatial index name>
AND us.segment_name = usim.SDO_INDEX_TABLE;
(thanks Reggie for supplying the sql)
Now, the curious thing is that in all cases, I get the answer
SEGMENT_NAME SEGMENT_SIZE_MB
LIDAR_POINTS109_IDX .0625
(obviously with a different sement name in each case).
I tried to see what an estimated index size would be with
SDO_TUNE.ESTIMATE_RTREE_INDEX_SIZE
And I get estimates ranging from 230MB in the case of 3million records up to 2.9 for the case of 37million records.
Does anyone have an idea why I am not getting a different actual index size for the different tables?
Any help is greatly appreciated!!!
Cheers,
F.

It looks like your indexes didn't actually create properly. Spatial indexes are a bit different to 'normal' indexes in this regard. A BTree index will either create or not. However, when creating a spatial index, something may fail, but the index structure will remain and it will appear to be valid according to the data dictionary.
Consider the following example in which the SRID has a problem:
SQL> CREATE TABLE INDEX_TEST (
2 ID NUMBER PRIMARY KEY,
3 GEOMETRY SDO_GEOMETRY);
Table created.
SQL>
SQL> INSERT INTO INDEX_TEST (ID, GEOMETRY) VALUES (1,
2 SDO_GEOMETRY(2001, 99999, SDO_POINT_TYPE(569278.141, 836920.735, NULL), NULL, NULL)
3
SQL> INSERT INTO user_sdo_geom_metadata VALUES ('INDEX_TEST','GEOMETRY',
2     MDSYS.SDO_DIM_ARRAY(
3     MDSYS.SDO_DIM_ELEMENT('X',0, 1000, 0.0005),
4     MDSYS.SDO_DIM_ELEMENT('Y',0, 1000, 0.0005)
5 ), 88888);
1 row created.
SQL>
SQL> CREATE INDEX INDEX_TEST_SPIND ON INDEX_TEST(GEOMETRY) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
CREATE INDEX INDEX_TEST_SPIND ON INDEX_TEST(GEOMETRY) INDEXTYPE IS MDSYS.SPATIAL_INDEX
ERROR at line 1:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-13249: SRID 88888 does not exist in MDSYS.CS_SRS table
ORA-29400: data cartridge error
Error - OCI_NODATA
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 10
SQL> SELECT usim.sdo_index_name segment_name, bytes/1024/1024 segment_size_mb,
2 usim.sdo_index_status
2 FROM user_segments us, user_sdo_index_metadata usim
3 WHERE usim.SDO_INDEX_NAME = 'INDEX_TEST_SPIND'
4 AND us.segment_name = usim.SDO_INDEX_TABLE;
SEGMENT_NAME                     SEGMENT_SIZE_MB SDO_INDEX_STATUS
INDEX_TEST_SPIND                           .0625 VALID
1 row selected.
SQL>When you ran the CREATE INDEX statement did it say "Index created." afterwards or did you get an error?
Did you run the CREATE INDEX statement in SQL*Plus yourself or was it run by some software?
I suggest you drop the indexes and try creating them again. Watch out for any errors. Chances are its an SRID issue.

Same index name for different tables in different schema

Just a quick query
Can two tables present in different schema of same database has same index name ?
Will there be any problem?
Thanks

And just a quick answer:
859486 wrote:
Just a quick query
Can two tables present in different schema of same database has same index name ?Yes.
>
Will there be any problem?No.
>
Thanks

Move index to a different tablespace using dbms_redefinition?

Hi all, I am trying to move indexes to new tablespaces. Can I use oracle built-in package DBMS_REDEFINITION for this? As far as I know dbms_redefinitoin only works for tables rebuilt online? I am running 10.2.0.5 on linux red hat, and the index sizes from 100MB to 10gb. Thank you in advance all.

Since one can seamlessly move an index from one tablespace to another by simply doing:
SQL> alter index <index_name> rebuild tablespace <tablespace_name>;even considering DBMS_REDEFINITION for this makes no sense at all.
If your boss has any further questions, show him the Oracle documentation:
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/d_redefi.htm
Quote from that page:
"The DBMS_REDEFINITION package provides an interface to perform an *online redefinition of tables*."
(Emphasis added by me.)
Hope that helps,
-Mark

2 identical indexes but with different names - index load balancing?

Hello,
is it theoretically possible to have 2 indexes which differ only in their names? And make something like load balancing?
The real situation that brought me to that question is that one of my indexes is sometimes unavailable and the queries that use it are during this time too slow. So my idea is to have 2 indexes for the same purpose and when one of them is unavailable for some reason, then the other one will serve all queries.
So what do you think, is it possible, and if yes, do I have to do something more except defining the 2 indexes?
And please, don't try to advise me to check why my index is not available and so on. I really want to hear an answer to that particular question - it is interesting for me also just theoretically. Thanks in advance for any replies!
Regards

user10962462 wrote:
Hi
now I have something for you:
CREATE INDEX employees_idx1 ON employees (last_name, job_id);
CREATE INDEX employees_idx2 ON employees (job_id, last_name); so, how does oracle decide which one to use, if one of these is not available, will oracle automatically use the other one?In addition to what Justin has pointed out, I'd point out a couple of things:
First, you initially talked about two identical indexes. The example above are not identical. They reference the same columns but not in the same order. So index 1 would be preferred (by the CBO) with a selection predicate on last_name, while index 2 would be preferred with a predicate on job_id.
Coming back to your original, where you asked about identical indexes and load balancing - the indexes will NOT be used for load balancing .. Oracle will not use one index for one query, then when the next query comes in say "I'm already using index 1 for the previous query, so I'll use index 2 for this one." In fact, such a scenario (if Oracle would do that) would actually have a negative impact on performance, because it would negate the ability to use what was already in the buffer from the first query.
And on top of that, every index you create means decreased performance for INSERT and UPDATE operations because there will be more recursive sql necessary to maintain the indexes. Creating indexes is always a balancing act between SELECT performance and INSERT/UPDATE performance. There's no free lunch here.

How to compare index names and columns from different user?

I am using below query to compare two indexes from 2 different users but even though index name and columns are same... result shows me they are different.. what I am doing wrong? Thanks
WITH t AS
        (SELECT COUNT (DISTINCT index_owner || index_name || indexed_cols)
                   cnt
           FROM ( SELECT index_owner,
                          index_name,
                          listagg (column_name, ',')
                             WITHIN GROUP (ORDER BY column_position)
                             indexed_cols
                     FROM dba_ind_columns
                    WHERE index_name='XPKTBL_A'
                 GROUP BY index_owner, index_name))
SELECT CASE
          WHEN cnt > 1 THEN 'Indexes are different'
          WHEN cnt = 0 THEN 'Indexes dont exist'
          WHEN cnt > 1 THEN 'Indexes are identical'
       END
          commnt
FROM t
Result:
Indexes are different
but Actually if you check below they are same After when I run this query:
SELECT index_owner,
         index_name,
         listagg (column_name, ',') WITHIN GROUP (ORDER BY column_position)
            indexed_cols
    FROM dba_ind_columns
   WHERE index_name='XPKTBL_A'
GROUP BY index_owner, index_name;
Result:
Index_owner
Index_name
Index_cols
USER1
XPKTBL_A
FIELD_A1
USER2
XPKTBL_A
FIELD_A1

Hi,
Erhan_toronto wrote:
I am using below query to compare two indexes from 2 different users but even though index name and columns are same... result shows me they are different.. what I am doing wrong? Thanks
WITH t AS
        (SELECT COUNT (DISTINCT index_owner || index_name || indexed_cols)
So index_owner is 'USER1' in one case, and 'USER2' in the other; right?
A string that starts with 'USER1' will be distinct from a string that starts with 'USER2', no matter what the rest of the string contains. Maybe you don't want to compare the owners, or maybe you meant to use some other column (such as table_name) instead of index_owner).
I hope this answers your question.
If not, post a little sample data (CREATE TABLE, CREATE INDEX and CONNECT statements), and also post the results you want from that data.
Explain, using specific examples, how you get those results from that data.
Always say which version of Oracle you're using (e.g., 11.2.0.2.0).
See the forum FAQ: https://forums.oracle.com/message/9362002

SAPF100 Error if Company Code Currency different from Index Currency

Scenario:
Company has the following parallel currencies:
Local - USD (10)
Group - CAD (30)
Index - USD (50)
SAPF100 is run using currency type 10. Transactions in Document Currency CAD are revalued by the program. However, the following error message appears:
"Error message ZPARTNER003: Company Currency and Index currency are different".

this is a Z message means not SAP-standard. Check validation in GGB0 - for FI and CO

Index on different tablespaces

I need to move some indexes on a different tablespace. How can I complete this task ? I'm not a dba..

Have a look at these links:
http://docs.oracle.com/cd/E11882_01/server.112/e26088/statements_1010.htm#SQLRF00805
http://docs.oracle.com/cd/E11882_01/server.112/e25494/indexes004.htm#ADMIN11732
ALTER INDEX YOUR_INDX REBUILD TABLESPACE YOUR_TBS;

Secondary index vs secondary db

I would like to be able to search against 2 fields. One is timestamp field, the other is name. So, I would like to search like within certain time range, all the records with name=XXX. Is it better to define 2 keys in my callback or to have two secondary db with one key each and then join them?
What is a better way?
Also, I can set for time_stamp > 123 with SET_DB_RANGE, but how can I search for time_stamp> 123 and time_stamp < 444?

new index are just different at workbench level, but are the same at database level. You may assign them to a Y or Z package (instead of the sap package, it was seen as a modification of the standard). They also have a dedicated object directory entry (R3TR XINX). http://help.sap.com/saphelp_erp2005vp/helpdata/EN/85/685a41cdbf8047e10000000a1550b0/frameset.htm
[Note 1257033 - Cookbook: Modification/enhancement for standard SAP system|http://service.sap.com/sap/support/notes/1257033]

Secondary Index vs Secondary Indices

Hi All,
In the earlier version already we have the primary index,secondary indexes,But now iam going through the enhancements in NW 7.0 In this they mentioned Secondary indices as the new enhancement with NW 7.0,I know how to create the Secondary indices ,But i am getting the conffusion between secondary indexes (already we have) and the new Secondary Indices,So please could any one elobarate this or atleast URL'S which are relavant to this topic,It would be very help full to me.
Thank you..
Srihasa

new index are just different at workbench level, but are the same at database level. You may assign them to a Y or Z package (instead of the sap package, it was seen as a modification of the standard). They also have a dedicated object directory entry (R3TR XINX). http://help.sap.com/saphelp_erp2005vp/helpdata/EN/85/685a41cdbf8047e10000000a1550b0/frameset.htm
[Note 1257033 - Cookbook: Modification/enhancement for standard SAP system|http://service.sap.com/sap/support/notes/1257033]

Index not being used in Oracle 11g

Hi,
I executed an SQL in Oracle 9i based on a Materialized View with an index. Execution plan shows it used Index and did Range scan. But the same query if I executed in Oracle 11g, it did full table scan and ignored the index. Finally, I used /*+Index*/ hint to tell compiler to use the index. Can anyone tell why it happended like this.
below is the query.
SELECT TYPE,NAME,PARENT_ID,CHILD_ID,UNIT_OF_MEASURE,QUANTITY,POSITION_NUMBER
FROM MVIEW_BOM_CHILD_ATTRIBUTES
WHERE BREAKDOWN_LIMIT = 'FALSE'
CONNECT BY PRIOR CHILD_ID = PARENT_ID START WITH PARENT_ID IN ('7325','34676','10121','35154','34370','4909','5494','28714','2273','22551','36465','35416','7148','34774',' 23290','18225','24415','35774','34772','20108','19072','8134','14688','31751','12669','26450','34716','768 4','26004','8770','34001','32614','3816','19801','30329','13822','15784','9296','17147','35423','6181','3477 3','18683','20780','35191','17990','7788','1559','7691','35449','34640','35432','35829','14161','9412','2039 2','593','23744','15741','35850','4177','36420','34695','33027','34655','31315','13552','23089','14025','901 2','22930','36182','13413','13839','32502','2392','19666','35183','32174','35170','20545','14344','29190','1 8163','19124','35448','32171','23498','2694','31101','4357','30421','35826','17976','13218','34770','35778' ,'16112','36408','34797','3294','9600','23524','3663','36412','34674','26715','2886','3204','15928','4510','8 112','27232','14966','35217','6281','1610','16359','25906','10262','3291','35777','11789','34675','24208','1 0093','28479','2928','23396','19702','32716','29813','2536','2349','34639','18610','35175','9796','26915','6 041','4745','34718','17946','3285','34308','9451','29689','17903','34642','35166','4630','35760','35761','34 696','27958','5912','35549','17695','31595','8028','24020','16025','8004','6430','36391','3580','32433','354 94','27368','15801','35583','35488','18807','34180','26626','20629','34767','14771','28746','34728','4948',' 34355','14000','34734','35820','36449','4904','11136','35177','27740','8016','13883','36402','35233','2614 7','21089','33152','35162','11320','32843','7336','34654','35602','32026','35582','24500','10573','33778','1 651','22781','25784','30124','10798','15930','28652','1513','745','35415','30404','21990','20872','2272','16 273','4234','35601','35581','22088','15543','3362','7713','35431','34719','27710','33104','20482','16801','1 686','35658','16545','32681','8722','20046','8950','34799','31605','21299','19572','445','35489','35656','35 546','7414','13369','35455','35434','35438','19383','10591','24698','14607','25715','27913','1046','15511',' 36386','6801','25134','2717','2083','35288','15851','14538','35398','11575','35156','35435','4232','36380',' 18406','32862','20879','5695','4229','24132','7081','35420','34694','22474','30047','29352','34735','2305',' 36409','18040','13472','31481','29246').
Thanks

SBH wrote:
My doubt is only that is it possible that a SQL query with same index proprties uses different access path to execute. Is it dependent on oracle version also.
Yes, it is possible.
It is even possible on the same Oracle version - look at simple examples:
case 1
create table test as
select level l, 'test' test from dual
connect by level < 1000;
create index test_ix on test(l);
explain plan for
select * from test where l < 50;
select * from table(dbms_xplan.display);
Plan hash value: 1408842701
| Id | Operation                   | Name    | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |         |    49 |   931 |     3   (0)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| TEST    |    49 |   931 |     3   (0)| 00:00:01 |
|* 2 |   INDEX RANGE SCAN          | TEST_IX |    49 |       |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("L"<50)
Note
   - dynamic sampling used for this statement (level=2)case 2
drop table test;
create table test as
select * from (
select level l, 'test' test from dual
connect by level < 1000
) order by dbms_random.value(0,100);
create index test_ix on test(l);
explain plan for
select * from test where l < 50;
select * from table(dbms_xplan.display);
Plan hash value: 1357081020
| Id | Operation         | Name | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT |      |    49 |   931 |     3   (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| TEST |    49 |   931 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - filter("L"<50)
Note
   - dynamic sampling used for this statement (level=2)The same query on the same table containing the same data in it. And the same index.
The only difference is records order in the table.
In the first case CBO decided that index range scan would be reasonable.
In the second case CBO preferred FTS as less costly.

Asset Revaluation: Indexing

Greetings,
Because of several reporting changes, we have to transfer a number of assets from one asset class to another. Each asset has been indexed and when the transfers are posted, the indexing of each of the new assets is taking on the acquisition date of the transfer. I have also found that if I transfer within the same asset class, moving a main asset to a subasset, the same problem occurs.
The indexing has four different indexing classes to choose from and we have selected option 3 (FI-AA: Dependant on year, with historical indexing). I have tried changing this to option 4 (FI-AA: Dependant on age, with historical indexing) with no change in values, even after executing the AFAR t-code.
In one example, I have an asset with an APC $317k and place into service in 1977. Prior to the transfer, the indexed (replacement) value is $1,188k; but after the transfer, the indexed value $331k and both asset had the same index.
Through my analysis, I believe the indexing calculation involves the Acquisition Year (ZUJHR) data element (t-code AS03), and it is being determined by the First Acquisition On (ZUGDT) data element, which is the date of the transfer. Using standard config, is there a way to have get the Capitalized On (AKTIV) data element to default in the Acquisition Year (ZUJHR). Or, is there an OSS Note that I just can't find, that need to be applied?
Any assistance would be greatly appreciated. Thanks!

We have found the solution to be both process and config.
First, each "index series" had the "index class" modified to 1) FI-AA: Dependant on year, no historical indexing.
Second, two new transaction types were created to limit the adjustments to the indexing to the affected depreciation key; one for increasing and one for decreasing the value. Then using t-code ABZO, each asset had it's acquisition value adjusted and then the depreciation value was adjusted second.
Third, a process change was implemented where asset transfers are not completed until the current years indexing values have been added.

Quick Look Index View and PDF hidden content

I have come across an odd quirk of Quick Look in which the Index View is different from the regular view. The Quick Look Index View of two or more PDF files will show hidden page or image content, while the regular view of the individual files will not.
The hidden content consists of one portion of the text covered up.
Preview does not show the hidden content of an individual file, but QuickTime does.
Is this inconsistency of Quick Look a bug?

VikingOSX, if I'm not using plug-in then I let Quick Look to not serving me at all!
Maybe I was not clear in my initial post. Index.html is not the file I want to see inside Quick Look. Index.html file I'm talking about is part of code BetterZip plugin is using to show Zip content. It is located in the Resource subfolder inside plugin. So my findings are related to html parsing issues Quick Look engine is doing inside plugin.
Once again, I'm not talking about HTML quicklook plugin that is already built-in to show HTML files, but BetterZip plugin that is designed to show compressed file contents (e.g. zip, tar, ...).
Does someone know if there are some changes in the behaviour of Quick Look engine or if there are some bugs in Quick Look engine for Mavericks 10.9.0 that parses internal plugin html contents incorrectly (or to load external html resource files)?

Indexes to a Different Filegroup

Similar Messages

Maybe you are looking for