Friday, April 29, 2005

Freedom!

Yipee! Last day of work before a two-month hiatus but unfortunately I probably have to complete some stuff over the weekend. You see, our current data warehouse was set up in Oracle 8.1.6 and we are in the progress of upgrading to 9.2.0.6. The user privileges and roles are a mess in the current version with most accounts being granted direct privileges (both system and object) which is a nightmare to maintain. I now have to review the current setup and propose a role-based setup to allow us to better manage accessibility and security in the new 9ir2 setup. A quick analysis done already tell me that not only the current setup was a mess but also most of the accounts have more sys privileges than necessary.

On a separate note, in Oracle-land, I follow the feeds of various Oracle blogs at www.orablogs.com as the site provides a quick overview of what's new on some of the more popular Oracle blogs. If you have not follow the spat between Burleson Consulting and the various others experts (Kyte, Lewis, Rogers, etc), then you probably wouldn't follow what I am able to post.

Don Burleson decided, after not being able to b.s. his way out of the deep hole that he dug himself, set up a series of Code of Conduct for his consultants, including banning them from participating in any forums which allows anonymous postings, not releasing sample data (even though the data could be 'sanitized') to back up any assertment of technical solution, dress code, etc. My assessment is that Burleson could have gotten himself out of the mess in the beginning if he has basically accepted the fact that his articles have incorrect information and to correct and republish giving credit to those who pointed out those mistakes but instead he turned around and accuse those of trying to help as "trouble-makers" and attempted to get them blacklisted. All we have to do is take a look at one of his recent articles and I'm sure you can find at least one glaring error or even look at his DBA Forum and you can see some of the errors. E.g. one poster asked about separating date and time into two fields and Burleson replied with SQL code that errored and his excuse was that he was in a hotel and has no access to an Oracle database instance to test his 'suggested SQL statements'.

It's too bad that he is still able to present at various Oracle conferences. I wish that the technical committee would actually review the materials and request that the presenters correct any non-factual information so as to avoid mis-information after all the attendees paid good money to get good information and advice.

Wednesday, April 27, 2005

Dress code and Oracle Net Services

Apparently my employee wasn't too happy with my voice message regarding his dress code at work. He spoke to my manager saying that he felt that he was being singled out and demanded to see the company policy on dress code. Hey, I am casual guy but shorts to work is probably not the best choice and neither is open-toe sandals (someone did that).

Our Data Warehouse group encountered a strange problem today. They were trying to access one of our databases via Cognos BI tools on a web browser which goes through a web server (IIS on W2K) and then onto the appl server (running W2003) which then goes directly to the db server. That's the idea but it was no go for a couple of our databases on W2K servers returning a TNS-12640 error. Accessing databases on our Unix servers were okay. This got us scratching our heads as to what's wrong with the databases on the W2K servers. Well, Oracle Net Services is installed on the appl server and logging in directly to that server and using SQL*Plus or TOAD to access the W2K databases went without a hitch. So, the databases are okay and verified by access from other parts of the network. A similar setup but with the appl server on W2K works great without any errors. This seems to indicate that it might be a W2003 compatibility issue and that will be a focus tomorrow as we try to pinpoint the actual problem.

Tuesday, April 26, 2005

New interesting site

Came across this website & service today from a referral e-mail from one of my work contacts. LinkedIn promote the sixth degree of separation concept by allowing you to manage your contacts as a network. You can invite your contacts to join and they in turn invite their contacts and so on and so on. Pretty soon, you are connected to others via a few degrees of separation.

Check it out at https://www.linkedin.com/

One of my employees showed up for work today again in shorts and the same top. Now the weather has been nice, sunny and warm but still showing up in the same outfit twice in a row is a little much especially if you tend to sweat. Anyhow, our GM noticed the attire and had a chat with my CIO who in turn spoke to my manager and guess who was next on the totem pole. Yep, I get to tell the guy that he should dress professionally but unfortunately the fellow had left for the day and I had to phone him at home. Instead I got his voice box even though I waited an hour before phoning.

Sunday, April 24, 2005

Weekend

Friday came and went with the only issue that I have at work being a non-technical (people management) one. One of my employees decided to take the afternoon off and didn't notify me until 15mins before he took off and even then I was at lunch! The good thing was I had mentioned the need to be on-call during the weekend for our PeopleSoft upgrade when I had coffee with him otherwise he wouldn't have known to be on-call. The problem was that this wasn't the first time that he has done that without or with very short notification. I left him a note that he should at least provide 24 hours notification so that I can plan around his absence.

Otherwise, the weekend was very good and with the warm and sunny weather and quality family time, it couldn't have been better.

Hopefully, the new week will be good and allow me to get some critical stuff done before I am off for a two-month parental leave.

Thursday, April 21, 2005

Another day

Another beautiful, warm and sunny day in Vancouver. Days like this is when you feel like you should be playing hooky from work/school. Unfortunately real life demands that you be responsible and do the right thing.

