Table partitioning/indexing strategy

Similar Questions

• Table partition and no partition indexes

  Hello
  
  I have the partition table that contains about 1 ml recods and he have daily score.
  This partition table have only a unique index that is a partition No.
  
  CREATE UNIQUE INDEX xxxxxx WE yyyyyy
  (ITEM_GUID, IMAGE_SIDE)
  LOGGING
  TABLESPACE zzzzzz
  PCTFREE 10
  INITRANS 2
  MAXTRANS 255
  STORAGE)
  INITIAL 170M
  ACCORDING TO 1 M
  MINEXTENTS 1
  MAXEXTENTS 2147483645
  PCTINCREASE 0
  DEFAULT USER_TABLES
  )
  NOPARALLEL;
  
  I drop very first partition of
  
  Fall of ALTER TABLE wwww.yyyyy SCORE PT_20080706;
  
  But this isn't my unique INVALID index.
  
  Is it normal to have a VALID unique index after the fall of any partition?
  
  Do I have to rebuild a unique index again?
  
  DB: oracle 10.2.0.3
  platform: solaris
  
  Thanks in advance

  According to the Oracle doc, if you drop the bulkhead with an overall index,.

  All index global, or all partitions of global partitioned indexes are marked UNUSABLE unless one of the following are true:

  You specify the UPDATE INDEX (cannot be specified for tables organized by index. Use GLOBAL updating INDEXES.)

  The dropped partition or its subparts are empty

  more info here
  http://download.Oracle.com/docs/CD/B19306_01/server.102/b14231/partiti.htm#sthref2751

  Check ALL_PART_INDEXES and ALL_INDEXES to check the State of your indexes.

