suggests to me that you have the full backup exec product (not just a remote and/or Oracle agent) installed on the box - hence the MSDE install. It can eat all your rpc connections as well :) . Honestly paul - trying to do two things at once on a windows box <vbg>. Run a DB and backup software. If you are really lucky the tape drive will keep getting 'lost' and take the connections to the SAN with it. Niall On 9/13/05, Paul Drake <bdbafh@xxxxxxxxx> wrote: > > 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 > > -- Niall Litchfield Oracle DBA http://www.niall.litchfield.dial.pipex.com