thekua.com@rest

Don’t get me wrong. I like the concept of OpenOffice, but just like many other open source projects (not all of them mind you), someone could teach these people about actually meeting user’s needs (and not some idealistic view of simply creating an “open standard”).

Today I had to open a SXW file (an OpenOffice Text Document) on a windows box today and found that nothing currently installed could open it. I didn’t really care too much for the formatting, but I desperately needed the content and opening it up in a notepad-like utility proved fruitless. I was thus forced to download the only “open” office that I could actually view this with (at least that I know of, I could be wrong).

Much to my dismay (not to mention distaste) I was forced to download a whopping 64MB file just to be able to view a 20KB file. I was lucky that I had access to broadband as it would have been super painful over dial-up (oh, yes people still use this!). As a user whose goal was to simply view the raw text in a document, I would have liked to either:

• Open up the document, ignore what special markup the formatting was in and be able to extract the raw data; or
• Be able to download the only application that I needed to view the file with.

Since we finished with our migration to the Oracle 10g database, I have been meaning to post some useful notes about developing in this new environment. This last two weeks, I have found myself using Oracle’s V$ views a fair amount so I thought it might be good to share (or at least archive this information for myself).

What are V$ views?
V$ views are defined by Oracle as dynamic performance related views because they are continually updated to reflect the database state as it is running, and most of the information is pertinent to performance tuning and useful for performance monitoring. You can find more information about V$ views quite easily, both through the Oracle Technology Network or the great AskTom website.

Why should I bother to use V$ views?
Many GUI interfaces are widely available to help administer and monitor Oracle databases and sometimes you may never have a need to use these views. However sometimes those tools are beyond the reach of your normal developer and interfacing with Oracle at this lower level can be the simplest solution for what you need. A database configuration where people who can execute any arbitrary SQL statement should also generally grant them with the access to read from these very informative views.

What are some useful examples for making the most of these views?
Easily monitor through the number of connections with:

SELECT SID, SERIAL#, PADDR, USERNAME, STATUS, MACHINE
FROM V$SESSION

Monitoring the total number of connections as your application is running may give you a good example of how well your application is properly managing its connections. Those connections that sit there in an INACTIVE state are probably ideal candidates for further investigation. If you have the DBA role, you can then kill sessions (with care) with:

alter system kill session 'sid,serial#';

Uncover the SQL statements that are currently running with:

SELECT text.SQL_TEXT
FROM V$SESSION session, V$SQLAREA text
WHERE session.sql_id = text.sql_id

Another view exposes settings for National Language Support (NLS) parameters. We once had issues with database instance managements that resulted in us creating a set of environmental acceptance tests as a cheap way of detecting differences in database configurations. These were useful for ensuring settings such as the NLS_DATE_FORMAT were configured correctly for standard JDBC.

SELECT *
FROM V$NLS_PARAMETERS

I have been part of a production support team lately and an issue that was raised this week had me concerned about some of the state we seemed to be operating in. We had a situation where a business analyst who wrote the requirements for a particular part of the system had to keep coming back to development asking how that was part of the system was supposed to be working.

I must apologise, but I thought our current process was actually working to ensure that the development loop was tight. Testers would work with BAs to ensure that all the scenarios were covered, developers would write to meet those scenarios and the BA would walkthrough the application to ensure that all of their requirements were met before signoff (completion of the storycards). It could have just been an off-day, but it worries me when business people come to the development team to see what the business rules should be.

Recently we were trying to upgrade to the latest release of Java 5 (the J2SE05_04 version to be exact) so we could make use of the various bug fixes in the VM, and just to stay on the bleeding edge. After running our entire test suite (I could not imagine life without it!), we found that the URLConnection.connect() had a regression, throwing errors when you have a URL containing foreign characters such as éâäàåçêëÇèïîÄèïîÄ (basically anything after %8x through to %FF). Kudos has to be given to Ajit George who did all of the investigation work but does not have a blog to post this on.

For example:

URL foreignURL = new URL("http://java.sun.com/%80/");
URLConnection connection = foreignURL.openConnection();
connection.connect(); // IllegalArgumentException thrown here

We were lucky enough that only our test code exercised this API, but be warned if your application makes use of this and you upgrade to the latest version. A bug report for this can be found here. According to sun, the underlying class that is apparently the problem, sun.net.www.ParseUtil, has had this issue since the latest JDK1.4 version, but this regression appears when you use the URLConnection.connect() only in J2SE05_03 and the current release J2SE05_04 but works fine for J2SE05_02.