Re: Oracle jobs in Seattle and DB Replay in 10g
Date: Mon, 7 Jan 2008 08:31:55 -0500
Very interesting and informative article and the paper. Thanks for sharing your thoughts with us.
On Jan 4, 2008 8:55 PM, Jeremiah Wilton <jeremiah_at_ora-600.net> wrote:
> 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
> and direction-setting functions. There are a couple openings in senior
> technical leadership that don't come around very often so if this
> you, please take a look. I recruit only for employers within my personal
> network or past and present technical colleagues.
> 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 -
> 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
> 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
> back to the start SCN of the workload. By doing this, you can try a
> of changes one after another, and quantify the impact of each iteration.
> 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
> 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
> 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
> 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:
> Jeremiah Wilton
> ORA-600 Consulting