• Partitioned Tables and indexes

  Hello
  
  
  I have a question on the table and index partitioning. My scenario is:
  
  Charge 2 mio records in table T once a month. Loaded records are added to existing records, and once loaded data is never changed.
  At some point, I want to delete the older recordings, so I intend to this partition table.
  
  T table looks like:
  

  create table t (id       number(10) not null  constraint t_pk primary key,
                  period   number(10) not null,
                  contract number(10) not null,
                  attr     number(10) not null);
  
  create unique index t_ux1 on t(contract,period);
  
  create index t_ix2 on t(period);

  My plan is to partition T over the period, and I'm trying to read through the concepts
  http://download.Oracle.com/docs/CD/B19306_01/server.102/b14220/partconc.htm#g471747
  
  
  My question is now, how to manage the indexes, the t_pk, the t_ux1 and the t_ix2. Concepts of say,
  
  «1. If the table partitioning column is a subset of index keys, use a local index.»
  
  "2. If the index is unique, use a global index. If this is the case, you are finished. »
  
  
  So, that's how I read it
  -t_pk is unique, so this should be global
  -t_ux1 of columns is a subset, unless I have misunderstood (?), which should be local
  -index t_ix2 column is the same as the partitioning column, so it must be local
  
  Is this right, this t_ux1 should be a local partioned index, even if the period is the second column in the index?
  
  If true, what will happen when a partion fell?
  
  
  I am new in this area, so please feel the comment as you wish.
  
  
  Concerning
  Peter
  
  
  BANNER
  ----------------------------------------------------------------
  Oracle Database 10 g Enterprise Edition release 10.2.0.3.0 - 64bi
  PL/SQL version 10.2.0.3.0 - Production
  CORE Production 10.2.0.3.0
  AMT for IBM/AIX RISC System/6000: Version 10.2.0.3.0 - production
  NLSRTL Version 10.2.0.3.0 - Production

  Peter Gjelstrup wrote:

  My question is now, how to manage the indexes, the t_pk, the t_ux1 and the t_ix2. Concepts of say,

  «1. If the table partitioning column is a subset of index keys, use a local index.»

  "2. If the index is unique, use a global index. If this is the case, you are finished. »

  So, that's how I read it
  -t_pk is unique, so this should be global
  -t_ux1 of columns is a subset, unless I have misunderstood (?), which should be local
  -index t_ix2 column is the same as the partitioning column, so it must be local

  Is this right, this t_ux1 should be a local partioned index, even if the period is the second column in the index?

  A partitioned index locally can only be defined as unique if the partition key is part of the columns in the index. Imagine what the database would have to do if this is not the case: in order to verify if a newly added or updated value violates the uniqueness, it will have to travel all the partitions in a serialized operation - means that no one else could do the same thing at the same time. Since he is a killer of serious scalability in terms of locking and contention, this is not allowed.

  So: Your T_UX1 index can be defined as a unique index that is local because it contains the partition key. Although the index is not prefixed ("Prefix" means that it is divided by the left side of the columns in the index) which means that there may be access patterns where all partitions should be scanned or the optimizer cannot use a method of size of effective partition according to the way the index is reached.

  Your T_PK index cannot be set as local because it must be unique (you can not use a local non-unique index in this case), but does not contain your partition key. It must be a global index. An overall index can be partitioned as well (different from the underlying table) but it doesn't have to be.

  Depends on how you access your data you have not T_IX2 index when partitioning by this key because it corresponds to the partition key and therefore could not actually be used by the mechanism of partition pruning that limit your query to the scores of individuals.

  If you have more than one MAS environment where running queries are used longer, you should be fine with the index the in general (because they could be analyzed in parallel in parallel operations), but if you have an OLTP environment, then you should avoid local no prefix indexes due to the potential problem that you need to analyze all partitions.

  Be borne in mind that with partitioning adds an important layer of complexity to other areas: in particular the options available to the optimizer and analyze cost optimizer statistics. Depends on how you access your statistical data must be maintained on several levels now (level of score and at the global level, in the case of subpartitioning may be still at this level). If your data is important and you rely on "global" level statistics (these are always the case when the optimizer at the time analysis cannot limit access to a single partition) then in the pre - 11 g databases analyze these "global" level statistics can take a lot of time and resources, since actually , you need data several times (once for the partition and even global level).

  Presenting this partitioning may mean other potential problems in terms of execution that change (not for the better sometimes) plans and how to effectively collect statistics. Note that g 11 addresses the issue of 'statistics' by introducing the so-called "extra" global statistics. Greg Rahn wrote a [blog note | http://structureddata.org/2008/07/16/oracle-11g-incremental-global-statistics-on-partitioned-tables/] on this nice feature.

  >

  If true, what will happen when a partion fell?

  Since you're already on 10g, you can specify the database to update the scores of the local index using the UPDATE of the INDEX clause, while 9i could maintain only an overall index and it is up to you to rebuild the local index partitions after the partition DDL on the table (according to the DDL operation).

  Kind regards
  Randolf

  Oracle related blog stuff:
  http://Oracle-Randolf.blogspot.com/

  SQLTools ++ for Oracle (Open source Oracle GUI for Windows):
  http://www.sqltools-plusplus.org:7676 /.
  http://sourceforge.NET/projects/SQLT-pp/

  Published by: Randolf Geist on Sep 30, 2008 16:39

  Added statistics / optimizer warning when you use the partitioning

• Table Partitioned parallelized vs

  Hello
  (11.2 server, OS = OL5)
  
  I have a table that contains more than 50 million lines. I created this table with option 'parallel degree (x).
  
  It seems that the time required to execute a query on this table does not change when I share that, for example partition range dividing the table to 3 partitions.
  
  (access the request a unique index in the table and the query criteria match exactly one of the partitions)
  
  the question:
  1. What is the difference of strategy parallelism between «Parallel degree...» "and the"Division "?
  2. which of them are better in what scenario?
  3. is it better to use PARALLEL_AUTOMATIC_TUNING?
  4 and especially why the performance doesn't change even with a local index on the partitions?
  
  Thank you
  SMSK.

  >
  It seems that the time required to execute a query on this table does not change when I share that, for example partition range dividing the table to 3 partitions
  . . .
  (access the request a unique index in the table and the query criteria match exactly one of the partitions
  . . .
  @Adam Martin: thanks, but I was explained to question 4 that the performance does not change when I toggle locality index.
  >
  I do not see why it would be necessarily change just of partitioning. What is your reason to think so?

  If the index access is used it is basically to get the IDENTIFIER of a line of interest. The line can then be retrieved using the ROWID. The recovery time will be essentially the same way regardless of the line in a partitioned table or non-partitioned table, and regardless of whether the line of partition. This is because the ROWID is (simple explanation here) a FILE ID (which file?), a BLOCK number (relative block in the file) and a LINE NUMBER (which line in the block. It doesn't matter if the segment that is the block is a segment of the table, partitioned table segment, segment index, etc.

  It is the only factor that COULD change the time of the query when the index is used if the access of the index itself is more effective when the table is partitioned when the table is not partitioned.

  Clearly if it is an overall index, there is a change since the index access itself will be the same.

  The only factor now that MIGHT change the time of the request is so if 1) the index is changed locally and 2) the local index has a different structure than the old index that allows to find the best performing required index entries.

  You have not published information on the index of structure, so let me give you an analogy which shows a scenario where it is clear that the access to the index would not change.

  Assume that the overall index is analogous to a catalogue of cards with 26 entries - one for each letter of the alphabet. My query accesses the entries beginning with the letter 'F' As discussed above in table access to aid a ROWID obtained from the index will be the same, if the table is partitioned or not.

  So now I have the partition table and have 26 partitions - one for each letter of the alphabet.

  With the help of the global index of the access to the partition of 'F' will be the same.

  Now, if I create a local index (instead of global) it's almost as if I now 26 index, one for each letter of the alphabet. The first entry for the 'F' in the global index can be found by reading the root node and perhaps one or two other nodes - then that an index scan can be performed.

  The first entry for the 'F' in the local index is at the beginning of the index - no need to jump or to do a binary search to ignore the 'A', 'B', etc. entered.

  This time difference is microscopic.

  Once I found the first entry for the 'F' either in the overall index, or local 'F' remaining entries in the index are consecutive, so access time will be the same.

  I don't know if there is a structural difference between the indices and the that you tried, but the above should show if the structure (order) has not changed it would not be a noticeable difference in access.

• Count (*) using partitioned index gives incorrect results

  I have a table partitioned by hash with 4 index the.

  Table name: store_assortment

  clues the: idx1 (master_id), idx2 (store), idx3 (item), idx4 (request_id)

  When I run this query result is 13649:

  SELECT COUNT (*)

  OF store_assortment

  WHERE to store = 6010

  ORDER BY point;

  When I run this query result is 13648:

  SELECT COUNT (*)

  OF store_assortment

  WHERE store = 6010;

  I rebuild all indexes, but the results are the same. Can anyone point to a bug or something that can explain this?

  I dropped and recreated the indices and values are correct now. Reconstruction did not work.

  Thanks for all the help.

• Number of rows in each partition is displayed with a NULL value for a table partitioned in user_tab_partitions. Why?

  I created a table and partitioned on the date of the entry and added a local partitioned index.

  Now, I use a query to extract "num_rows" of user_tab_partitions to know the number of rows in each partition.

  Getting this value as null num_rows, wonder why?

  After looking to explain the Plan after interrogation ("select * from my_table1 where entry_date = 1 January 2015" ;))

  to find out if she actually partitioned table and its data in different partitions, I interpreted in effect because the query plan had a line like Partition_range (Single).

  My Question is:

  (a) is actually partitioned data (have I misinterpreted the Explain plan)

  (b) why is the num_rows null column in the query (Pasted below)

  (c) also in addition what difference it would have been if I had created a Global Index instead of the Local Index in my case?

  The following code Snippet:

  ----------------------------------------------------------------------------------------------

  create the table my_table1
  (
  roll_no number constraint my_table1_pk primary key,
  date of entry_date
  )
  partition of range (entry_date)
  (
  PARTITION data_p1 VALUES LESS THAN (TO_DATE (December 31, 2014 ',' DD-MM-YYYY ""));
  PARTITION data_p2 VALUES LESS THAN (MAXVALUE)
  );

  
  create an index only my_table1_indx on my_table1 (entry_date) local;

  ----------------------------------------------------------------------------------------------

  I now insert two lines:
  insert into my_table1 values (1, to_date ('01-01-2015', ' dd-mm-yyyy'));
  insert into my_table1 values (2, to_date('01-02-2015','dd-mm-yyyy'));

  ----------------------------------------------------------------------------------------------

  These have been inserted successfully, now using the query below shows num_rows column as null. I don't know why?

  SELECT table_name, num_rows, high_value, nom_partition
  Of user_tab_partitions
  where table_name = 'MY_TABLE1 '.
  ORDER BY table_name, nom_partition;

  ----------------------------------------------------------------------------------------------

  
  

  (a) is actually partitioned data (have I misinterpreted the Explain plan)

  Yes, it is partitioned. You can query this particular partition SELECT * FROM my_table1 (data_p1) PARTITION to check that.

  (b) why is the num_rows null column in the query (Pasted below)

  As already mentioned that you have not collected statistics.

  (c) also in addition what difference it would have been if I had created a Global Index instead of the Local Index in my case?

  In fact, you have created two types of indexes without knowing (can be)! One is not partitioned (although this column is not partition key) and another is partitioned (LOCAL). They are MY_TABLE1_PK and MY_TABLE1_INDX. You can check that USER_INDEXES.

  You can read this article to get an early jump on the partitioning of decision. Partition: Partition decisions

