11g auto States meet on partitioned tables

Similar Questions

• Need to take stats twice for partitions and subpartitions?

  Hello world
  
  I'm taking a new approach for making statistics.
  
  First my system:
  
  Oracle 10.2.0.1
  3 instance RAC running on Linux RH AS 3, 64-bit
  
  I'm currently my stats using dbms_stats.gather_schema_stats with the option "rally car", it's good because only the data tables with stale and empty tables are being analyzed, but the process takes 3 to 4 days...
  
  Now I want to spread the statistical processes on nodes in the cluster using gather_table_stats (stale tables and empty tables only), while I was doing my procedure, I discovered the following, and here's where I need your help.
  
  If I run the following command:
  
  exec dbms_stats.gather_table_stats (ownname = > 'CACOSTA', tabname = > 'subpart_date', granularity = > 'SUBPARTITION', partname = > 'P200901')
  
  I can see the stats from my server BUT no stats have been taken for the partition.
  
  If I change the granularity on the "PARTITION": gather_table_stats
  
  exec dbms_stats.gather_table_stats (ownname = > 'CACOSTA', tabname = > 'subpart_date', granularity = > 'PARTITION', partname = > 'P200901')
  
  It will take the stats ONLY for the partition, but not for subparts.
  
  If I take the stats twice for 'PARTITION' and 'SUBPARTITION', I'll get all stats but it will take twice as long to complete.
  
  Is someone can you please tell me if I'm on the wrong approach? is it possible to understand that when I use the granularity of the "PARTITION", it can take the opportunity to use this same information it is collecting and provide statistics for subparts too to the RDBMS?
  
  Thank you and sorry for the long post.
  
  Carlos Acosta

  Carlos Acosta wrote:
  I'm taking a new approach for making statistics.

  First my system:

  Oracle 10.2.0.1
  3 instance RAC running on Linux RH AS 3, 64-bit

  exec dbms_stats.gather_table_stats(ownname=>'CACOSTA',tabname=>'subpart_date',granularity=>'SUBPARTITION',partname=>'P200901')

  I can see the stats from my server BUT no stats have been taken for the partition.

  If I change the granularity on the "PARTITION": gather_table_stats

  exec dbms_stats.gather_table_stats(ownname=>'CACOSTA',tabname=>'subpart_date',granularity=>'PARTITION',partname=>'P200901')

  It will take the stats ONLY for the partition, but not for subparts.

  If I take the stats twice for 'PARTITION' and 'SUBPARTITION', I'll get all stats but it will take twice as long to complete.

  Is someone can you please tell me if I'm on the wrong approach? is it possible to understand that when I use the granularity of the "PARTITION", it can take the opportunity to use this same information it is collecting and provide statistics for subparts too to the RDBMS?

  Carlos,

  This composite partitioning (range-list, range-hash) do you use?

  First of all I think it's important to understand that statistical subpartition will actually not to be used by the cost based optimizer in previous versions 10.2.0.4 (but in 10.2.0.4 only with bugs without patch installed, see the link to the message below) and 11.1.0.6:

  http://Oracle-Randolf.blogspot.com/2007/03/subpartitions-and-optimizer-statistics.html

  http://Oracle-Randolf.blogspot.com/2008/04/revisiting-subpartition-pruning-and.html

  http://Oracle-Randolf.blogspot.com/2009/03/partition-oddities-part-1-severe-bug-in.html

  So, I'd be interested to see a case in the database pre - 10.2.0.4 where the optimizer actually using subpartition level statistics; I have not yet found one.

  Second, he must be aware of what Oracle offers several ways how to maintain the different level of statistics:

  -Less consumption of resources, but less quality: collection of statistics on the lowest level (e.g. subpartition) only. I hope all subparts of the partition have statistics, the higher levels (partition / global) will be inspired by the aggregation. This way, you get the low quality statistics on levels higher (e.g. no histograms will be generated by aggregation, number of distinct values potentially quite inaccurate), but you do not need to collect statistics on these levels. Note that if once you have collected statistics on the higher levels (indicated by the "GLOBAL_STATS = YES" column in the DBA_\ * views STATISTICS) will not perform this statistical aggregation. You must first remove the statistics of higher level using DELETE\ * _STATS have enabled new aggregation (next time gather you statistics on low levels and all partitions (sub-) have statistics)

  For more information about this approach, see for example here: http://oracle-randolf.blogspot.com/2008/04/exchange-partition-and-aggregated.html

  -Consumption of resources, but of better quality most: separate statistics on all levels

  - And the new modes supported by 10.2.0.4 and especially 11.1.0.6: APPROX_GLOBAL AND PARTITION (10.2.0.4), true incremental global statistics in 11.1.0.6 and the new algorithm for estimating AUTO_SAMPLE_SIZE introduced in 11g:

  http://structureddata.org/2008/07/16/Oracle-11g-incremental-global-statistics-on-partitioned-tables/

  http://structureddata.org/2007/09/17/Oracle-11g-enhancements-to-DBMS_STATS/

  http://optimizermagic.blogspot.com/2009/02/maintaining-statistics-on-large.html

  Another very good synthesis about the management of statistics has recently been published by Karen Morton: http://karenmorton.blogspot.com/2009/02/new-paper-and-cj-date-advert.html

  So in your case a database pre - 10.2.0.4 you should not bother with subpartition statistics at all (or you can show me otherwise I would be interested), and you can then try to find out if you could live with the above statistical approach of "sum" by simply collecting statistics on the level of partition, or if you need to collect statistics on the partition and the global level separately (you did not mention your current strategy to the global level statistics).

  If you install the 10.2.0.4 patch game you have several options and statistics subpartition can be used by the optimizer (but only in the case of beach-list composite partitioning, as far as I know), for example by using the option of PARTITION AND APPROX_GLOBAL introduced in this version. Note that you must install the unique patches to get this working properly as described by my post and the optimizer of blog post for the development group.

  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/

