Submitted by Kevin Meade on Mon, 2007-04-09 17:07
Been doing a lot with Historical Perspective lately. This has caused me to think a bit about the different variations of lookup that can be called a Point In Time query. My customers have found this discussion useful in understanding the details of how their report programs find specific rows in time. It is helpful to them because it provides an understanding as to why a specific row shows up on a report, and thus allows them to create more exacting definitions of what they want. Plus I find it is a good primer for newbies on staff to read so they don't make the same mistakes we made when we first started doing PIT queries. Maybe you can use it too.
Submitted by abatishchev on Fri, 2007-04-06 08:54
Once upon a time Le Petit Chaperon Rouge (LPCR) decided to change db_files from 200 to 300 on a busy cluster of four nodes.
Soon after the change applications started to block each other, timeout and crash (enq: TX - contention, cursor: pin S wait on X, enq: HW - contention). Those applications which were actively inserting into LOB columns - suffered the most.
Many lock holders were waiting for "DFS lock handle". Thus LPCR learned that DFS stands for "Distributed File System".
As soon as she reversed the changes - everything went back to normal.
Submitted by Kevin Meade on Wed, 2007-03-28 17:15
One of my recent clients had a real data twisting process to validate. It didn't help much that their source had been corrected by many "ONE-SHOTS" over the years to deal with bugs, and accounting methods mandated by Act of Congress. What we needed was a way to see changes in a stream of related rows. In the end I created for them, a solution that allowed developers to pick two rows from a table at random and compare them in SQL with a result set returned showing only differences. Its a simple thing, but kind of neat, and very useful. So I'd like to share it with you.
Submitted by Kevin Meade on Mon, 2007-03-26 17:24
Recently my friends at work saw me doing things with indexes they didn't understand. They saw what looked like unneeded columns in some indexes, and funny expressions they didn't know could be done in an index. So I explained to them the benefits of INDEX ONLY ACCESS, and FUNCTION BASED INDEXES. They had not seen these two techniques before so I figured maybe other people would be interested too. Here is it, a short discussion on what are fast becoming my two favorite tuning techniques.
Submitted by saibal on Sun, 2007-03-25 11:35
To continue with the shared server series, as mentioned in my last post, I will here be taking up the issues of configuration of memory, and the management of shared servers using available data dictionary views and initialization parameters.
How much memory should you configure for shared servers?
Submitted by saibal on Sun, 2007-03-25 11:33
So, to continue with our shared server series, let's begin with how a user connects through a shared server connection:
Submitted by saibal on Sun, 2007-03-25 11:25
This is the first of my three-part series dealing with Shared servers: Today an organization can have hundreds or thousands of users connecting to their databases. The traditional dedicated server model maps each user to a dedicated process running on the database server. Each dedicated server process requires memory and as the number of users increase, there is a linear increase in the demand for memory.
Submitted by rleishman on Thu, 2007-03-08 23:58
A common sight in databases is a table that contains the start and end values of a range - usually dates. One or both of the dates are typically part of the primary key; sometimes they are the entire key. Some examples:
- History tables
History tables record the changes made to a row over time. Instead of updating a row and losing the prior values of each non-key attribute, a new row in inserted. Each row is differentiated by two columns that record the date the row was created (
START_DATE) and the date it was superceded (
Submitted by bhupinderbs on Tue, 2007-03-06 04:40
Here is a Function that convert NUMBERS into WORDS:
[code]CREATE OR REPLACE FUNCTION f_words (p_amount IN Number) RETURN Varchar2 IS
--Author : Bhupinder Singh
--Creation Date : 05/03/2007
--Purpose : This Function returns amount in words.
--1) p_amount : Only positive and negative values are allowed.
Precision can be entered upto 10 digits and only 2 scales
are allowed e.g 9999999999.99
Submitted by rleishman on Fri, 2007-03-02 18:25
One glance at my golf clubs would be enough to determine that I'm a terrible golfer. The pitching wedge is dirty. Nine-iron: dirty. Same with the eight, seven and six irons. Five, four and three irons are fairly clean. Woods: pristine. I play percentage golf (actually 110%, if you count penalties); I figure a 5-iron 150 meters down the fairway is a better bet than a 3-wood 200 meters into the trees.
So I've got a golf bag with 2 clubs that I paid for but never use. Madness? Well no, not really; but then I'm not paid to play golf. Can you imagine a professional golfer never using the driver? It wouldn't happen.
Can you picture an Oracle programmer never using the most powerful join method available? No? Get a mirror.