Oracle jobs in Seattle and DB Replay in 10g

From: Jeremiah Wilton <jeremiah_at_ora-600.net>
Date: Fri, 4 Jan 2008 17:55:48 -0800
Message-ID: <017c01c84f3e$1882a180$4987e480$@net>


Hi list,

(technical content at end of post)

I have a few jobs in Seattle I am recruiting for, including at my former employer, the major Internet merchant with whom we are all familiar. I don't want to take up excessive list space, but in addition to DBAs, I am trying to find more senior Oracle professionals who can provide architecture and direction-setting functions. There are a couple openings in senior technical leadership that don't come around very often so if this interests you, please take a look. I recruit only for employers within my personal network or past and present technical colleagues.

http://www.ora-600.net/careers.html

Positions include:

SENIOR DATABASE ENGINEER, DATABASE ENGINEERING, INTERNET PIONEER - SEATTLE DATABASE ENGINEER, DATABASE ENGINEERING, INTERNET PIONEER - SEATTLE DATABASE ADMINISTRATOR, CHOICE OF GROUPS, INTERNET PIONEER - SEATTLE DATABASE ADMINISTRATOR, DATA WAREHOUSING, INTERNET PIONEER - SEATTLE DATABASE ENGINEER, SYSTEMS ENGINEERING, ONLINE TRANSACTION PROCESSING - SEATTLE
CHIEF ORACLE DBA, GAME CONSOLE GIANT - REDMOND, WA (SEATTLE) In order to redeem myself for posting jobs, I will try to provide some technical content as well. I have had a lot of exposure to DB Replay lately, and thought of a few things worth sharing. First, Oracle has been trying to get out the news that 10.2.0.4 will contain the capture functionality (dbms_workload_capture) of the DB Replay feature, so we will be able to leverage this tool for a 10g to 11g upgrade. In addition, I thought a variety of cool things we can do with DB replay that it was perhaps not ever designed to do. At very least, these are potential ways to leverage the investment in the additional license cost:

  • Use Database Flashback with DB Replay

Once a replay is completed, if the test system has flashback logging on, then you can record relevant performance statistics, then flash the database back to the start SCN of the workload. By doing this, you can try a variety of changes one after another, and quantify the impact of each iteration. For example, you can try several settings for an initialization parameter, and determine which setting provides the best performance under your workload. You can also keep the same test database and workload around for repeated use with any number of unrelated changes. Whenever a DBA wants to quantify the impact of something they are going to change, they can use a canned database and workload that they keep on a test system.

  • Perform mid-stream changes under DB Replay workload

A common source of database service destabilization is the running of maintenance or change tasks under production load. By performing these activities in the middle of a running DB Replay workload, you can simulate what effects performing that activity under production workload may have. Any global change, or activity that might invalidate SQL or generate waits would be a good candidate for such testing. If you feel afraid to do something in production, it is probably a good candidate for testing under DB replay load.

  • Problem simulation under DB Replay workload

If a particular job or activity is causing performance problems in production, you can try running that same activity under DB Replay workload, and diagnose the causes of the problem in the comfort of a test database rather than in production. You can also use known destabilizing activities to simulate problems under DB replay workload to give DBAs an opportunity to practice diagnostic methods.

  • Test case identification

If a production performance problem occurs predictably, you can use DB Replay capture to capture the database workload during the time of the problem. That problematic workload may then be replayed repeatedly (using Database Flashback) in a test database. This provides a quicker path to root cause identification, because you can run many repeated simulations of the problem as are needed. Without DB replay, you would have to wait hours or another day for the next occurrence of the problem to try to diagnose it.

My Openworld whitepaper on DB Replay is here:

http://www.ora-600.net/articles/wilton-CustPerspectives.pdf

Thanks,

Jeremiah Wilton
ORA-600 Consulting
http://www.ora-600.net

--
http://www.freelists.org/webpage/oracle-l
Received on Fri Jan 04 2008 - 19:55:48 CST

Original text of this message