• 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

• importing into a partitioned table of interval 11g

  as I took export utility simple partition table 8i exp not rained so 100 k lines in there.
  
  and imported with the import utility in the interval of 11g partitioned based on the date column.
  
  There were imported, but did not what I expected...
  
  If we execute the simple insert for partition interval 11g command, it create new partition automatically according to the strategy of partition.
  
  Here's the demo...
  
  created range partitioned table on the date with shift interval column...
  
  CREATE TABLE TEST.xxx_HIST
  (
  xxx_DATE DATE NOT NULL,
  P_ROLL_CONVENTION CHAR (2),
  R_ROLL_CONVENTION CHAR (2),
  P_COMPOUNDING_IND CHAR (2),
  R_COMPOUNDING_IND CHAR (2),
  P_CALC_METHOD CHAR (2),
  R_CALC_METHOD CHAR (2),
  P_SPREAD_AMT NUMBER (28,12).
  R_SPREAD_AMT NUMBER (28,12).
  
  )
  partition by range (xxx_DATE)
  interval (numtoyminterval(3,'MONTH'))
  store (security)
  (
  values of pQ1 lower partition (to_date('2010-01-01','yyyy-mm-dd'))
  ) IN PARALLEL.
  
  
  -IMPORTED FROM ROWS IN THE TABLE...
  
  ======================================================================
  Connected to: Oracle Database 11 g Enterprise Edition Release 11.1.0.7.0 - 64 bit Production
  With partitioning, OLAP, Data Mining and Real Application Testing options
  
  Export file created by EXPORT: V08.01.07 direct
  
  CAUTION: objects have been exported by SYSTEM, not by you
  
  . import of xx_ARCH in TEST objects
  . . import of 141749 lines imported from the table 'xxx_HIST '.
  Import completed successfully without warnings.
  ========================================================================
  
  
  
  -HE HAS A LOT OF DATES OF DIFF IN THERE...
  
  
  
  SQL > SELECT COUNT (DISTINCT xxx_DATE) TEST.xxx_HIST;
  
  COUNT (DISTINCT xxx_DATE)
  -----------------------------
  1371
  
  
  28-MARCH 06
  10 FEBRUARY 06
  9 FEBRUARY 05
  20 FEBRUARY 02
  3 JUNE 02
  10 MAY 04
  26 DECEMBER 03
  31 JANUARY 03
  
  xxx
  ---------
  21 JULY 08
  31 OCTOBER 05
  25 APRIL 08
  28 APRIL 08
  12 OCTOBER 06
  DECEMBER 21 07
  28 DECEMBER 04
  
  
  -BUT STILL ALL DUMPED INTO A PARTITION
  
  
  SQL > SELECT nom_partition FROM DBA_TAB_PARTITIONS WHERE TABLE_OWNER = 'TEST ';
  
  NOM_PARTITION
  ------------------------------
  PQ1
  
  It all dumped in a partition...
  
  fact partition interval 11g creates the partition automatically in function whose lines if imported... when we import lines in there...? or am I missing something?
  
  any idea guys?

  Seems to be a poor strategy for me because if I am not mistaken, there is no way to specify the order of the imported lines. If you import a line with the date max as your first row... bang, you get a range partition created for you and the rest falling.

  I think you'd be better import these data into a table in step and then by a

  insert into new_fancy_partition_table
  select *
  from old_8_temporary_imported_table
  order by date_column asc
  

  Or create the partitions manually.

  I just realized that you specify a partition in your create table statement (missed that on cursory inspection). And I think you misunderstand how the interval works... it's for values LARGER than the existing partitions ONLY...

  http://download.Oracle.com/docs/CD/E11882_01/server.112/e10592/statements_7002.htm#SQLRF01402

  "
  INTERVAL clause

  Use this clause to set the interval of partitioning the table. Range partitions are partitions based on a digital range interval or datetime. * They extend from range partitioning by commanding the database to automatically create partitions of the specified range or interval when the data inserted in the table exceed all the partitions.* range
  "

  Published by: Tubby on August 16, 2010 18:32

  Additional document link.

