Query on partitioned Table

Similar Questions

• query the partition tables

  Hi all
  
  I want to query the partition tables that are over 1 GB in size?
  
  How can I ask questions?

  Salvation;

  You can also try with dba_tab_partitions view

  Respect of
  HELIOS

• query running too long on a partitioned table

  Hello
  I try to run the following query on a table of line 73 million, but the application continues running and works without any results back within a reasonable time.
  
  Select *.
  of svcdepot.service_log l
  where dbms_lob.instr (l.service_log, 'SALESFORCE_ROLE_CREATED') > 0 and rownum < 2
  and create_date > sysdate-.1
  
  This table has a normal index on the create_date table and is also divided on create_date. Partition names as PARTITION20120316 and PARTITION20120311. It shows values lower than TIMESTAMP' 2012 - 03 - 16 00:00:00 'and TIMESTAMP' 2012-03-11 00:00:00 ', respectively. Is could someone please tell me how I can change the query so that it does not forever? He seems to fight the create_date column (while I was troubleshooting). I just need one record with this SALESFORCE_ROLE_CREATED text in this clob column.
  
  Thank you!

  Hello

  It would be helpful if you mentioned the name of the partition in the query. For example, for superior to sysdate create_date-. 1, you don't need to go through the full table and only the partition created for today would be sufficiient.
  for example
  Select *.
  svcdepot.service_log PARTITION (PARTITION20120312) l
  where dbms_lob.instr (l.service_log, 'SALESFORCE_ROLE_CREATED') > 0 and rownum<>
  and create_date > sysdate-.1
  If you use this query in PL/SQL program, you will need to create this dynamic partition name and dynamic SQL can be used.

• How to configure the partition table for SSD?

  Drive: 32 GB SSD

  I accidentally delete without backup partition table information and would like to know how to put the partition table, I can access the tools of partition table, but do not know how to define.

  Does anyone have any suggestions?

  Thanks in advance for your suggestions

  Hello

  Thanks for posting your query in Microsoft Community.

  The SSD could be seen in the disk management window, and you could name and set up as another hard drive internal. To create a partition or volume on a hard disk, you must be logged in as an administrator, and there must be unallocated disk space or free space in an extended hard disk partition. To repartition your hard drive, please consult the following link and check if it helps.

  I can I repartition my hard disk?

  Additional information:

  Create a new Partition on a hard disk in Windows 7

  Hope this information is useful. Let us know if you need more help, we will be happy to help you.

• Partitioning of an existing partitioned table

  Dear Experts,

  I have a problem with redefinition of partitioning of an existing partitioned table. I have a parent table separated by a virtual column by range:

  CREATE THE PARENT TABLE

  (

  PARENT_ID NUMBER NOT NULL,

  INSERT_TIMESTAMP TIMESTAMP (6) NOT NULL,

  CLOB PARENT_DATA NOT NULL,

  BATCH NUMBER,

  DATE of INSERT_DATE generated always as (TRUNC("INSERT_TIMESTAMP"))

  )

  LOB (PARENT_DATA) AS STORE NAVIGATION (ACTIVATE ONLINE STORAGE)

  PARTITION BY RANGE (INSERT_DATE)

  (

  P2015_11 PARTITION VALUES LESS THAN (TO_DATE (' 2015-12-01 00:00:00 ',' SYYYY-MM-DD HH24:MI:SS ',' NLS_CALENDAR = GREGORIAN '))

  CRAFT STORE (PARENT_DATA) AS (SECUREFILE

  ACTIVATE THE ONLINE STORAGE),

  P2015_12 PARTITION VALUES LESS THAN (TO_DATE (' 2016-01-01 00:00:00 ',' SYYYY-MM-DD HH24:MI:SS ',' NLS_CALENDAR = GREGORIAN '))

  CRAFT STORE (PARENT_DATA) AS (SECUREFILE

  ACTIVATE THE ONLINE STORAGE),

  P2016_01 PARTITION VALUES LESS THAN (TO_DATE (' 2016-02-01 00:00:00 ',' SYYYY-MM-DD HH24:MI:SS ',' NLS_CALENDAR = GREGORIAN '))

  CRAFT STORE (PARENT_DATA) AS (SECUREFILE

  ALLOW ONLINE STORAGE,

  PARTITION P_DEFAULT VALUES LESS THAN (MAXVALUE)

  CRAFT STORE (PARENT_DATA) AS (SECUREFILE

  ALLOW ONLINE STORAGE

  ))

  );

  and a child table partitioned by reference:

  CREATE ACCOUNTS FROM THE TABLE. CHILD

  (

  PARENT_ID NUMBER NOT NULL,

  DATAACC DATAACC_TBL,

  CREATION_DATE DATE,

  CONSTRAINT PARENT_D_E_PRT_FK

  FOREIGN KEY (PARENT_ID)

  (PARENT_ID) REFERENCES PARENT

  ENABLE VALIDATE

  )

  NESTED TABLE, STORE DATAACC AS DATAACC_NT

  PARTITION OF REFERENCE (PARENT_D_E_PRT_FK)

  (

  P2015_11 PARTITION,

  P2015_12 PARTITION,

  P2016_01 PARTITION,

  PARTITION P_DEFAULT);

  However, now in Oracle 12 c I am able to use the reference interval partitioning. How can I redefine the partitioning of the parent table so that there can be scope-level?

  Thank you for your help.

  Best regards, Atanas.

  To change range partition to partition interval, the table should not have MAXVALUE partition... Follow the steps below to convert to partition interval

  (1) check if all data of the MAXVALUE partition (p_default) using query below

  SELECT COUNT (*) FROM parent PARTITION (p_default).

  (2) if there is no trace in the p_default partition, drop the help below

  ALTER TABLE DROP PARTITION parent p_default;

  (3) use the clause SET INTERVAL to convert the range partition partition interval as below

  ALTER TABLE parent SET INTERVAL (NUMTOYMINTERVAL(1,'MONTH'));

  I guess, you have the range partition up to until, so there should not be any folder in p_default partition.

