Oracle jobs in Seattle and DB Replay in 10g
- From: "Jeremiah Wilton" <jeremiah@xxxxxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 4 Jan 2008 17:55:48 -0800
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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