• Is it possible to copy a table partitioned to another different partitioned table statistics?

  Hello

  Using oracle 11.2.0.3 and study the possibility to copy his stats of a hash range partitioned table to another partitioned table range-hash.

  New table is based on the old table with the same structure, about right. of lines.

  estimate_percent auto not practical sample - size took 10 hours in tests and careful to just down for example 1% percent estimate.

  Is it possible to simply copy the stats on our old table

  Thank you

  Mismatch / typo in statid?

  statid-online "CURRENT_STATS."

  statid => ' CURRENT_STATUS

• Compression is disabled when performing the update on partitioned tables

  
  Hi all

  I'm on Oracle Database 11 g Enterprise Edition Release 11.2.0.3.0.

  My question is related to the Compression of the Oracle.

  I have an infra partitioned table enabled with Compression of the base. Active compressed State, I update some columns in this table (command Update Normal and merger as well) but the end result shows the increase in the size of the table and the compression is still in the ACTIVE State. After that, if I compress the secondary partition explicitly the table back to its original size.

  Is this a bug? I read a whitepaper on 11g itself, compression is turned on in the case of all DML operations, so why this behavior?

  Thank you

  Ishan

  Ishan,

  take a look at http://docs.oracle.com/cd/E11882_01/server.112/e25494/tables.htm#CJAGFBFG , it seems that the distinction between OLTP and compression of base is sometimes a bit vague ("operations that allow compression include:...") "), but I also find the statement"insert rows inserted without using direct-path access and updated rows are uncompressed. "So I would say it's not a bug but a limitation of the service. Updates just to not mix well with compression.

  Martin