• CTXCAT index on partitioned tables

  Hi all

  I use an oracle 11.2 database and try to use the index for a sample application oracle CTXCAT.

  I saw that oracle reference documentation "the CTXCAT index can't stand table and index partitioning, not...» "in http://docs.oracle.com/cd/B28359_01/text.111/b28303/ind.htm#BEIIEAFD

  But I was able to create a CTXCAT index on a partitioned table query to use it successfully.

  So can someone tell me exactly it meaning in the documentation of oracle developer "CTXCAT index does not support index and table partitioning?

  Thanks in advance,

  Mor.

  This simply means that you cannot create a LOCAL partitioned index on a table partitioned using the CTXCAT indextype. There is not probably the creation of a global index (ie. covering all partitions) on a partitioned table.

  The wording could be clearer.

• Order by in a partitioned table

  Hi all

  I recently list partitioned table. After the partition, the existing query result was completely different from that of a non-partitioned table.

  CREATE TABLE 'BALANCE_TMP '.

  ("BRANCHID" VARCHAR2 (10 CHAR) NOT NULL,)

  VARCHAR2 (1 CHAR) 'ACCOUNTTYPE' NOT NULL,

  VARCHAR2 (20 CHAR) 'ACCOUNTID' NOT NULL,

  "BUSINESSDATE" DATE NOT NULL,

  'BALANCETYPE' VARCHAR2 (1 CHAR) NOT NULL,

  ("BALANCE" NUMBER (18.3) NOT NULL)

  LIST PARTITION (BRANCHID)

  (

  PARTITION bal_100 VALUES ("100")

  PARTITION bal_101 VALUES ('101')

  PARTITION bal_102 VALUES ('102')

  );

  The query:

  SELECT * OF balance b WHERE ROWNUM < = 1 AND BranchID = '100' AND

  AccountType = 'N' AND AccountID = "100999999613USD" AND BusinessDate <= May 12, 2014 ' AND

  BalanceType = 'A' ORDER BY BusinessDate DESC

  "The account has dates of business March 12, 2003 '-may 12, 2014. The SQL above on partitioned table gives me the folder that has the date of the company March 12, 2013 "and when partitioned may 12, 2014".

  Please let me know what I'm missing here. I'm assuming that partitioning atleast, in this case, is transparent to the SQL code.

  1543042 wrote:

  The same SQL on a non-partitioned table gives me the results expected is the last album of businessdate. On the partitioned table version, it gives me a record earlier.

  I believe you. Most likely date column is indexed. Optimizer decides to use the SORTED INDEX RANGE SCAN and first rank is rank of more recent date. That's why you get the desired result. But it's only because you're lucky optimizer chose a plan where the last line is read first. It is a time bomb which had sooner or later go off.  And that's exactly what happened with the partitioned table. Optimizer realized account of the table is partitioned and probably the use parallel execution plan. Now you have several slave process every single partition handling and using the INDEX RANGE SCAN SORTED for that. So each slave will get the last row in a respective score but then master process will choose one of them when applying ROWNUM<= 1="" and="" here="" you="" are="" at="" the="" mercy="" of="" which="" row="" will="" it="" be.="" and,="" as="" you="" already="" know,="" you="" didn't="">

  SY.

• 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.

