Hi we had big Oracle column object and we had partitioned it with a Data Type of DATE
One of the partitions looks like this :
GCP_P1 TO_DATE(' 2011-01-01 00:00:00', 'SYYYY-MM-DD HH24:MI:SS', 'NLS_CALENDAR=GREGORIAN') 83 M_DATA01 DISABLED 348132 15214 146 08.06.2014 02:20:40 1078 0
Each partition is one week long.
We run our sql's through thin client with jdbc. No ORM just pure jdbc.
When our predicate item for the partitioned column is java.sql.timestamp we realized that the query does not benefit from partition. However when it is of type java.sql.date the execution plan shows a successful partition access.
So for example our sql looks like this :
SELECT COUNT(1) FROM ATABLE WHERE PARTITIONED_COLUMN > ?
When our java statement is :
preparedStatement.setDate(...); // it benefits from partition
But when it is like this :
preparedStatement.setTimestamp(...); //it does not benefits from partition
I am looking them from Toad. I have experienced that when it is java.sql.date, It is interpreted as DATE on oracle, when it is java.sql.timestamp it is interpreted as TIMESTAMP
I am following the captured jdbc date type with the following sql statement
SELECT *
FROM V$SQL_BIND_CAPTURE
WHERE WAS_CAPTURED = 'YES' AND LAST_CAPTURED BETWEEN SYSDATE-1/50 AND SYSDATE
ORDER BY LAST_CAPTURED DESC;
My question is have you experienced such an issue? If so would you direct me to some documents.
The case you describe is documented section 8 - Mapping SQL and Java Types of "Getting Started with the JDBC API"
8.3.12 DATE, TIME, and TIMESTAMP
Because the standard Java class java.util.Date does not match any of these three JDBC date/time types exactly (it includes both DATE and TIME information but has no nanoseconds), JDBC defines three subclasses of java.util.Date to correspond to the SQL types. They are:
java.sql.Date
for SQL DATE information. The hour, minute, second, and millisecond fields of the java.util.Date base class should be set to zero. If the number of milliseconds supplied to the java.sql.Date constructor is negative, the driver will compute the date as the number of milliseconds before January 1, 1970. Otherwise, the date is computed as the specified number of milliseconds after January 1, 1970.
java.sql.Time
for SQL TIME information. The year, month, and day fields of the java.util.Date base class are set to 1970, January, and 1. This is the "zero" date in the Java epoch.
java.sql.Timestamp
for SQL TIMESTAMP information. This class extends java.util.Date by adding a nanoseconds field.