• To access large partitioned tables over a database link - traps?

  Hello
  
  We are in the middle of a business acquisition, and I have a question on the use of links to database access efficiently to large tables. There are two distinct geographical database instances, both on Oracle 10.2.0.5 sitting on Linux boxes.
  
  The main forum (PSHR) contains a PeopleSoft HR system and pays and is sitting in our data center.
  
  The secondary instance (HGPAY) runs a payroll application home grown and is in a different datacenter to PSHR.
  
  The requirement is to allow PeopleSoft (PSHR) to display data of payroll (one employee at a time) targeted to the secondary instance.
  
  For example in HGPAY
  
  CREATE TABLE MY_PAY_DATA AS
  SELECT TO_CHAR (A.RN, ' 00000000') 'EMP' - it is a figure 8 leading 0 unique identifier
  '20110' | TO_CHAR (B.RN) "PAY_PRD" - it is a format of exercise more than fifteen days in the year (01-27)
  C.SOME_KEY - it is the element of remuneration being considered - effectively randomly
  , 'XXXXXXXXXXXXXXXXX' "FILLER1.
  , 'XXXXXXXXXXXXXXXXX' "FILLER2".
  , 'XXXXXXXXXXXXXXXXX' "FILLER3".
  FROM (SELECT ROWNUM 'RN' FROM DUAL CONNECT BY LEVEL < = 300) has
  , (SELECT ROWNUM 'RN' FROM DUAL CONNECT BY LEVEL < = 3) B
  (SELECT TRUNC (ABS (DBMS_RANDOM. (Random())) 'SOME_KEY' FROM DUAL CONNECT BY LEVEL < = 300) C
  ORDER OF PAY_PRD, EMP
  
  HGPAY. MY_PAY_DATA is the range partitioned on EMP (approximately 300 employees by partition) and the list below partitioned on PAY_PRD (3 pay periods a secondary partition). I limited the above create statement to represent a sub-partition of data.
  Every employee generates an average of 300 lines in this table each pay period. The table has about 180 million lines and all fifteen days more.
  
  In PSHR
  
  CREATE VIEW PS_HG_PAY_DATA (MEP, PAY_PRD SOME_KEY FILLER1, FILLER2, FILLER3)
  AS SELECT EMP, PAY_PRD SOME_KEY FILLER1, FILLER2, MY_PAY_DATA@HGPAY FILLER3
  
  PeopleSoft would then generate SQL along the lines of
  
  SELECT * FROM PS_HG_PAY_DATA WHERE EMP = '00002561' AND PAY_PRD = '201025'
  
  The link between data centers where PSHR and HGPAY sit isn't the best in the world, but I expect dozens of hits per day rather than thousands, so I think that the link must have sufficient bandwidth to meet the requirements.
  
  I tried a quick test on two instances of size production test and it works because it presents the data, when I look at the plan of the explain command that I can see that the remote database is only presenting the relevant secondary partition on PSHR rather than the entire table. Until I get in the back with a "job well done" - y at - it a witch hunt that I am absent using dblink to access the partitioned tables of big?

  Yes, it's just. A lot of it depends on exactly what happens in different "oops" scenarios - you are, for example, just burn some CPU extra until someone comes to the DBA and says "my query is slow" or saturating the network has an impact on critical applications or long random queries prevent some maintenance operations of partition.

  In my mind, the simplest possible solution (assuming you are using a username that is fixed in the database link) would be to create a profile on HGPAY for user defined for the link of database that set a value LOGICAL_READS_PER_CALL which was large enough to handle any request '' reasonable '' and low enough to quickly kill any session that has tried to do something 'stupid '. Obviously, you have to define 'stupid' in your particular environment where the scope of a 'simple reconciliation report' is not defined. If there is no political problem and you can adjust the values of profile to the wire when you encounter new reports that slowly increase what is considered '' reasonable '' is probably the most straightforward approach. If you have to put in a change request to change the parameter which must be reviewed by the Control Board change at its next quarterly meeting with the outsourced DBA seller, on the other hand, you could turn a report by 30 minutes in 30 hours over 30 days. However, in an ideal world, this is where I would start.

  Becomes more complex, you can use the resource manager to kill applications running too long on the wall clock. Since the network will almost certainly the bottleneck, it is probably unlikely that the limitation of the CPU will do much good - probably you can saturate the network with a very small amount of CPU. Limitation in my mind of the network is an additional step in complexity according to the specifics of your situation and what you are competing with.

  Justin

• Collection of statistics on partitioned and non-partitioned tables

  Hi all
  My DB is 11.1
  
  I find that the collection of statistics on partitioned tables are really slow.
  

  TABLE_NAME                       NUM_ROWS     BLOCKS SAMPLE_SIZE LAST_ANALYZED PARTITIONED COMPRESSION
  ------------------------------ ---------- ---------- ----------- ------------- ----------- -----------
  O_FCT_BP1                        112123170     843140    11212317 8/30/2011 3:5            NO                    DISABLED
  LEON_123456                      112096060     521984    11209606 8/30/2011 4:2           NO                   ENABLED
  O_FCT                           115170000     486556      115170 8/29/2011 6:3            YES         
  
  SQL> SELECT COUNT(*)  FROM user_tab_subpartitions
    2  WHERE table_name =O_FCT'
    3  ;
  
    COUNT(*)
  ----------
         112

  I used the following script:

  BEGIN
    DBMS_STATS.GATHER_TABLE_STATS(ownname          => user,
                                  tabname          => O_FCT',
                                  method_opt       => 'for all columns size auto',
                                  degree           => 4,
                                  estimate_percent =>10,
                                  granularity      => 'ALL',
                                  cascade          => false);
  END;
  /

  It costs 2 minutes for the first two tables to gather statistics respectively, but more than 10 minutes for the partitioned table.
  Time of collection of statistics represents a large part of the time of the whole lot.
  Most of the work of the lot are at full load, which case all partitions and subpartitions will be affected and we cannot collect just specified partitions.
  
  Does anyone have experiences on this subject? Thank you very much.
  
  Best regards
  Leon
  
  Published by: user12064076 on August 30, 2011 01:45

  Hi Leon

  Why don't collect you statistics to the partition level? If your data partitions will not change after a day (score range date for ex), you can simply do to the partition level

  GRANULARITY-online 'SCORE' for partition level and
  GRANULARITY-online 'SUBPARTITION' for subpartition level

  You collect global stats whenever you can not require.

  Published by: user12035575 on August 30, 2011 01:50

• Qosmio x 500 - 14W - invalid partition table

  Hay guys,

  I wanted to start my Toshiba Quosmio x 500 - 14W PQX33E (Product Code), but the only thing I found on my desk: invalid partition table.

  In another Forum I found a threat, which means I have to restart my computer. So I tried a Reboot Cd, but found nothing. Then I tried to call the Call Center of Toshiba, but they are closed...

  For me, is the Toshiba Service miserably and I hope that some guys from the Forum can help me.

  Thank you
  Paul

  Hello

  You must install the operating system once more.
  Invalid partition table means that something is wrong with the HARD drive and the operating system cannot start.
  So if you n t have a recovery disk, you must order one:
  http://backupmedia.Toshiba.EU/landing.aspx

  PS: I made good experience with the Toshiba service comparing the service with another laptop from the manufacturer I have to say that s OK and I meet a lot of people who said that other manufacturers are not really better
  Which; s my opinion

• How to recover the partition table (corrupt) for the partition in good health?

  Partition (drive H) was working fine, then I rebooted my system normally and the drive is now inaccessible.

  "An error occurred reading the file: the file or directory is corrupted and unreadable." (1392).

  Window CMD CHKDSK says NTFS file system and "unable to determine the State and version volume.»

  [This is a disk external drive with 2 partitions on it - H and Mr. the second partition (drive M) discs works fine.]
  [Vista Ultimate OS]

  Is there a way I can get it to work or get the data off of it?

  Try the procedure described in the article below

  http://www.ehow.com/how_7500292_recover-bad-partition-table.html

• Partition table does not have a valid system partition

  I am working on a Dell XPS 420 computer for a customer.  She has Windows Vista installed on it (not sure what version of Vista).

  He's doing a loop, wherever it loads to the point where I can see the bottom and the mouse, but it stops there.  After 5 minutes of him sitting on this screen, it restarts, I can't access one of the Advanced menu F8.  I tried Safe Mode, and after that it loads the crcdisk it restarts, it does with Safe Mode, Mode safe mode with networking Mode and safe mode with command prompt.  I can't use the last known configuration because it will just try to load and eventually restart.

  Things I've tried is that I ran a diagnosis of hard drive and memory, and they both pass.

  I tried the repair with the regedit option and load the system hive in the registry.

  I tried the bootrec command.

  Well I put in a disk for Installation of Vista and choose the repair option.  I did the auto diagnosis and repair option (first choice I think) and I checked the report after he finished saying that it fixes itself and needed to restart (which he did not in fact)

  Well the result that came was that the Partition Table does not have a valid System Partition.

  I tried the bootrec command, and they all said it has repaired but it did not, when I tried to do the bootrec /rebuild he gave me the message "element not found".

  I ran a test diagnosis system and I received the following message

  System test
  error code 0146
  Msg error code 2000-0146
  MSG HDD 0 - self-test log contains previous errors. Given the code and can be used by the support message technology guide to help diagnose the problem.

  be honest, I just need to know if I need to replace the hard drive or not, it's for a customer.

  I did not see if the HDD is set to AHCI or SATA in the bios again, but I will when I get home today, but I would like some answers backup.

  Hi countryboyofal,

  I suggest that you contact Dell support for the outcome of the diagnostic system.

  http://support.Dell.com/support/topics/global.aspx/support/DellCare/contact_us?c=us&l=en&s=Gen&redirect=1

   

  I hope this helps!

  Halima S - Microsoft technical support.

  Visit our Microsoft answers feedback Forum and let us know what you think.

• How to create a partitioned table

  Apex 4.2

  Oracle 11g

  There is a large table, which have 160000 rows, I would like to create a partitioned table to improve performance, but could not find a way to create a.

  Concerning

  Hello

  I don't see how your question relates to APEX, unless you mean how to make APEX builder object Explorer.

  Answer is simple, you can do it from the object browser.

  You should write a ddl script to create the partitioned table, and run it from sql commands.

  Kind regards

  Jari

• Size of partition on interval range partitioned Table happens when SYSDATE is used in a Where Clause

  We have tables interval range partitioned on a DATE, with a partition for each day column - very standard and straight out of doc Oracle.

  A 3rd party application queries the tables to find the number of rows based on the date range that is located on the column used for the partition key.

  This application uses the date range specified from the current date - i.e. for last two days would be «...» StartDate > SYSDATE-2 "- but the partition size is irrelevant and the explain command plan shows that each partition is included."

  In presenting the request uses the date in a variable partition size location and query table is obviously much better.

  DB is 11.2.0.3 on RHEL6, and default settings - i.e. nothing that could influence the behavior of the optimizer to something unusual.

  I can't work on why this would be the case. It is very easy to reproduce with cases of simple test below.

  I would be very interested to hear any views on why it's that way and if anything can be done to allow the size of the partition to work with a query including SYSDATE because it would be difficult to get the application code has changed.

  In addition to make a case to change the code, I need an explanation of why query using SYSDATE is not advisable and I know this information.

  (1) create a simple partitioned table

  CREATETABLE part_test
     (id                      NUMBER NOT NULL,
      starttime               DATE NOT NULL,
      CONSTRAINT pk_part_test PRIMARY KEY (id)) 
  PARTITION BY RANGE (starttime) INTERVAL (NUMTODSINTERVAL(1,'day')) (PARTITION p0 VALUES LESS THAN (TO_DATE('01-01-2013','DD-MM-YYYY')));
  

  (2) fill in the rows of the table 1 million distributed among 10 partitions

  BEGIN
      FOR i IN 1..1000000
      LOOP
          INSERT INTO part_test (id, starttime) VALUES (i, SYSDATE - DBMS_RANDOM.value(low => 1, high => 10));
      END LOOP;
  END;
  /
  EXEC dbms_stats.gather_table_stats('SUPER_CONF','PART_TEST');
  

  (3) to query the Table of data from the last 2 days using SYSDATE in paragraph

  EXPLAIN PLAN FOR 
  SELECT  count(*) 
  FROM    part_test
  WHERE   starttime >= SYSDATE - 2;
  

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

  | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |

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

  |   0 | SELECT STATEMENT |           |     1.     3 ×  7895 (1) | 00:00:01 |       |       |

  |   1.  GLOBAL TRI |           |     1.     3 ×            |          |       |       |

  |   2.   RANGE OF PARTITION ITERATOR.           |   111K |   867K |  7895 (1) | 00:00:01 |   KEY | 1048575.

  |*  3 |    TABLE ACCESS FULL | PART_TEST |   111K |   867K |  7895 (1) | 00:00:01 |   KEY | 1048575.

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

  Information of predicates (identified by the operation identity card):

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

  3 - filter("STARTTIME">=SYSDATE@!-2)

  (4) now do the same query, but with SYSDATE - 2 presented as a literal value.

  This query returns the same response but very different cost.

  EXPLAIN PLAN FOR
  SELECT count(*) 
  FROM part_test
  WHERE starttime >= (to_date('23122013:0950','DDMMYYYY:HH24MI'))-2;
  

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

  | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |

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

  |   0 | SELECT STATEMENT |           |     1.     8.   131 (0) | 00:00:01 |       |       |

  |   1.  GLOBAL TRI |           |     1.     8.            |          |       |       |

  |   2.   RANGE OF PARTITION ITERATOR.           |   111K |   867K |   131 (0) | 00:00:01 |   356 . 1048575.

  |*  3 |    TABLE ACCESS FULL | PART_TEST |   111K |   867K |   131 (0) | 00:00:01 |   356 | 1048575.

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

  Information of predicates (identified by the operation identity card):

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

  3 filter ("STARTTIME" > = TO_DATE (' 2013-12-21 09:50 ',' syyyy-mm-dd hh24:mi:ss'))))

  Thank you in anticipation

  Jim

  sysdate is not constant and its value may change from time optimization of execution; but the optimizer can deduce that he will be a known running value and then produce a plan that will make the size of partition running.  This is the meaning of 'KEY' in the column pstart – the partition of departure will be known at run time and the size of partition will take place in order to eliminate the previous partitions.

  Concerning

  Jonathan Lewis

