I've just recently opened the pandora's box that is tkprof, as soon as I get a grasp of it, I plan to write about it in this space. Actually reading that link, along with the official documentation, will give you a pretty good idea on how to use it.
Got some IMs from one of my devs today including linkstoarticles about Oracle proxy users. The IT-eye articles are very nice, and the asktom article just provides some tkyte flavor to it all. The obvious and immediate benefit is for web applications that would normally log in as one application users, with many virtual users contained in some application-specific authentication and privilege system. Proxy users gives you the privilege/role system of having real Oracle database users, and tightens up security by stripping all privileges away from the "application user" except for CREATE SESSION.
It also gives you an outlet for authenticating your users. In my case I could have my application do any type of authentication I would want, say to our MS Active Directory setup, and if that succeeds, make the call to proxy as that user in Oracle. The important thing to note is that the actual user's password in Oracle is never used and never needs to be known.
Finally got around to installing the cx_Oracle lib for python. Since my Oracle sandbox at work is only CentOS3 (to be as close to prod RHEL3 as possible), I only have python 2.2, so I needed to build/install from source. Sadly, I didn't realize how trivial this was, but it's done now, and I can further my python fanboidom AND play with Oracle at the same time.
At last! I've restarted my personal dedication to actually know something about my job. Lately I've herded all my favorite Oracle blogs into Google Reader (which is a fantastic app, btw). Now that I've got the 10g DBA Handbook and the 10g OCA/OCP Exam Guide, I hope to do a lot more reading in the off-hours. I hope to turn around and provide any help that I can to future nubs and provide at least one technical Oracle posting here each day (perhaps not weekends).
Also, my wife and I launched a family-related blog, which is why I feel more at ease to take this thing on a tech tangent.
brotherlove sent this news. Yeah that's right, a movie adaptation of Welcome Back, Kotter! And who is a better choice to take on the role of Gabe Kaplan's Mr. Kotter than Ice Cube! I guess Vin Diesel had prior commitments.
Although this does allow for the chance to fantasize about Travolta reprising the role of Vinnie Barbarino, and then just have Sam Jackson play Freddie "Boom-Boom" Washington. I can just see him saying the classic "Hi there" and then blowing some dude away. You know with Ice Cube running the class it's going to be ultra-ghetto.
If Frank Warren can pull it off and still look cool, then why not me? Probably because I'm not cool to begin with. So now I've got the trifecta of social networking going with LinkedIn, MySpace and Facebook. I do have an Orkut profile somewhere. I remember back in 1995/1996 when Pascal turned me on to PlanetAll.
So I was apprised of some goings-on wherein our data warehouse tables were going to (finally) be moving from separate monthly tables (e.g. FOO_200607, FOO_200608, FOO_200609) to a single table with range partitions on the year and month fields and local indexes.
The developers were going to just do direct insert into the new table (presumably holding off on building indexes and constraints until after), but I immediately saw my chance to finally use Oracle's partition exchange. Paritition exchange basically allows you to do a logical swap of a single partition with a single table. The hitch is that the partitioned table and the to-be-swapped table have to be virtually identical in column types, sizes and constraints. The constraints part means you can't have a NOT NULL constraint on a column in one table and not in the other. If you use INCLUDING INDEXES in your exchange command, then the indexes need to be identical as well in terms of columns indexed.
I didn't even bother trying to do the "insert way," but I rest assured that I'm saving a LOT of time doing partition exchange. Equally important is the space saved. If I were to simply copy the data via insert statements, I would basically need to use twice as much tablespace, and in this case that is a LOT. Partition exchange involves none of that. I just do the swap and them I am free to drop the monthly tables (which should contain zero rows now). Anyway the big migration is part of a crazy Sunday SUNday SUNDAY of zaps and releases coming up this weekend. All the time saved for something like this is a huge win considering everything else that we need to get done in a Sunday night.
And one famous DBA told me that partition exchange is clutch for doing dataloads into a NOLOGGING stage table, then exchanging that table into your normal partitioned table. That avoids ugliness with NOLOGGING and redo logs. I currently bump up against this all the time doing RMAN duplication recovery because all of our DW tablespaces and tables were created with NOLOGGING. Yes it seemed like a good idea when we just cared about load times. But now I know that it shrinks my recovery window on any given day and also prevents us from trying to use DataGuard. We'll be going back to LOGGING next year after we have time to test and time it.
I can't remember if the DBA was tkyte, HJR or maybe hali from #oracle. All three rock.