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: win32: veritas embedded ms sql server huge memory hog

Re: win32: veritas embedded ms sql server huge memory hog

From: Paul Drake <bdbafh_at_gmail.com>
Date: Tue, 13 Sep 2005 14:25:18 -0400
Message-ID: <910046b405091311255abf0ef3@mail.gmail.com>


On 9/13/05, Kevin Closson <kevinc_at_polyserve.com> wrote:
>
> Are we confusing a bug with an architecture issue?
> Personally, I don't put my cross-hairs on any product
> for bugs...only completely flawed architecture issues
> get my focused attention.
> Sorry, I'm sure that was no help.
>

Kevin,

I take it that was a crack at win32 OSes. Point taken. RHEL 4 ES would do quite nicely but that was not my call.

Thanks for your input, but what I believe that it is is along the lines of ... backup exec developer sets parameter in embedded database product to use the process limit for ~sga_max_size.

The reason that this particularly irks me, is that I've already had to deal with client site systems with 4 GB of physical mem, running as a single purposed box supporting 2 smallish oracle databases having virtual memory issues. I'm getting support calls for a mistake made by Veritas Backup Exec staff.
You know the kind of support issue - "the system is slow".

There a monitoring app (java process) and the backup exec ms sql server process (that was not even required) were using 2.5 GB of virtual memory. This wasn't like Linux filesystem caching where the OS will give it back as needed.

My point is that Veritas pushes out an update that resolved some serious security issues ... and as a side effect we get denial of service issues regarding memory allocation and system resource utilization. I want the blame squarely placed upon the guilty party.

I haven't worked directly with backup exec since the 7.3 release. I have no working relationship with their tech support, no one's email address on the inside.
I just figured that if a dozen users send an email to their accounting office requesting backcharging the vendor for 2 GB of physical memory that the issue would hit Backup Exec's management much more quickly than an email that gets forwarded to /dev/nul. Vendors HATE backcharges.

So if you're running Veritas Backup Exec v9.1, download a copy of pslist.exefrom the
sysinternals.com <http://sysinternals.com> website and run it

C:\pstools> pslist -m sql

and see how much mem, vm its chewing up.

Its actually rare these days to see a tape device mounted to a server as a single purpose, but some CFOs/controllers still like taking home a tape of their accounting system database with them each week/night as a cheap form of DR. According to a Computerworld article, there are still alot of companies that can't get their tapes off of Iron Mountain down in LA.

back to the upgrade treadmill.

Paul

-- 
#/etc/init.d/init.cssd stop
# f=ma, divide by 1, convert to moles.

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Sep 13 2005 - 13:27:19 CDT

Original text of this message

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