• deletion of a partitioned index

  Hi friends,

  I use 10.2.0.4 oracle on solaris.

  I have several partitioned index with the 2011 created on a daily basis. I tried to drop one of the indexes and got the below error.

  SQL > ALTER INDEX QOSDEV. PK_RATE_CISCOMEMORYPOOL DROP PARTITION 'OCTOBER 5, 2012 '.

  ALTER INDEX QOSDEV. PK_RATE_CISMEPOOL DROP PARTITION 'OCTOBER 5, 2012 '.

  Error on line 2

  ORA-14076: submitted alter index partition/subpartition operation is not valid for local partitioned indexes

  Script done on line 2.

  I ask you how to remove these partitions.

  Thank you

  DBApps

  Hello

  Try-

  ALTER drop partition table RATE_CISCOMEMORYPOOL 'October 5, 2012;

  Anand

• Partitioned index

  Using Oracle 11.2.0.3
  
  We are evalauating partitiong stragetegies with a view to the realization of gains from perfomnace in reports in particular.
  
  How effeicient are partitioned indexes in this by example anti-terrorism just partitioned index aan table is not partitioned.
  
  One big fact to durrogate keys that have bitmpa indxese table which link to accentuate associated key dimensions.
  
  Patitioning given bitmap index which links to the largest dimension and partitiong Kay dimesnion dimension laregts.
  
  Reflections on partitioned indexes would be particularly useful.
  
  Thank you

  user5716448 wrote:
  Using Oracle 11.2.0.3

  We are evalauating partitiong stragetegies with a view to the realization of gains from perfomnace in reports in particular.

  How effeicient are partitioned indexes in this by example anti-terrorism just partitioned index aan table is not partitioned.

  One big fact to durrogate keys that have bitmpa indxese table which link to accentuate associated key dimensions.

  Patitioning given bitmap index which links to the largest dimension and partitiong Kay dimesnion dimension laregts.

  Reflections on partitioned indexes would be particularly useful.

  Thank you

  It is not possible to create a partitioned index bitmp on a non-partitioned table. Bitmap indexes can be local partitioned only.
  --
  John Watson
  Oracle Certified Master s/n
  http://skillbuilders.com

