A common complaint in SQL is that "it runs in 5 seconds in SQL*Plus, but takes hours in Production. Why?"
The reason is because SQL*Plus and most GUI SQL tools display rows as soon as they are fetched. In this way, you can
SELECT * FROM big_big_table and it will display the first 20 or so rows in the table in a fraction of a second, then go back for more. The SQL is not really finishing in seconds; if you timed how long it took to retrieve every row, you'd see that it takes just as long as in Production.
This article provides several comparative methods to avoid primary key conflicts across multiple sites.
When you setup statspack with level 6 you can have information on the sql_plan associated with a sql.
I'm not really an "early-adopter" of technology. Don't get me wrong; I love it, I just don't want to feed the addiction. When I do get a new piece of technology though, it's like a fever; I can't concentrate on anything until I've read the manual from cover to cover and found out everything it can do, every built-in gizmo, and every trashy piece of after-market merchandise that can be plugged into it.
And I don't think I'm alone here.
Where were you in 1990? Nelson Mandela was being freed from Victor Verster Prison after 26 years behind bars, Saddam Hussein was starting the Gulf War by invading Kuwait, and Tim Berners-Lee was inventing the World-Wide-Web at CERN in Geneva. Me? In 1990, I was writing an insurance system in Oracle SQL*Forms v2.3.
Well, just for a briefing, since 1966, most of the United States has observed Daylight Saving Time from at 2:00 a.m. on the first Sunday of April to 2:00 a.m. on the last Sunday of October. But in 2007, most of the U.S. will begin Daylight Saving Time at 2:00 a.m. on the second Sunday in March and revert to standard time on the first Sunday in November.
So, Oracle has released patches to adapt these Daylight saving time changes. The databases that are using the following will be impacted…
1. Databases using TIMESTAMP WITH TIME ZONE and TIMESTAMP WITH LOCAL TIME ZONE data types and TZ_OFFSET function as they take their time zone information from Oracle's time zone files.
Recently Performance Tuning compared Oracle 10gR2 RAC on Windows Server 2003 x64 vs. RHEL. You can download the paper from microsoft-oracle.com
The following behavior was observed during testing of the Oracle RAC databases on Red
Hat Enterprise Linux x86_64 and Microsoft Windows Server 2003 Enter:
Oracle RAC Stress Test
o Transactions Per Minute were roughly equivalent for 2 - 150 user sessions.
o Transactions Per Minute were up to 16% higher for MS Windows for 150
- 250 users.
o CPU usage was above 90% for all of these tests for both Linux and MS
o The response times for the “New Company Registration” test component
A handy alert log is invaluable for troubleshooting database problems. A RAC database has multiple alert logs.
I prefer to monitor them through a single table.
"A master failing to make an entry in the vessel's official
logbook as required by this part is liable to the Government for a
civil penalty of $200.
United States Code. Title 46 - Shipping. Subtitle II -Vessels and seamen, Part G - Merchant seamen protection and relief. Chapter 1113 -Official logbooks.
How meticulously do you keep your book log, Captain?
Luckily for us, our databases are as much ships as they are first mates. They are intelligent enough to keep their own records. And those logs are as important as vessel logs of the past, because the information carried by an early 21st century database could be easily worth more than 1450 tons of tea carried by Cutty Sark in 1870 en route from Shanghai to London.
As Oracle does all the mundane work, our role becomes more creative - to inspect and properly use the gathered information.
Today I have been experimenting with the new feature of continous mining with logmnr.
- Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options
- ALTER DATABASE ADD SUPPLEMENTAL LOG DATA
or we don't see the funny things in the redologfiles
dbms_Logmnr.Start_Logmnr(StartTime => SYSDATE - 1 / 24, Options => dbms_Logmnr.dict_From_OnLine_Catalog + dbms_Logmnr.Continuous_Mine);
During a test of some backup setup with rman I ran into problem running the restore / recover command.