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

Home -> Community -> Mailing Lists -> Oracle-L -> OT: win32: veritas embedded ms sql server huge memory hog

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

From: Paul Drake <bdbafh_at_gmail.com>
Date: Tue, 13 Sep 2005 13:32:40 -0400
Message-ID: <910046b405091310327711c19f@mail.gmail.com>


ms w2k3 server (32 bit)
Oracle 10.1.0.4 <http://10.1.0.4> (32 bit) Veritas Backup Exec 9.1

I've had it.
This is the last time that I sit idly by and see Backup Exec allocate a process limit's worth of virtual memory to support a catalog database on a win32 oracle server. This box has no stand-alone ms sql server databases running on it.

How do the folks at Veritas get away with this stuff? This is not the first time I've seen this type of behavior, but as its right in front of me currently ... its all too convenient to vent it here.

Veritas - you hit my radar. I used to push Backup Exec as a third party backup software product.
No more.
Yes, I will RTFM and figure out how to cut this down the memory alloation to say 64 MB to handle the massive transaction load of 1 backup job per day on a server.

(yes, I know that "pskill sqlservr" would do that quite nicely)

In the meantime, if you're using Backup Exec on win32 - don't forget to add an extra 2 GB of physical memory for its embedded ms sql server process. Perhaps the vendor might refund you that cost from their product. ;P

Its not my box - otherwise I'd talk to some other backup software vendor that offers trade-ins.
It used to be that ARCServe and Veritas had a bigger war going than Netscape vs IE in the win32 space.

C:\rant> pslist -m sql

PsList 1.23 - Process Information Lister Copyright (C) 1999-2002 Mark Russinovich Sysinternals - www.sysinternals.com <http://www.sysinternals.com>

Process memory detail for "a non MS SQL Server server":

Name Pid VM WS WS Pk Priv Faults NonP Page PageFile sqlservr 1904 1746880 56452 56752 67480 65669 11 41 67480 sqlmangr 1560 35448 4452 6204 1452 2078 3 36 1452 sqlmangr 2204 35448 4452 6200 1452 2080 3 36 1452

oracle 3076 555520 455192 486080 468116 12264247 13 90 468116 oracle 2916 855088 734356 749404 755620 8561689 31 105 755620

1.67 GB of virtual memory allocated. I still can't believe it.

back to BDBAFH mode.

-bdbafh

--
http://www.freelists.org/webpage/oracle-l
Received on Tue Sep 13 2005 - 12:34:39 CDT

Original text of this message

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