• partion tables and indexes

  Hi all
  
  DB: 10.2.0.4
  
  Is that we can convert a normal table into partitioned tables?
  If Yes, then what is the existing indexes on this table?
  
  IM totally new about partitioning (Table and Index). I read the oracle docs but still have confusion with local and global index (score and no-partion)...
  
  
  Please suggest...
  
  Kind regards.

  >
  Is that we can convert a normal table into partitioned tables?
  If Yes, then what is the existing indexes on this table?
  >
  You can use the EXCHANGE PARTITION to do. See this article from the Oracle base
  Partitioning of an existing Table using the EXCHANGE PARTITION
  http://www.Oracle-base.com/articles/Misc/partitioning-an-existing-table-using-Exchange-partition.php

  Or you can use for DBMS_REDEFINITION do directly

  See this article from the Oracle base
  http://www.Oracle-base.com/articles/Misc/partitioning-an-existing-table.php

  You can also create a new table and INSERT the data from the old table.

  The option you are using could depend on indexes how you have, if you intend to keep them all and if the indexes on the partitioned table must be either local or global.

  To refine the new partitioned table, you really need evaluate each index to determine that the index should be global or local, and if the index should also be partitioned.

  There isn't any point to create a new table with the same indexes if you want to redefine all the indexes. You would be better of the backup of the original and then table drop indexes before conversion.

  See the VLDB and partitioning Guide
  http://docs.Oracle.com/CD/B28359_01/server.111/b32024/TOC.htm

