Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Remote or Not? Was: Production Oracle DBA Needed in Rochester

RE: Remote or Not? Was: Production Oracle DBA Needed in Rochester

From: Michael Kline <mkline1_at_comcast.net>
Date: Tue, 26 Mar 2002 13:25:32 -0800
Message-ID: <F001.00434197.20020326132532@fatcity.com>


This is a bit of what I do, for those who wonder...

I *AM* one of those persons we are discussing, and I work from home. I've got clients in Texas, Oklahoma, Pennsylvania, New Jersey, Virginia, Ohio, and others that are often just a phone number and passwords...

What I do is just a tad different in that I trend databases and can tell the clients things like "This is what you are doing and if it continues you are going to need two more disk drives in July, and two more in Sept. You'll have a choice of doing that or move application two to a new system."

I would guess my more personal slogan is "No More Database Surprises".. to which most managers reply "That's EXACTLY what I'm looking for." Management tells me I have a FIERCE customer loyalty.

But with the trending, I am normally way ahead of what's going to happen. At one client I've got tables in a "no room" situation, but that's not going to happen for 4, 7, 9, and 17 weeks. I'll work on the 4 in a week or two. This client came with me when I changed jobs. They have also given me 3 other databases to watch for them. This leaves their group free to work on development and moving the business forward, and except for electricity, network, and the like, the database has not had a crash in 4 years.

Environment: I have a cable modem, 2 modems, 5-6 computers but mostly work off an HP Desktop and Compaq laptop. You need a headset for the phone, I've got 3 phone lines. I've got Comcast.net and Earthlink for backup. Storage for customers is about 400-600 meg. File server has 100gb of disk. Every pertinent piece of customer info is on 3 different pcs, and 4 different disk drives. CDs for archiving.

The only thing I can't do from 300-4500 miles away is change CDs or mount tapes.

"Normal Day": Get up, shower, make coffee, go down stairs and start email which includes various reports mailed from the customer site. Make sure everything is fine, and that no one has mailed with any new "opportunities". Check out all the lists such as Oracle-L. Also keep track of Smart Partners, VAR Business, all sorts of NwFusion and other lists that track the going ons of our businesses. Submit occasional "view from the field" back to management.

As we get into afternoon, I then dial up, vpn, or "back door" into various clients and perform the daily checks. Several evenings I do "the gathering" from which I do my trending, no more often that once a week, and some only once a month.

So if you are wondering, the days may run something like this: 7:45-9:30 email, filing, etc...
10:30-12:30 email, filing, R&D, etc.
2:00-4:30 - checking databases.
8:00-9:30 - twice a week, evening gatherings

about 4-6 hours on Saturday, occasional 2 hours or so on Sunday.

On all the databases I watch, I get beeped or called perhaps once a month or so. I have a cell phone.

I've been involved in conference calls. I "touch base" with the "nuts and bolt" people of clients several times a week either by cell phone, email, or ICQ/IM.

*Part of a business*: Being part of a team is good because it allows me to have a vacation. The "daily" stuff gets passed along to the fellow team members. The "laptop" can do the gathering, and that's only about 5-8 hours a week, pretty much when I want to do it. Customers can get the reports when I get back. Also, since there are "others" that can do Oracle App customization and development, I stay a DBA. The team is tied together with ICQ which allows us to ask backup ("Can you go look at XYZ and expand the temp space, I'm busy on ABC"... "Okay, be on it in 5 minutes."... "Thanks.") Our internal team listserv is some 150-250 DBAS and developers.

*For the customers*: I think they are charging about $800-5600 a month for customers or $9600-$67,2000 a year for a dba team of 8-15+ years experience. I know many of my customers have to have a fixed cost so they can budget. And with the backup and all, there are no benefits, no vacations to worry about etc. (The high end is for full Oracle Apps support.)

And it's totally proactive. With the trending and some daily watching we catch the problems way before they even show up as a show stopper. A new ramp up at one customer took I/O from 100 to 400/sec in just a short time and index use fell from 80% to 5%... They had a report with the SQL in question, which datafiles, which conveniently pointed to 80% of it being the datafiles of the new application, and a list of recommendations... This allowed their people to work on getting things right and not having to worry about each little nut and bolt.

There have been conference calls with the client and whole development team and management going over the reports, ways to get things done, and the steps to accomplish.

But anyhow, for those that were wondering, that's what I do... It can be long hours, but I normally only see a "database emergency" about once a year. Everything else is planned in advance.

Michael Kline
ThinkSpark
Richmond, VA
804-744-1545

