- Global Oracle Contractors Network Track

Many thanks firstly to Ahmed Jassat, author of “Cloning from 20hrs to 20mins using Oracle Dataguard” & also to Alexander Reichman, author of “Interacting with BPEL/Workflow from Oracle Forms 11g”.

Ahmed is an Oracle Apps DBA based in South Africa & his White Paper focuses on a client site where he has worked & how implementing Oracle Dataguard has reduced the cloning time dramatically for them & the impact this has had on the business. A must-read for any DBA/Technical Managers, DBAs, Apps DBAs & disaster recovery teams.

Alexander is a certified Oracle DBA based in Canada & his White Paper focuses on integrating Oracle Forms 11g with Oracle BPEL/Workflow included in the Fusion Middleware 11g platform. A must-read for any Oracle Forms Developers, SOA Architects & Project Managers.

When you log into a database server that has been running for several years, you will often find lots of files from databases that may not have been used for some time.

The people who created them probably left the company long ago and there is little documentation on the databases. Nobody is certain whether or not they are still being used, so they just sit around using up disk space. If the databases are started up, then they’re also using memory, even though they may not be doing anything productive.

Rather than prolonging this situation, it’s a good idea to remove these databases - once you’ve confirmed that no-one uses them anymore. Unfortunately, within a large business it may not be easy finding out who within the company is using which databases, if documentation has not been kept up to date.

As a starting point you can look in the following places:
(i) Database alert log
If the database is currently shut down, then what date was it shut down? If this was a long-time ago (i.e. more than 1 year), then the chances are that the database is no longer used, or is so out of date with current business data that it would need to be refreshed/updated before it could be of any use.

Note: Just because things such as configuration changes (i.e. extending datafiles) are shown in the alert log, it doesn’t mean to say that it’s actually in use. A DBA can carry out maintenance tasks on a database, whether or not there are any business users carrying out work.

Similarly, you may find that a backup tool such as RMAN regularly connects to the database. This also doesn’t mean to say that the database is being used by the business - just that it’s being backed up.

(ii) Listener log
Search in the listener log for the last entries for that database. Even if the database is shutdown, this will let you know the last time that anyone was using it. Be careful that you don’t think that someone is using the database just because there is an automated application process or reporting tool that connects to the database regularly. If individual users are not connecting to the database, then it may not be in use anymore.

Note: Double-check with any reports or application support teams as well, because the database may just be a repository, in which case individual user connections could be rare.

(iii) Datafile timestamps
If the database is shutdown, What is the last modified date shown in the filesystem for the datafiles? I’ve come across situations where you can’t find any entries for the SID in the listener log and the alert log for the database has been removed, so this is a good way to find out when the database was last open.

Note: This is assuming that someone hasn’t just copied the files from another location, without preserving the original file timestamps.
(iv) Run AWR/ASH or Statspack reports
These will let you know if anyone has been using the database within the last week or longer - depending on the retention period configured for the database. (If performance snapshots are not configured, then you may also find useful information on long-running transactions in V$SESSION_LONGOPS).

Note: Just because a database hasn’t been used in the last week, doesn’t mean to say it’s not required anymore. It could be used for monthly, weekly or annual reporting, so you may not see regular activity.
(v) Database Auditing
If database auditing has been enabled, it will give you an idea who has been accessing the database. (e.g. query views such as DBA_AUDIT_SESSION and DBA_AUDIT_TRAIL).
(vi) Standby databases
It’s worth running the query SELECT DATABASE_ROLE FROM V$DATABASE; If this returns “PHYSICAL STANDBY” or “LOGICAL STANDBY”, then it could mean that someone has deleted a primary database in the past, but neglected to remove the associated standby database.

Before deleting any databases, it would be advisable to email anyone that may have an interest in the database and then ensure that a copy of the database files and configuration information is archived to tape or other storage for a pre-defined period of time. Ensure that you have approval from all interested parties before carrying out any work like this, which could have an impact on the business.

If you would like a copy of any of these papers, please register with the White Paper area of our website where you can gain access to our full White Paper library & if you are interested in becoming a White Paper author yourself, please contact me at: kirsten.campbell@oraclecontractors.com

New papers are also being released in September too so watch this space!

Over the years, the topic of whether or not to take the Oracle Certified Professional (OCP) exams has been discussed many times. A large number of clients and agencies now regularly ask for candidates who are OCP qualified.

The main arguments against the exams seem to be along the following lines:

The exams only deal with theoretical situations. You can’t beat real-life experience. This is true, but the exams do demonstrate that you are able to understand technical issues. In order to resolve problems, you need to know how the software works. You also need real-life experience of using your theoretical knowledge in a practical manner, before you can become an effective DBA.

Outside of a test laboratory or classroom, you have real users, applications and software from multiple vendors. Once exposed to these environments you become a much better DBA.

The exam is just a memory test.That’s true to some extent - but you have to understand the question and which of the possible answers is the correct one. You still have to understand what you’ve remembered. Even though you may forget the exam topics over time, at least you have positive proof that at the time you took the exam, you knew that area of Oracle in detail.