Got in and started prioritizing the day's work including delegating meetings/tasks to my team. Started looking at the SQL*Net issue described in my previous post. It seems that the tnsping was unable to open a socket connection. Went over to the security group and look through their firewall log and no sign of any packets hitting the firewall from the virtual server in question. Really, really strange. Did a couple more tests, this time using the IP address of the host machine and same results. The Security Officer told me that they added a new rule to the firewall but did not think that it would impact access to the database. After some detailed checking, the Security Officer realized that he had been working on a firewall rule that wasn't complete but was applied when he added the new rule. Undoing this half-completed rule seems to solve the issue. We were able to tnsping, connect to the database (and other databases) with nary an error message. Phew! Goes to show you that when things stop working because there has been a change, it's time to take a closer look at that change. In fact, the change should not have been applied without prior testing. Huh, a great lesson here.

I've also been getting calls from the Oracle account representative (more like team as they seems to have a number of folks involved). It's driving me nuts as each of them asked the same questions and wanted an overview of our Oracle environment and how we are using the technologies and what we are planning for the future. It's just incredible!! I had two folks out of Toronto, two from the local office and another two from the US (mind you, these two were following up regarding Oracle OpenWorld). That's just the database and application server guys. Wait 'till we get Oracle Appls into the organization! I will have Oracle sales coming out of the yin-yang!!

Anyhow, a couple of things on my list includes implementing Oracle Enterprise Manager utilizing OMS as well planning to migrate our Oracle Names to OID. Hopefully, the OEM implementation will be straightforward although with the various versions that we currently have, we will probably ended up with two versions of OEM (one to deal with 9i and 8i and the other to deal with v7). When I am ready, I will post the details on here.

Wednesday, April 20, 2005

Intro

Hey there,
After years of working in IT, I've decided to take the plunge and dive right into blogging. I don't really know what I will be noting down and also how often as things changes and time is definitely at a premium right now.

I have used Oracle since version 3 back in 1985 but have gotten away from Oracle over the years into Data Management and Data Architecture. I have always tried to keep my hands on Oracle as it progresses from version 5 to 10g now. The RDBMS is a lot more complex and full of features that help make the life of a DBA easier and manageable. My current employer has multiple versions of Oracle from 7.3.4 to 9.2.0.5 and had wanted to move to 10g (r1) but I have managed to convince them to stick to 9.2r2 until we migrate off 7.3.4 and 8.1.7. This, I believe, will give us a stable foundation to plan and move to 10g (by then r2 will be available and tested in the real world).

I have also tried catching up on the going-ons in Oracle-land and found myself fancinated by the war of the "experts" (various postings on c.d.o.s and other forums) and I got to admit that one group of 'experts' are not making their case nor are they looking good in this on-going feud. I have my own opinion on who I think is right and why one of the key participant should take his lumps and admit that he has been incorrect about a number of Oracle technologies and move on from there. Right now, looking at it, I would say that I would be insane to even recommend this particular individual and his organization to my Executives paying outrageous consulting fees for bad advice.

There have been so many technical books on Oracle over the years and I can tell you that just because someone published a book does not make him/her an expert. I have learned over the years that you don't just take things for granted or just because an "expert" say so. You read, understand, and if it seems iffy, try to verify. A lot of time we don't get the luxury of chasing down a problem but rather we are pressed to get things up and running as quickly as possible. That's still doesn't mean that we shouldn't try to get to the bottom of things. In most IT shops, the DBAs will have a test box that they can use to trouble-shoot and test out fixes, identify issues, test new patches, etc. This is part and parcel of the responsibilities of a DBA. Too often I have seen too many "DBAs" with no experience but has their certification and no idea to think and figure out things for themselves. All they have to go on is what they read or have been told. One DBA that I know told me that it would take him two weeks to install and create a new Oracle database! Folks! You have to enjoy what you are doing as a DBA otherwise you will never make it. Part of the fun is taking apart Oracle and seeing how it works, trouble-shooting and resolving issues AND making life easier for you so that you do have the time to research, test and verify!

Well, it's mid week (Apr 20th) and I spent part of the day trying to troubleshoot a SQL*Net issue. One of our virtual servers (VMware) suddenly starting getting timeout error in trying to connect to one of our Oracle databases. In fact, attempts to connect to other databases on other servers ended up the same. Something had change but what? All we know was our System Security Administrator decided to tweak the firewall (the virtual servers are on a separate private network from our database servers). Did a trace (TNSPING.TRACE_LEVEL=admin) to trace the route and it seems that we were getting an ORA-12560 TNS: Protocol Adapter error. Did some research and try a number of suggested workarounds but nothing work. Strange thing was other servers on that private network seems to be fine. Since the database in question wasn't production, I was happy enough to leave it for tomorrow as I had family commitments to attend to.

That's enough musing for the day and tomorrow, I will post on what I have found about the above error (or maybe one of my DBA would have fixed it by then)