Accessing large partitioned tables over a database link - any gotchas?

Question

Hi,
We are in the middle of a corporate acquisition and I have a question about using database links to efficiently access large tables. There are two geographically distinct database instances, both on Oracle 10.2.0.5 sitting on Linux boxes.
The primary instance (PSHR) contains a PeopleSoft HR and Payroll system and sits in our data centre.
The secondary instance (HGPAY) runs a home grown payroll application and sits in a different data centre to PSHR.
The requirement is to allow PeopleSoft (PSHR) to display targeted (one employee at a time) payroll data from the secondary instance.
For example in HGPAY
CREATE TABLE MY_PAY_DATA AS
SELECT TO_CHAR(A.RN, '00000000') "EMP" -- This is an 8 digit leading 0 unique identifier
, '20110' || to_char(B.RN) "PAY_PRD" -- This is a format of fiscal year plus fortnight in year (01-27)
, C.SOME_KEY -- This is the pay element being considered - effectively random
, 'XXXXXXXXXXXXXXXXX' "FILLER1"
, 'XXXXXXXXXXXXXXXXX' "FILLER2"
, 'XXXXXXXXXXXXXXXXX' "FILLER3"
FROM ( SELECT ROWNUM "RN" FROM DUAL CONNECT BY LEVEL <= 300) A
, (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 BY PAY_PRD, EMP
HGPAY.MY_PAY_DATA is Range Partitioned on EMP (approx 300 employees per partition) and List Sub-Partitioned on PAY_PRD (3 pay periods per sub-partition). I have limited the create statement above to represent one sub-paritition of data.
On average each employee generates 300 rows in this table each pay period. The table has approx 180 million rows and growing every fortnight.
In PSHR
CREATE VIEW PS_HG_PAY_DATA (EMP, PAY_PRD, SOME_KEY, FILLER1, FILLER2, FILLER3)
AS SELECT EMP, PAY_PRD, SOME_KEY, FILLER1, FILLER2, FILLER3 FROM MY_PAY_DATA@HGPAY
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 the data centres where PSHR and HGPAY sit is not the best in the world, but I am expecting tens of access requests per day rather than thousands, so I believe the link should have sufficient bandwidth to meet the requirements.
I have tried a quick test on two production sized test instances and it works in that it presents the data, when I look at the explain plan I can see that the remote database is only presenting the relevant sub-partition over to PSHR rather than the whole table. Before I pat myself on the back with a "job well done" - is there a gotcha that I am missing in using dblink to access partitioned big tables?

Answer 1

Yes, that's about right. A lot of this depends on exactly what happens in various "oops" scenarios-- are you, for example, just burning some extra CPU until someone comes to the DBA and says "my query is slow" or does saturating the network have some knock-on effect on critical apps or random long-running queries prevent some partition maintenance operations.
In my mind, the simplest possible solution (assuming you are using a fixed username in the database link) would be to create a profile on HGPAY for the user that is defined for the database link that set a LOGICAL_READS_PER_CALL value that was large enough to handle any "reasonable" request and low enough to quickly kill any session that tried to do something "stupid". Obviously, you'd need to define "stupid" in your environment particularly where the scope of a "simple reconciliation report" is undefined. If there are no political issues and you can adjust the profile values over time as you encounter new reports that slowly increase what is deemed "reasonable" this is likely the simplest approach. If you've got to put in a change request to change the setting that has to be reviewed by the change control board at its next quarterly meeting with the outsourced DBA vendor, on the other hand, you could turn a 30 minute report into 30 hours of work spread over 30 days. In the ideal world, though, that's where I'd start.
Getting more complex, you can use Resource Manager to kill queries that run too long on the wall clock. Since the network is almost certainly going to be the bottleneck, it's probably unlikely that the CPU throttling is going to do much good-- you can probably saturate the network with a very small amount of CPU. Network throttling in my mind is an extra step up in complexity again depending on the specifics of your particular situation and what you're competing with.
Justin