• A slower loading into partitioned table as the non partitioned table - why?

  Hello
  
  Using oracle 11.2.0.3.
  
  Have a large fact table and do some comparative tests on the loading of large amounts of data histroical (several hundred GB) in fact range partitioned to date table.
  
  Although I understand if use exhange partition loading may be faster to load a partitioned table, trying to figure out why a standard sql insert takes 3 x long to load a table partitioned compared to an identical table but not partitioned. Identical EVERYHING in terms of columsn and the sql that the insert and second partitioned sql execution to
  ensure caching with no impact.
  
  Local partitioned table a partitioned bitmap index as compared to the non-partitioned table that has standardnon-partioned bitmap indexes.
  
  Any ideas/thoughts?
  
  Thank you

  One would expect that the queries that cannot no partition pruning may be slowed down, Yes.

  An easy way to see this is to imagine that you have a partitioned local index b-tree and a query that needs to scan all partitions of the index to find a handful of lines that interest you (of course, this is not likely to be exactly what you see probably but we hope informative of the source of the problem). Let's say that each partition of the index has a height of 3, so for each partition, Oracle has read 3 blocks to reach the correct terminal node. So to analyze each of the N index partitions, you need block index 3 * N bed. If the index is not partitioned, perhaps the height of the index would go up to 4 or 5 If, in that case not partitioned, you must read 4 or 5 blocks. If you have hundreds or thousands of partitions, it can easily be hundreds of times more work to analyze all the index partitions individual he would to analyze one unpartitioned index.

  Partitioning is not a magical option "go faster". It is a compromise - you optimize certain operations (such as those that can partition pruning) at the expense of operations that do not partition size.

  Justin

• 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

• Select for a partitioned table, it will work with &gt; sign?

  Hello
  I partitioned table and select for that:

  ...
  PARTITION BY RANGE  ( "INDATE"  )
    (   PARTITION "PRT_20091201" VALUES LESS THAN (TO_DATE(' 2009-12-02 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN')...
  ....
     SELECT COLUMN_LIST FROM TABLE1   WHERE
             ( indate >= to_date(t_indate || t_timefrom, 'mm/dd/yyyy HH24:MI:SS'))                       AND
             ( indate <= to_date(t_indate || t_timeto,   'mm/dd/yyyy HH24:MI:SS'))                        AND... 

  so by selecting all of the Info for the given date specified inside time, and I use > = condition on the column partitioned, do you think that it will work correctly learn directly to the single partition or Oralce requires me to put strictly = sign for this column and then additioanly I can probably choose time, something like:
  

  SELECT COLUMN_LIST FROM TABLE1   WHERE
            ( indate = to_date(t_indate , 'mm/dd/yyyy'))                        AND
                 ( trim_to_time(indate) >= to_char(t_timefrom, ' HH24:MI:SS'))              AND
                 ( trim_to_time(indate) <= to_char( t_timeto,   ' HH24:MI:SS'))              AND... 

  All TX
  TR

  Trento wrote:
  Thanks to all the guys,
  Always learn to follow the plan. I can't use SELECT FROM TABLE of PARTITION (P - NAME) because of dynamic political anti on our site.

  Not a bad policy as dynamic sql is a blade against double edge that can cut you, and the problem with its employees.

  But do not use the option of PARTITION in a dynamic query - use manually in a one-time ad hoc when query data. Decide what partition to get the data is done automatically and is what is the process for

• Link to database to a partitioned table

  Hello
  
  I'm running 10g and have a link database to another database that has partitioned tables.
  Is it possible to query tables partitioned via a link?
  
  Mattias

  Hello

  You cannot query a particular partition via db link.
  Workaround: use where clause on partitioned column.

  Concerning
  Anurag

• Oracle Excessive Partition table

  People,
  We have a server Oracle 10 g. My question concerns an Oracle table that until now has 183 scores. Whoever created this table, put in place to add a new partition at the end of each month. I checked and verified in each partition, there are anywhere between 20 000 and 40 000 lines. Each line consists of 218 bytes. My manager is to get rid of these partitions. He just wants me to check that let down the barriers would not impact the response time that much. I can see Adding a partition of all ranks from 500 000 to 1 000 000, but having a partition for 20, 000 to 40 000 lines seems excessive to me. At the pace partitions are added to this table, in 5 years, it might have more than 600 scores. Finally, like anything else in life, there must be some back of draw for Oracle table partitioning. I saw a lot of 'Pros' on the Web but not 'jerks '.
  
  I would appreciate your opinion on it.
  
  Seyed

  I agree with your idea that the partitioning for 40K lines (with the information provided) seems excessive. Do the calculation lines 40 K * 218 partitions should be out only about 8 million, I would not immediately consider a candidate for partitioning.

  Partitioning of the benefits that you are aware of; most of them involves the use of large data sets. Pruning is a huge advantage by excluding the vast amounts of data that are unwanted review of the join.

  There are disadvantages too, for the most part buried under the volume of data partitions work usually with. There is a performance slightly beat on standard queries against a partitioned table while SQL decides which partitions to hit. You can observe this by querying the table, then by a specific partition trying only to get data for a specific partition.

  There is also the question of how many partitions you want to keep track of? You ask the right questions.

  Its possible that the partitions help performance; the only way to be sure is to create a table that is not partitioned using DEC, indexes, and constraints such as the partitioned table and run performance tests.