Distributed partitioning

Question

Hi!
First of all thank you for the time you grant me... and sorry for my english too!
I currently work for my university on databases distribution and partitioning concepts.
I installed two oracle instances on two servers. Each instance contains one database (lets call them db_1 and db_2).
These two databases are linked to each other with oracle database links.
Each instance contains tables, and I managed to make queries on remote tables... everything seems fine on that side.
My goal then was to do table partitioning.
For example, a customer table in db_1:
- when client name is between A and F: customer.partition_1
- when client name is between G and Z: customer.partition_2
Everything seems fine on that side too :)
I suppose that, with partitioning metadatas, Oracle is able to optimize queries to consult only the partitions that might contain the data.
For example, in a " select from customer where name like 'A%'; " query, partition_2 should remain quietly at rest.
Now my question is: is it possible that customer.part_1 stay on db_1 but part_2 goes on db_2 ?
That is, make a mixture between distribution and partitioning.
db_1 will have a customer table, but the 2 partitions containing the data will be distributed.
The ultimate goal is to have a customer table on both databases, but with distributed partitions.
In this case, access to the remote partition will be made only when necessary.
I know it seems completely useless, but it's for my graduation project, and faculties projects are not intended to be useful, but interesting!
Having said that, from this idea, we can imagine distributed systems powerful enough...
If it's possible, I haven’t found this information in the oracle doc. Or I missed something...
Thanks in advance for any answer, if you need a fuller explanation, do not hesitate to ask!
Pedro

Answer 1

Oracle's partitioning option would not allow you to have one partition of the CUSTOMER table in database A and a second partition in database B (that technique is generally referred to as "sharding"). Oracle provides features like RAC, Active DataGuard, and various replication technologies in order to allow you to build distributed systems in the real world.
Since this is an academic exercise, however, you could build something like what you're describing using the (*very old-school*) techniques that were used prior to partitioning being available. In Oracle 7, for example, you could implement a form of poor-man's partitioning where you create, say, 26 different physical tables, your code inserts the row into the appropriate table (i.e. customers with a last_name of 'Cave' would go in the CUSTOMER_C table), and a view does the UNION ALL to combine all the tables.
CREATE TABLE customer_a (
  customer_id NUMBER PRIMARY KEY,
  first_name VARCHAR2(30),
  last_name VARCHAR2(30)
CREATE TABLE customer_b (
  customer_id NUMBER PRIMARY KEY,
  first_name VARCHAR2(30),
  last_name VARCHAR2(30)
CREATE VIEW customer
AS
SELECT *
  FROM customer_a
WHERE last_name LIKE 'A%'
UNION ALL
SELECT *
  FROM customer_b
WHERE last_name LIKE 'B%'
UNION ALL
SELECT *
  FROM customer_z
WHERE last_name LIKE 'Z%'Assuming you have a query like
SELECT *
  FROM customer
WHERE last_name = 'Cave'the optimizer should be able to identify that only the CUSTOMER_C table would need to be scanned and ignore the other 25 tables in the query. In this setup, CUSTOMER_A could be in one database and CUSTOMER_Z could be in another. This setup, though, is hugely more fragile than partitioning-- it's not something that people today would design. Getting all the setup exactly right so that the optimizer knows which tables it can ignore can be rather non-trivial (I doubt that this particular example would work without tweaking) and is a bit of a lost art. I'm sure there are papers from the mid-90's when this was a more common workaround to the lack of a partitioning option that discuss this technique in more detail. And I'm sure some of those papers could use a bit of updating given the huge changes that have been made to the optimizer over the years.
Justin