• Scans of partition take longer than a full table on a non-partitioned table scan?

  Hello

  I have a PART_TABLE range partitioned table that has 10 million documents and 10 partitions having 1 million records each. Partition is based on a column named ID, which is a sequence of 1 to 10 million.

  I created another P2_BKP table (do a select * from part_table) which has the same group of data than that of PART_TABLE, except that this table is not partitioned.

  Now, I run the same query on the tables to get a range of data. Precisely, I'm reading only the data present in 5 partitions of the partitioned tables that requires theoretically less reading than when done on non partitioned tables.

  Yet the query seems to take more time on a table that is partitioned only when running on a non-partitioned table. No reason precisely why is this the case?

  Here's the query I am trying to run on the tables and their Plans to explain corresponding.

  ASK A

  =========

  Select * from P2_BKP where id < 5000000;

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

  | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time |

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

  |   0 | SELECT STATEMENT |        |  6573K |   720 M | 12152 (2) | 00:02:26 |

  |*  1 |  TABLE ACCESS FULL | P2_BKP |  6573K |   720 M | 12152 (2) | 00:02:26 |

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

  QUERY B

  ========

  Select * from part_table where id < 5000000;

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

  | ID | Operation | Name | Lines | Bytes | Cost (% CPU). Time | Pstart. Pstop |

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

  |   0 | SELECT STATEMENT |            |  3983K |   436 M | 22181 (73) | 00:04:27 |       |       |

  |   1.  RANGE OF PARTITION ITERATOR.            |  3983K |   436 M | 22181 (73) | 00:04:27 |     1.     5.

  |*  2 |   TABLE ACCESS FULL | PART_TABLE |  3983K |   436 M | 22181 (73) | 00:04:27 |     1.     5.

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

  016f62a3-35cf-4f4e-B812-95774e4d662f wrote:

  Now, I run the same query on the tables to get a range of data. Precisely, I'm reading only the data present in 5 partitions of the partitioned tables that requires theoretically less reading than when done on non partitioned tables.

  Yet the query seems to take more time on a table that is partitioned only when running on a non-partitioned table. No reason precisely why is this the case?

  Have you actually run the queries, or you assume that they will take different amounts of time because the execution plans show different numbers?

  It is clear from the output of the execution plan that the statistics are not very good, since Oracle should have estimated about 5 M of lines for each request. That said, however, Oracle should have used the counties of partition block level to estimate the cost of the analysis of the 5 score - and we could expect them to a total of less space than a full copy.

  Of course, it is possible that your partitioned table has been the subject of many DML involving the line movement and line of chaining; It is possible he has been the subject of many lots of parallel or direct path loads inserts leaving much free space in each partition. It is also possible that you have created the copy in a tablespace that table of default compression!

  What are the stats for the original table partition level?   (select nom_partition, num_rows, blocks of user_tab_partitions where table_name = 'T1' partition_position order)

  Concerning

  Jonathan Lewis