I don’t need to take the exams to show that I keep up to date.Whilst you can just read the documentation, at least the exams prove that you’ve made the effort to keep your skills current. Otherwise everyone else just has your word for it that you have.

The other issue is that you can read the documentation but not understand it properly. Passing the exam is proof that you understood the concepts in sufficient depth to pass the exam.

Taking the exams also provides a more focused way of keeping up to date.

Why bother learning about lots of features that you’re never going to use?There are lots of features that you may never use, but if a new problem arises - if you’ve kept up to date - then you’re are aware of all the possible solutions. You don’t always have several days or hours to go away and research all the available options. Even having a high-level overview of a solution can mean that you not only resolve issues more quickly, but that you’re more likely to come up with the most effective solution. If you aren’t aware of other solutions then you never will use them. You’ll just end up doing things the same way that they’ve been done for years.

Another reason for learning about many features is that unless you can predict the future, how do you know what features you will never use?

Knowledge of lots of functionality is useful when resolving issues because more options that were once separate from the main database installation are now integrated into it. Sometimes these options can cause errors even though your application isn’t actually using them.

The exams also demonstrate that you’re interested enough in the technology to want to keep up to date. Nobody forces you to take them.

Whether or not you decide to take the exams is a personal choice, but I would say that they can be useful as a starting point to differentiate between two DBA’s who have a similar level of experience. There is still no substitute for real-world experience and just because someone passes the exam doesn’t necessarily mean that they’ll be a better DBA.

Various applications can be configured to connect to an Oracle database using an ODBC connection. When there are problems with the connection, it can sometimes be useful to enable ODBC tracing.

This is a pretty straightforward task and can often highlight useful information to diagnose issues such as incorrect ODBC drivers or driver versions, or attempting to use incorrect database connection information.

The Scenario
————-
To demonstrate ODBC tracing, we’ll first log into an Oracle 11.2.0.1.0 Enterprise edition database called “ORCL11″ and create an account called “odbc1″:

create user odbc1 identified by odbc1;

(Note: You may want to make your password more secure than this! Remember also that 11g has case-sensitive passwords by default)

Then we create an ODBC connection to our ORCL11 database. Create the connection using a System DSN called “EXCEL_TEST11″. Use the Oracle ODBC Driver 11.2.00.01 and the odbc1 database account to connect.

The last step is to create a new Excel 2010 spreadsheet called “odbctesting.xlsx”

Note: To keep this post brief, I haven’t included full details of the steps to create the ODBC connection, or of setting up the connection in Excel. If anyone wants detailed instructions on how to do this, please let me know. For the Excel connection the main steps are to go to the Data tab - “From Other Sources” - “From Data Connection Wizard” - “ODBC DSN” - Next and then select the “EXCEL_TEST11″ ODBC connection. (Even though you’ll see a large listing of database objects, the ODBC1.ODBC_TEST_TAB is in the list - near the end. All the other objects are database views and tables to which PUBLIC - i.e. all users - have been granted access). Don’t select the option to save the password to the file.

Turning on tracing
——————
Next we’ll turn on ODBC tracing, so that we can see what’s happening when the connection is being made. From a Windows XP client, as you need to do is:

Once you’ve clicked on the “Start Tracing Now” button, you’ll notice it will change to be a “Stop Tracing Now” button - Apply - OK. This closes the ODBC Data Source Administrator.
Notes:
(i) To change the location of the logfile, click on the “Browse” button on the Tracing tab. You can also change the name of the log file. Then click Save.
(ii) Be aware, that this will turn on tracing for ALL ODBC connections running on this client.
(iii) Tracing could have a serious performance impact on your application, so only enable it if neccessary.
(iv) Microsoft support article ID: 942976 notes that 64-bit versions of windows have two versions of the ODBC Administrator tool:

%systemdrive%\Windows\SysWoW64 folder. - 32-bit version of Odbcad32.exe%systemdrive%\windows\System32 folder. - 64-bit version - also called Odbc32.exe

If running odbcad32 to edit 32-bit DSN’s, then specify the full path to the executable. 32-bit System DSN’s will only appear in the 32-bit version of odbc32.exe and 64-bit System DSN’s will only appear in the 64-bit version of odbc32.exe. However, be aware that User DSN’s will appear in both versions. Please refer to the Microsoft support note for more details.

Viewing a successful connection
——————————-
To see a successful connection, we can open our spreadsheet and select the “Refresh All” option on the Data tab.
The ODBC tracing logfile contains a large amount of information. An extract is shown below. (I’ve added comments pre-fixed by “#”, but you obviously won’t see these in the logfile).

Note: You might think, why bother tracing ODBC if you get the error messages in Excel anyway? That’s fine, but the main purpose of this post is to illustrate that if you are using an application which doesn’t supply detailed messages, you may be able to find out the cause of any issues by turning on ODBC tracing.

Turning off ODBC Tracing
————————
To stop tracing, you can then just open up the ODBC Data Source Administrator as before - go to the “Tracing” tab and click on the “Stop Tracing Now” button - Apply - OK.
Note: Don’t leave tracing turned on permanently, otherwise it could fill up the local drive on the client. ODBC tracing can generate a lot of information. Remember to delete or archive old trace files.