Stephen's Oracle Blog

We're looking at implementing Dataguard as part of an implementation of Documentum (a document management system from EMC) and I have been asked to look at producing documentation and scripts for non-DBA users to use during a failover. The actual failover of the database itself will be handled by our DBAs, this is for the sys admins, network admins, application admins &c who may need to do things during fail over. I'm currently going through the Dataguard concepts guide and have found some other documentation on OTN but was hoping that someone with more knowledge of Dataguard could point me towards any documentation that might help with the non-Oracle side of failover. If anyone has any documentation/scripts like this they have prepared themselves that they are prepared to share and I could adapt to our environment then I'd be very grateful. Here is the background: We have a pair of IBM p590 servers, running AIX 5, currently sitting in different parts of the same dat...

This just came up on the mailing list for my local Linux Users Group following last night's meeting (which I didn't attend), the original mail and my response is below: > In the pub, there was an interesting conversation going on regarding > validation of data in databases. > > Excuse the omissions, as I said, it was overheard > > Someone brought up the point that in databaseX If say, you have a > varchar field set to a limit of 10, and put 26 chars of data into it > databaseX silently truncates it. > > So my question is, in your opinion, should it be up to the front end or > the database to do this kind of data validation? > I'm a Database Administrator, mostly working with Oracle. The reverse of this problem (data validated in the client but not in the database) is something I come accross a lot. Most RDBMS/ODBMS/ORDBMS, certainly any that can claim to be enterprise class, will have functionality to implement data validation (key con...

This entry is partly an aide memoire for me, partly to try to get something that has been keeping me awake for the past hour or so out of my brain so I can sleep and partly in the hope that someone can suggest a way forward. A quick bit of background. Until April 06 most of our major systems were looked after by an external Faccilities Management company. In April 06 IT was kind of outsourced to a joint venture company, support of the systems transferred to that company and a couple of the DBAs transferred in as well under TUPE. A reccurring problem on one of the systems is that the users keep deleting records which, by law, they must not delete so we (actually one of the DBAs who transferred in who is responsible for that system) has to restore from backup to another machine and copy the deleted records over (she's tried using LogMiner but finds it too unwieldy). The core problem is that the application is faulty and lets the users delete the records when it shouldn't. The...

We have a situation where we need to rationalise the range of installed Oracle clients (i.e. the bit that sits between the app and the network stack) we have installed. We currently have versions from 7.x through to 10.2 installed accross approximately 12,000 desktops (accross various locations in an area of around 26 square miles) running various apps on Windows versions from NT4 to XP (mostly Windows 2000). We are also introducing a standard TNSNAMES.ORA file (this is the impetus to standardise on a single client version as different locations on disk and formats of the TNSNAMES.ORA file would make it pretty much impossible to manage the rollout of the file otherwise). With the number of desktops to be updated and the area they are spread over it would not be possible to do this by visiting every desktop so management are proposing automated installation of the Oracle client through scripts run at logon requiring no user interaction. Has anyone ever tried something like this? Are...