• Split partition - index / local

  Hi friends,
  
  I'm trying to divide a table partition.
  
  Please let me know if the syntax below are correct.
  
  If the local index used
  
  ALTER TABLE SNYT. PART_ESTD
  ESTD_M13_S22 PARTITION SPLIT TO ('IS', 13, '22')
  IN (ESTD_M13_S21 PARTITION, PARTITION ESTD_M13_S22)
  update of the index;
  
  (by http://asktom.oracle.com/pls/asktom/f?p=100:11:0:::P11_QUESTION_ID:1401247200346349807)
  =================================================================
  
  If used Global indexes
  
  ALTER TABLE SNYT. PART_ESTD
  ESTD_M13_S22 PARTITION SPLIT TO ('IS', 13, '22')
  IN (ESTD_M13_S21 PARTITION, PARTITION ESTD_M13_S22)
  UPDATE GLOBAL INDEXES;
  
  Concerning
  KSG
  
  Published by: KSG on 23 August 2012 18:27
  
  Published by: KSG on 23 August 2012 18:51

  http://docs.Oracle.com/CD/E11882_01/server.112/e26088/statements_3001.htm#i2131218

  http://docs.Oracle.com/CD/E11882_01/server.112/e26088/statements_3001.htm#i2151566

• How to specify a table in Index?

  I've looked everywhere, I can think of for this: How can I specify a particular table in a table in Index?
  
  I found the statement "You can choose many options of creating table and table organizations (such as the partitioned tables, organized in tables and external tables index) meet the diverse needs of a company." in the SQL Developer Data Modeler 3.0 Users Guide, but not other references such as the way to achieve this.
  
  Thank you
  Mike

  You must open "Relational model", then "models". After choosing an Oracle implementation. Once this done, under "Tables", you will find your table in the physical model. Double-click the table that you want to make an IOT. On the "General" tab in the menu drop-down 'Organization' you can choose: "INDEX". 'Apply' ing and / or keys 'Ok' from the main menu, 'See'--> 'File DDL Editor_'--> 'Generate'--> 'Ok', you will see your table took the DDL generated for an IOT.

• Local partitioned indexes

  Hi all
  
  I created 2 local partitioned index. The indexes are indexes of function. the table size is 2.3 T.
  I created the first clue that it took 14 hours to create, and even to analyze and it works fine now. Then, I created second index. But now it does not.
  What should I do?
  
  version 11.1.0.6
  RAC, ASM
  
  Thanks in advance
  
  Published by: disaster on April 10, 2011 21:43
  
  Published by: disaster on April 10, 2011 21:51

  Dear Sir

  ----------------------------------------------------------------------------------------------------------
  | Id  | Operation              | Name         | Starts | E-Rows | A-Rows |   A-Time   | Buffers | Reads  |
  ----------------------------------------------------------------------------------------------------------
  |   1 |  PARTITION RANGE SINGLE|              |      1 |      1 |     82 |00:03:37.92 |     534K|    534K|
  |*  2 |   TABLE ACCESS FULL    | TBL          |      1 |      1 |     82 |00:03:37.92 |     534K|    534K|
  ----------------------------------------------------------------------------------------------------------
  

  It is the plan of the real explanation followed by the SQL engine to run your query

  The Oracle optimizer is the estimate (based on the statistics that you have collected about index and table) that your query will return only 1 rank (E-lines = 1) while in reality (when the query has been executed) it's return of 82 lines (A-Rows = 82) within 3 minutes and 37 seconds (A-Time = 00:03:37.92)

  It is clear that your index function that is not used.

  You should be aware that when you create a function based index, oracle will create a virtual column that is hidden behind the scene.

  Try to gather statistics on this column using dbms_stats.

  Please, try first to TEST

  BEGIN
     DBMS_STATS.gather_table_stats
                   (ownname             => user,
                    tabname             => 'TBL',
                    CASCADE             => TRUE,
                    method_opt         => 'FOR ALL HIDDEN COLUMNS SIZE 1'
                           );
  END;
  /
  

  and re - run your query and post once again the new plan explain him like you did before

  Best regards

  Mohamed Houri

• Global partitioned index hash

  Is it possible to create an index of global partitioned hash on the columns of the primary key of a table that is not partitioned itself?
  If a table has a PK constraint there an index generated automatically on the PK columns.
  Y at - it a syntax to make the overall index partitioned hash when creating the constraint of PK,.
  or syntax to MODIFY the indexes after the creation of the constraint?

  When you add a Pk to a table, you can choose a place already in the index. Something like

  alter table t1 add constraint T_PK primary key (col1) using index T_IDX;
  

  Create the partitioned index as you like with the same columns as the primary key and use the foregoing.

• How do you know the name of table or index that has the segment?

  Hi all
  
  I want to move the data to the LOB_TABSPC on LOB_TABSPC1 tablespace. I almost moved my data. But when I checked the LOB_TABSPC tablespace, there is still a segment:
  
  Line: -.
  Select dba_segments nom_segment, nom_partition, SEGMENT_TYPE, nom_tablespace, HEADER_FILE, HEADER_BLOCK, BYTES, BLOCKS, EXTENTS where OWNER = 'xxx' and nom_tablespace = 'LOB_TABSPC. '
  
  Rank # nom_segment nom_partition SEGMENT_TYPE nom_tablespace HEADER_FILE, HEADER_BLOCK BYTES BLOCKS SCOPES
  1 SYS_IL0000103064C00019$ $ SYS_IL_P87 INDEX PARTITION 18 59 131072 16 2 LOB_TABSPC
  2 SYS_IL0000103064C00019$ $ SYS_IL_P88 INDEX PARTITION 18 67 65536 8 1 LOB_TABSPC
  3 SYS_IL0000103064C00018$ $ SYS_IL_P83 INDEX PARTITION 18 27 196608 24 3 LOB_TABSPC
  4 SYS_IL0000103064C00018$ $ SYS_IL_P84 INDEX PARTITION 18 35 196608 24 3 LOB_TABSPC
  5 SYS_LOB0000103064C00018$ $ SYS_LOB_P81 LOB PARTITION 18 11 34603008 4224 48 LOB_TABSPC
  6 SYS_LOB0000103064C00018$ $ SYS_LOB_P82 LOB PARTITION 18 19 33554432 4096 47 LOB_TABSPC
  7 SYS_LOB0000103064C00019$ $ SYS_LOB_P85 LOB PARTITION 18 43 11534336 1408 26 LOB_TABSPC
  8 SYS_LOB0000103064C00019$ $ SYS_LOB_P86 LOB PARTITION 18 51 13631488 1664 28 LOB_TABSPC
  Line: -.
  
  I don't know the table or index that has these segments to move into the new tablespace.
  Please help me...

  Use the dba_lob_partitions view.

• ASM and table partitioning

  Hi gurus,
  a level of table colleague told me of partitioning is not necessary if the DSO is in place, the ASM can manage etc load balancing
  
  your expert opinion please...
  
  Thanks in advance,
  Charles

  Sorry, it's not true. ASM and partitioning are not related.

  ASM allows to balance the blocks for a table or an index on multiple disks, which can improve the IO.
  Split a table or index into small pieces to reduce the number of blocks that need to be analyzed and partitions allow parallelism.

  Even if you use ASM, you can benefit from partitioning of tables (but this is a design decision based on your data and queries that you run)