Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Post
  • Reply
GanjamonII
Mar 24, 2001
Does anyone here run oracle on iscsi? we're having some performance issues.
I apologise in advance if I mess up the terminology or details as my experience is on the application side and some of this stuff is kinda new (as in.. since since we discovered the issue). There are real server/storage folks looking at this too but I think there is a lot of expertise on the forums also. Also I'm responsible for the application running on this DB.

We have NetApp 3070 supplying about 1.8Tb to our oracle box (server 2008 x64) which is running 4 databases. The server is a beefy 4 socket HP blade (bl something or other g6, can't remember the model) 32gb ram with 2 1gb nics teamed for the production lan. We're using microsofts iscsi initiator software.

Our DBA ran the AWR report for oracle which shows that its waiting on i/o something like 70+% of the time. It reported the throughput at something stupid like 478kb/s read and 68kb/s write which I can pull on my home DSL connection so either that is not accurate or something is really wrong cause these things are in a serious datacenter about 3 feet apart. The LUNs are in a volume/aggregate/whatever with 26 disks so there should be plenty of spindles, and the report from storage team is that the disks are basically idling along at under 10% average utilization.

Oracle is reporting average request latency of 35-50+ms for some of the database files, whereas our storage team reports average request latency on the filer is something like 4ms. So seems there is something going on between oracle and the filer. CPU usage on the servers is low, there isn't any network issues we're aware of, though we're checking into it.

This is supporting a business critical application and looks like our db is going to increase significantly in size over the next 6 months. Performance for the application overall now is borderline - it is very slow but still usable but its definitely not acceptable and users are not happy with it.

Anyone have any advice? It would be really appreciated.

Adbot
ADBOT LOVES YOU

GanjamonII
Mar 24, 2001

Cultural Imperial posted:

Is this a new oracle install?
Are you using snapdrive?
What initiator version?
How have you configured your target NICs on the filer? Are they vif'd?
What ontap and snapdrive versions are you running?
What oracle version?
Are your servers clustered?
How complicated is your networking? ie multiple vlans?
Misogynist and Adorai asked very good questions about your network. I'd also take a look at basic stuff like duplex and autonegotiate on the switches.

Finally, have you opened a case? If not, I suggest you do so now. You're paying for support anyway. Might as well use it. This sort of problem is well within the responsibilities of the support centre.

Everyone who replied to my query - thank you. I haven't posted an update cause I can't post at work and my internet at home just got reconnected after moving.
We found that the servers/enclosure/network hadn't been configured as per the PTM. All traffic was going over the production network, not the storage vlan. We had purchased nics with hardware iscsi which are disabled and the correct cabling hadnt been run to the blade enclosure blah blah blah. All getting fixed this weekend hopefully. We also found Oracle was misconfigured in terms of some parameters and memory configuration which looks like it was slowing it down a bit anyway.

  • 1
  • 2
  • 3
  • 4
  • 5
  • Post
  • Reply