We are looking for a person/company that provides oncall Oracle support. Need pretty advanced skills. We are having some issues with our Oracle backended ERP and our DBA is struggling to solve it. Just looking for a name/number.

Have you tried creating a SR with Oracle? Thats a good way to go in the meantime while you look to get a consultant in. Whats the problem in particular? Is it E-business suite or an issue with the actual DB?

80k+
End of story

whats 80k+, the product or the support?

that provides oncall Oracle support. Need pretty advanced skills

Anyone who can support an Oracle DB remotely isn't going to be cheap, especially if they have "advanced" skills

Oh, and I am speaking from past history

last edited by HERMITech at 22:29:12 16/Jul/07

It appears to be a problem in the database. We have been banging heads against a wall trying to get sense out of Oracle. Unfortunately they have moved nearly all their support to Asia/Sub Continent. Their entire problem resolution revolves around applying patches which doesn't help our problem, hence looking for a local consultant. I know it isn't going to be cheap, hence I never mentioned that price was an issue.

If oracle have identified the problem as being addressed in a later patch, its unlikely the person you get in will have a better solution. That being said, oracle support are known for suggesting patches as a first resort, before really fully investigating the issue. Is your problem listed in the patch release notes?

You're pretty light on details here...maybe you could post the contents of the SR so that people can get a better idea of the problem. What DB release? What ERP? Symptoms? Any changes to the ERP/proceess/business logic prior to this occurring?

Any vendor I've dealt with will insist you are fully patched up on all hardware/software they provide, and I reckon it stands to reason, since they know they are often fixing bugs and the issue might well be fixed in a patch or at least exacerbated to some degree by not having a patch. It seems perfectly reasonable to me for them to make that requirement before 'really fully investigating the issue'.

Is it fair to ask the DBA to bring down the company's operations, to patch a DB which is supporting the company's mission critical ERP system if the problem hasn't even been noted as being addressed by that patch?

What may be perfectly reasonable to SME's, may not be reasonable to a company sizable enough to justify the purchase of an ERP system.

Provided the OP is running a supported release, there is no reason to patch without good cause as Oracle's policy is to support the full release.

Anyhow, going by the scarce details that has been given, I have a hunch that the problem is more likely with application logic than with the DB. My experience with the oracle db's is that they are rock solid...and if you do have a problem inherent to the database...you can be sure its already been addressed or it is a 'feature'.

problem hasn't even been noted as being addressed by that patch

In my previous job working for a large IT vendor it became common knowledge that patch notes that were distributed publicly with patches were far from complete.

This is done for numerous reasons and as such you shouldn't write off applying patches because the patch notes don't list a fix for a problem you are having.

What may be perfectly reasonable to SME's, may not be reasonable to a company sizable enough to justify the purchase of an ERP system.

A 'company sizable enough to justify the purchase of an ERP system' shouldn't be in a position where they can't down an instance of oracle to apply patches

The issue we have has resulted from running some backend scripts on our database, we suspect that it has caused a corruption in the data possibly due to a deadlock on records, oracle solved the deadlock (as its supposed to) but it seems to of mashed some data, we are unable to locate this error in a search of our data.

We have a couple of sandpit databases running and patching of these has not corrected the problem.

Yes you are right we cannot take down a production database to run patches. If it were to correct the problem then we would schedule it, however its not a fix.

We are running Oracle 9i release 9.0.7.0. Our ERP is called Visual Manufacturing, it runs everything from our sales to factory to accounts.

We are in the process of sourcing some assistance from the states.

Thanks for the replies, I'll update if we get a resolution.

A 'company sizable enough to justify the purchase of an ERP system' shouldn't be in a position where they can't down an instance of oracle to apply patches

Yeah exactly you can customize and test in different instances while keeping the ERP running and see if it solves the problem, if it doesn't who cares at least your DBA isn't totally useless.

Sorry to hear your situation, sounds like you're in a bind. I would suggest that your problem is beyond the abilities of oracle support (or even a DBA for that matter) as it has really gone beyond the boundaries of being a datbase problem. What you really need is support from Visual Manufacturing, who should have enough application knowledge to diagnose where the data inconsistency lies...which is affecting the application logic.

Can I just say...why the hell is oracle support suggesting a patch to fix data inconsistency? After something like that...especially on an ERP system which is probably still operational and accepting new transactions...unless had you shut down the system at the first sign of issues, could roll back to a backup taken just before the script was run, and hoped like hell that a patch changed the way Oracle deals with deadlocks (HAHA, impossible) and re-ran the script... what could it possibly achieve. This just highlights my comments earlier. But hey, I guess you need to have actually dealt with oracle support before to know what i was talking about.

While waiting for the US, I would be looking more closely at the script that was run to narrow down the tables you are comparing. If you have flashback enabled, do some outer joins on them to narrow down your search even more. Also, use the most recent snapshot you have prior to the script on your sandpit...turn on trace and run the script. This way you have a better idea of what was executed/deadlocked/rolled back. Good luck!