• Unusable index Partitioned table

  Oracle Version: 11.2.0.2
  OS: Linux RHEL 5
  
  I'm having a problem with the index on a partitioned table interval. This is the scenario:
  
  There are 3 indices (A, B, C) on a table. A is created on two columns (1,2), B is on the column (2), C is the column (3). Table is partitioned on column 2 apart. A and B are partitioned indexes. When I drop a partition without a clause to update index, Index C will unusable. After seeing this, I gave up the C rating and create it as a local partitioned index, then all indexes are in condition of use after the drop partition statement. Is - this mandatory on a range partitioned table all indexes on the table must be locally partitioned inorder to have indexes in usable state after the drop statement of partition (without the update index clause)? Also there will be a negative impact for all indexes on the table like locally partitioned indexes?

  >
  Is - this mandatory on a range partitioned table all indexes on the table must be locally partitioned inorder to have indexes in usable state after the drop statement of partition (without the update index clause)?
  >
  Yes - it should be obvious by looking at a simple example.

  You have an OVERALL index and drop a partition but say Oracle are NOT updating the overall index.

  How this index may be usable for anything? It is not accurate. There was GARBAGE everywhere that gets in the way of Oracle find the entries of the "good". There are the index keys in the branch blocks that belong to the partition that has been deleted. Oracle cannot use these keys to determine how the blocks of branch, he needs to find.
  >
  Also there will be a negative impact for all indexes on the table like locally partitioned indexes?
  >
  Who knows? There are maybe or maybe not.

  As with many things Oracle "it depends."

  It depends on what types of queries that you ran.

  It depends on the filter predicates used for query.

  It depends on if the maintenance simple score (add/drop/split) are important to you.

  For the maintenance of the partition only all index LOCAL is the best.

  For full table scan, an index is not intended to be used.

  For a query that needs all THE records for a COMPANY_ID given in a table partitioned by DATE an OVERALL index could be better. Oracle also use 100 index LOCAL (if there are 100 partitions) to get the same data.

  It depends on.