Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Usenet -> c.d.o.server -> Re: HELP - Oracle Schema Import problem
On Jul 26, 6:02 pm, Johne_uk <edg..._at_tiscali.co.uk> wrote:
> Hi,
>
> I have 2 identical Solaris servers (freshly installed v490 - dual CPU
> 8GB RAM). The OS (Solaris 10) were both installed to an agreed spec by
> 2 diff consultants (all disk mirrored and striped).
>
> I created identical 9208 DB instances on both servers (using identical
> scripts with only diff being SID names).
>
> I then imported a schema dump (from another db server) on server 1.
> This took about 3 hrs.
>
> However, despite an idential setup the second server took up to 3
> times longer than the first to import the same export dump (except
> this dump was sourced from a Linux db whereas the first was from
> another solaris instance)
>
> Im not an expert DBA and in the morning need to start troublesheeting
> this performance bottleneck. Could the linux sourced export be the
> reason for it being being slower on server 2. No logs etc were
> generated whilst importing.
>
> If I rule out using a linux derived export dump AND verify there are
> no i/o issues with the Solaris server how would you suggest I proceed
> to identify the bottelneck on server 2.
>
> Apologies for the simplistic explanation (there are reasons for using
> the Linux export) but I'd appreciate any pointers on how to start
> solving this as I'm currently stuck in a hotel room and cant get my
> hands on the system until the morning.
>
> Thanks in advance
> John
Two things immediately pop into mind:
Be sure Intimate Shared memory is set the same on both kernels, and especially, is set the same for both Oracles. Google for it and see metalink Note:317257.1 section 7.2.
Are the I/O systems exactly the same? You should see what Oracle is
waiting on, check if CPU's are maxed out, use system utilities to see
what the I/O is doing, and so forth.
http://kevinclosson.wordpress.com/2007/07/21/manly-men-only-use-solid-state-disk-for-redo-logging-lgwr-io-is-simple-but-not-lgwr-processing/
might be kind of interesting given the likely things you will be
waiting for with the mass loading from an export.
Then of course, there are the more, well I won't call them silly, but how about pedestrian things, like do both systems have archiving turned on or off as the case may be, any other differences between init.ora's, something else running on the systems, swapfiles determined differently, one system doesn't have controllers duplicated, you are using autoextend on the data tablespaces, etc. For that matter, I've seen slowdowns be an indication that a disk or controller is about to die.
As far as the sysadmins go, "Trust, But Verify." Also see http://oracledoug.com/serendipity/index.php?/archives/1278-DTrace-Discussion-List.html
Remember, what Oracle sees as a problem and what the system sees as a problem may be skewed by the instrumentation used. Just mindlessly playing with knobs probably won't help.
jg
-- @home.com is bogus. "You know, you look a lot like Catherine Zeta-Jones" - restaurant customer "You know, I get a lot of that." - Catherine Zeta-Jones, training for a movie role.Received on Fri Jul 27 2007 - 13:50:50 CDT
![]() |
![]() |