> -----Original Message-----
> From: root_at_fatcity.com [mailto:root_at_fatcity.com]On Behalf Of Paul Vallee
> Sent: Tuesday, March 26, 2002 1:09 PM
> To: Multiple recipients of list ORACLE-L
> Subject: Re: Remote or Not? Was: Production Oracle DBA Needed in
> Rocheste
>
>
> Hello everyone,
>
> This is a very interesting thread. Speaking as a part-owner of one of the
> companies John held up as an example of the successful outsourcers (thanks
> for mentioning us John), I'd like to make some points that I think will be
> of interest to all.
>
> The first is that working in a shop such as Pythian is actually a dream come
> true for many DBAs. The fact that the industry is trending to a managed
> service model for database administration is NOT A BAD thing for salaried
> DBAs out there. I think the opposite is true. The same thing happened for
> payroll specialists in the 80s and 90s, and now some 40% of companies
> outsource payroll. Those payroll specialist jobs simply migrated from
> individuals working solo in firms into working in teams for the Ceridians,
> Paychex and myriad competitors (i.e. almost every bank too) of the world.
>
> It's a great transition for many reasons that work well for the DBA as well
> as for the customer. I'll concentrate on the advantages for the DBA (why
> DBAs love working here), because they might not be as obvious. I can't speak
> for our competitors (hissss!!! just kidding) :-) , but I believe a similar
> dynamic applies to them. A Pythian DBA gets experience on every major
> platform Oracle runs on: Solaris, HP/UX, Tru64, AIX, Linux, Win2k, I'm sure
> I'm forgetting some. A Pythian DBA gets experience on many versions of
> Oracle, in many industries simulaneously. We get to learn and develop best
> practices learned by seeing the way Oracle is used in many shops. We get to
> work in teams, relying on each other to help in emergencies, unstall each
> other, teach each other and develop each other's skills, and make sure we
> put our best foot forward for any customer simply because as a team we have
> an enormous amount of skills and experience. We get to learn and teach the
> very best in the industry, getting to know and understand that even the
> giants don't know everything while still having so much to share. We get to
> know our customers so well we mutually consider ourselves teammates,
> co-workers and sometimes even friends, greatly leveraging our network of
> contacts and friendships.
>
> We get to take on new shops on a continuous basis, whenever the company
> signs on a new customer, instead of having to quit a job when it gets
> boring. The way I've structured our company, in many small teams, we even
> get to take on completely new challenges and team dynamics simply by
> changing teams, rather than having to look elsewhere. We get to not be
> on-call every night, to not get shit for taking holidays, to not have to
> work insane hours (our team model is scalable in a way that the
> single-person salaried model is not.) We get to work on some of the most
> challenging environments in the world. I'm not kidding; I'm sure Jeremiah at
> Amazon has his hands full, but I am confident any DBA here would have
> something to talk with him about if they sat together at a dining-room
> table.
>
> Moreover, we get the satisfaction of doing an extraordinarily good job. I
> considered myself an accomplished DBA before having started this company.
> And yet I am completely certain that never was I able to do as good a job as
> we are doing now as a team. We provide sophisticated problem tracking tools,
> availability monitoring tools and and performance monitoring tools that
> never when I was an individual could I have contributed. It's extremely
> satisfying and fun.
>
> Moreover, much of our work is with DBAs (or teams of DBAs!) at customer
> sites. We work with many shops where we are not the sole DBA resource, but
> rather a part of a larger team, sometimes with us doing mentoring, back-up
> and on-call support for a DBA early in their career. Sometimes, it's when a
> company has an (or many) expert DBA that's completely swamped, and we help
> with the 24/7 and routine but lengthy aspects of the work and let them focus
> on the project management, strategic data modeling and other tasks that are
> more than enough to keep them on the right side of the very busy/having a
> breakdown boundary. I can't recommend it enough; I haven't had a better job
> or been happier at work than I am here.
>
> Hope this give you some insight into our company and what we're trying to do
> here.
>
> Best regards,
> Paul
> ---
> www.pythian.com -- vallee_at_pythian.com -- 877-PYTHIAN
> Smarter than adding another team member, Pythian has new services for
> supplementing DBAs: get our help with monitoring, 24x7 on-call, daily
> verifications, storage management, performance and more.
>
> ----- Original Message -----
> To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com>
> Sent: Tuesday, March 26, 2002 2:53 AM
>
>
> Personally I like being in the office environment and interacting with other
> members of my species :-) I do get the opportunity to work from home on a
> fairly regular basis and I do take it when I really need to focus on
> something but I do miss the buzz of being in the workplace if I'm away for
> too long. Working from home is ideal around the holidays and those days when
> you have overindulged in whatever your favourite tipple is the night before
> and driving into work would be too risky :-)
>
> FWIW - there are two DBAs in this country (UK) working for our company and
> we live about 300 miles apart. I work from the Data Centre, with the UNIX
> SAs and the hardware in the North East of England, he works from an office
> in London with the developers. It works well (esp. for me !!) and we meet up
> on a regular basis for status meetings and catch ups.
>
> Regards
>
> Lee
>
> -----Original Message-----
> Sent: 25 March 2002 23:08
> To: Multiple recipients of list ORACLE-L
> Rocheste
>
>
> Hi all,
>
> Thanks Chris for that nicely worded e-mail. It *is* true that Development
> work is easier to farm off elsewhere where it is cheaper, and even Oracle
> Corporation is farming out Internet-based Support and Development work
> elsewhere. These teams typically work with a bunch of junior developers
> somewhere else working on the major chunk of the project, fronted by one or
> two 'implementors' - typically senior and more 'culturally aware' locally
> working with the users/businesses they serve. This Development model does
> lend itself to such offloading.
>
> However, I haven't heard of similar farming out of day-to-day DBA or SA
> services *outside* of the US. These services are perceived as 'Business
> critical' jobs still and Management wants to see/hear the key-clicks, esp.
> when a Disaster occurs or something goes wrong. Steve Orr - the one who
> escaped this $$$ valley for the wide open spaces he loves - made the point
> that Remote working is more an organizational issue than a technical issue.
> Face-to-face and human touch-and-feel still is still required, and time
> zones are still an issue (even here in the States where the West and the
> East is separated by just 3 hours).
>
> Having said that, I have to say that I am in the process of wrapping up a
> 'remote' performance troubleshooting mini-project for a previous client.
> VPNs, Previous association and familiarity with systems/personnel and the
> requirement of out-of-the-ordinary skills for a limited period drove this
> remote assignment, and it worked out successfully. I did suffer from the 3
> hour timezone difference, though it worked to our advantages at times. I do
> also know that many DBAs have been 'farmed-out' to 'Remote DBA Services'
> within the country (counting Canada too - Pythian, TUSC, ...), and a number
> of cross-country tuning assignments (from Australia - need I say more!) have
> also worked out well.
>
> On a personal front, I observe that (at least in the US) the urban/suburban
> cost-of-living is driving more and more remote workers (quite a number of IT
> workers, esp. DBAs) into the extended suburbia (100 miles or more, up from
> the current 50 mile radius), where these workers do come in once or twice a
> week, sometimes to 'branch offices' spread out among the various suburbs....
> Hence, you could theoretically work as a DBA in a city somewhere else for an
> organization with HQs/DBs somewhere else, as long as you have
> access/presence of a remote office, and possibly fly down to the HQ once in
> a while. Remote workers still need to be in a community, with access to
> education, recreation and health servcies, so this will probably not be too
> far off the beaten path.
>
> On another tack, there was a discussion on this list about Ari's cool tools
> - the PocketDBA/SA. I could theoretically be far away in a log cabin (Steve
> - are you listening?!) and still be connected to the office - the question
> is: Do you want to be? In other words, most tools for full remote capability
> are available. But would Damagement accept them and not have to see a warm
> body fill a seat?
>
> John Kanagaraj
>
> > -----Original Message-----
> > From: Grabowy, Chris [mailto:cgrabowy_at_fcg.com]
> > Sent: Monday, March 25, 2002 12:46 PM
> > To: Multiple recipients of list ORACLE-L
> > Subject: RE: RE: Production Oracle DBA Needed in Rochester, Minnesota
> >
> >
> > Ahhh...be careful what you ask for. If that were truly the
> > case, then you
> > might not be able to find a job, since you would be outbid
> > from someone
> > working else where. Obviously, skills are a critical factor,
> > but explain
> > that to the bean counters...
> >
> > Some of the developers here are becoming very angry because
> > some of the work
> > has been "farmed-out" overseas because of their lower rates.
> > It is a very
> > interesting situation that I am quietly observing. The world
> > is indeed
> > becoming smaller.
> >
> > I have carefully worded this email in the hopes that I do not
> > offend some of
> > the VERY talented/god-like DBAs we have on this list that
> > come a variety of
> > locations around this great planet. I hope that I have succeeded.
> >
> > -----Original Message-----
> > Sent: Monday, March 25, 2002 3:04 PM
> > To: Multiple recipients of list ORACLE-L
> >
> >
> > Yeah, does anybody know what happened to the new Internet concept of
> > "location doesn't matter"? I thought by now I could be sitting at home
> > taking DBA assignments all over the country, if not over the world?
> >
> > Dennis Williams
> > DBA
> > Lifetouch, Inc.
> > dwilliams_at_lifetouch.com
> >
> >
>
>
>
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Paul Vallee
> INET: dbalist_at_pythian.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Michael Kline
  INET: mkline1_at_comcast.net

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
Received on Tue Mar 26 2002 - 15:25:32 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US