Re: Oracle jobs in Seattle and DB Replay in 10g

Jeremiah,

Very interesting and informative article and the paper. Thanks for sharing your thoughts with us.

Vlad Sadilovskiy
Oracle Database Tools
Web site: http://www.fourthelephant.com
Blog: http://vsadilovskiy.wordpress.com

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
> 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
>
>
>

--
http://www.freelists.org/webpage/oracle-l