toasters March 2002

toasters@lists.teaparty.net

120 participants
168 discussions

RE: Vol/qtree/dir/file snapshots (was Re: DataONTAP 6.2) ORACLE D ATABASES
by Joe Luchtenberg 29 Mar '02

29 Mar '02

I think Chris' point has more merit than you give credit, Quentin. There are many issues to consider, including segregating the root volume, parity disks, costs of additional shelves/cabinetry/head units, etc. Granted the cost of disk capacity does not scale linearly. However, if you're not using the additional capacity in a volume (30GB database on a volume of 5-6 72GB drives, as in Chris' scenario) - and there may be very good reasons for this - then big drives are definitely not the most cost-effective way to scale capacity. Qtree-level SnapMirror and/or file-level SnapRestore may solve some of these issues related to capacity management, allowing you to put more databases on the same volume. Even still, it would be nice to have an internal 2x9GB volume (maybe even with solid state disks!) to serve as root, rather than "wasting" 72GB drives and shelf slots. Just musing... Joe Joe Luchtenberg Dataline, Inc. Email: joe.luchtenberg(a)data-line.com Phone: 757-457-0504 (direct line) 757-858-0600 (front desk) 757-285-1223 (mobile) Fax: 757-858-0606 Please visit us at www.data-line.com > -----Original Message----- > From: Quentin Fennessy [mailto:quentin.fennessy@amd.com] > Sent: Friday, March 29, 2002 8:29 AM > To: Chris Lamb > Cc: Melvin, Grant; 'Noll, Kevin'; 'Toasters (E-mail)' > Subject: Re: Vol/qtree/dir/file snapshots (was Re: DataONTAP > 6.2) ORACLE > DATABASES > > > > Chris asked: > > Of course, one just begs to ask: WHY is it that we > continue this absurd > > notion that bigger is always better? Who the hell needs a > 72GB BOOT DISK? > > Sure, maybe when Windows(tm) 2004 comes out... :-) > > This is a detail that is unnecessary to sweat. Large drives > don't have to be > full. The cost of capacity is dropping -- at a given time in > product life, a > 72GB disk is not 8x the cost of a 9GB drive. It may well be > 1x the price, > this 1/8x the cost! > > Leave the disk space empty if its use is not appropriate. > > If you need extra spindles for performance, buy them. Don't > get caught in the raw capacity trap. > > I cannot imagine that it is economical to continue to sell > relatively smaller disks, when for the same outlay the > disk manufacturers can provide more capacity. The factories > can provide X disks (or disk platters) per week. They will > optimize appropriately. And they would go out of business > if they did not, because the competition will! > > As a system administrator we (you and I) all have to exercise > judgement on > how to best manage these resources. If your boss or your > customers override > your judgement then something should change. But it won't be the > manufacturing economics of disk drives! > > > > Yes, it is a fundamental law of computing that files and > databases will > > always expand to fill the available disk space, but why is > it that you > > can't even buy a 9GB drive anymore? A 20-30GB database, even if you > > double or triple it in size, is still going to fit on *one* > shelf with > > 9- or 18GB drives. > > > If I had a 30GB database, I'm sure my DBA would agree - > striping 5-6 9's > > together makes way, way more sense than throwing piles of > higher-cost 36's > > or 72's at it, only to waste massive amounts of space in an > effort to keep > > performance up. Of course, our database grows at over 30 > million rows per > > week, so adding 36's makes sense for us. :-) Still! I > echo the call for > > using appropriately-sized drives where it makes sense. :-) > > > All of my production servers have ridiculously huge boot > drives because > > that's the only way Sun (or anyone else) sells them these > days. So I > > mirror / & /var, interleave swap, and even after sizing > things to some > > absurd degree, there's usually a chunk of 8-10GB of free > space - 'cuz all > > the good stuff lives on the filers. Having that local disk > space there > > just means that someone is going to want to USE it, and > that's bad - it > > means I'd have to actually back up those machines, and I > *hate* backups. > > (In the exceedingly rare case where both drives of a > mirrored boot volume > > are corrupted or destroyed, it's always going to be faster > to re-Jumpstart > > and cfengine the machine from scratch than to restore from > tape anyway. > > Local data just messes up all that beautiful automation. :-) > > > A long time ago I was going to recommend that filers come > with a pair of > > internal boot drives - like a mirrored pair of 4GB or 9GB drives > > _strictly_ for use as the boot volume, with some space for > logs, etc. > > There's plenty of room inside the big filer heads for a > pair of drives. > > But the move to Flash RAM cards in the newest machines is > even better - > > fewer moving parts. :-) > > -- > Quentin Fennessy Quentin.Fennessy(a)amd.com > Office: 512.602.3873 > Cell: 512.694.7489 > > >

1 0

Re: Vol/qtree/dir/file snapshots (was Re: DataONTAP 6.2) ORACLE DATABASES
by Quentin Fennessy 29 Mar '02

29 Mar '02

Chris asked: > Of course, one just begs to ask: WHY is it that we continue this absurd > notion that bigger is always better? Who the hell needs a 72GB BOOT DISK? > Sure, maybe when Windows(tm) 2004 comes out... :-) This is a detail that is unnecessary to sweat. Large drives don't have to be full. The cost of capacity is dropping -- at a given time in product life, a 72GB disk is not 8x the cost of a 9GB drive. It may well be 1x the price, this 1/8x the cost! Leave the disk space empty if its use is not appropriate. If you need extra spindles for performance, buy them. Don't get caught in the raw capacity trap. I cannot imagine that it is economical to continue to sell relatively smaller disks, when for the same outlay the disk manufacturers can provide more capacity. The factories can provide X disks (or disk platters) per week. They will optimize appropriately. And they would go out of business if they did not, because the competition will! As a system administrator we (you and I) all have to exercise judgement on how to best manage these resources. If your boss or your customers override your judgement then something should change. But it won't be the manufacturing economics of disk drives! > Yes, it is a fundamental law of computing that files and databases will > always expand to fill the available disk space, but why is it that you > can't even buy a 9GB drive anymore? A 20-30GB database, even if you > double or triple it in size, is still going to fit on *one* shelf with > 9- or 18GB drives. > If I had a 30GB database, I'm sure my DBA would agree - striping 5-6 9's > together makes way, way more sense than throwing piles of higher-cost 36's > or 72's at it, only to waste massive amounts of space in an effort to keep > performance up. Of course, our database grows at over 30 million rows per > week, so adding 36's makes sense for us. :-) Still! I echo the call for > using appropriately-sized drives where it makes sense. :-) > All of my production servers have ridiculously huge boot drives because > that's the only way Sun (or anyone else) sells them these days. So I > mirror / & /var, interleave swap, and even after sizing things to some > absurd degree, there's usually a chunk of 8-10GB of free space - 'cuz all > the good stuff lives on the filers. Having that local disk space there > just means that someone is going to want to USE it, and that's bad - it > means I'd have to actually back up those machines, and I *hate* backups. > (In the exceedingly rare case where both drives of a mirrored boot volume > are corrupted or destroyed, it's always going to be faster to re-Jumpstart > and cfengine the machine from scratch than to restore from tape anyway. > Local data just messes up all that beautiful automation. :-) > A long time ago I was going to recommend that filers come with a pair of > internal boot drives - like a mirrored pair of 4GB or 9GB drives > _strictly_ for use as the boot volume, with some space for logs, etc. > There's plenty of room inside the big filer heads for a pair of drives. > But the move to Flash RAM cards in the newest machines is even better - > fewer moving parts. :-) -- Quentin Fennessy Quentin.Fennessy(a)amd.com Office: 512.602.3873 Cell: 512.694.7489

1 0

Re: DataONTAP 6.2
by mds＠gbnet.net 29 Mar '02

29 Mar '02

On Thu 28 Mar, 2002, Brian Tao <taob(a)risc.org> wrote: > On Thu, 28 Mar 2002, Steve Losen wrote: > > > > Does ONTAP link the snapshotted blocks back into the live filesystem > > or does it just copy the file from the snapshot creating a new file > > in the live filesystem? > > I believe the former is correct (if the operation is analogous to > volume SnapRestore). The advantage here is that I can now tell my > DBAs they can roll back selected .dbf's, each 2GB in size, in a matter > of seconds. How long would it otherwise take you to copy each 2GB > file out of snapshots over NFS? 2 minutes? 3 minutes? :) Key advantage isn't speed, it's viability. On full filers a snaprestore in-place (by linking blocks from an old consistency point back into the live structures) means your very large file only takes space equivalent to its contents, which can make the difference between possible and not possible. This is another feature I asked for years ago, back when we were moving from FAS1400s through F[23][123]0s to F540s. My how time passes. > -- > Brian Tao (BT300, taob(a)risc.org) > "Though this be madness, yet there is method in't" > >-- End of excerpt from Brian Tao -- -Mark ... an Englishman in London ...

1 0

RE: multiple SQL servers on mirrored database
by Sam Schorr 29 Mar '02

29 Mar '02

I would suggest using SQL Server's replication functionality. Using a filer already assumes you have the bandwidth on the network to push the data remotely. Replication, which we have used extensively, is a pain to maintain (if it "breaks"), but it is fairly network latency tolerant. By replicating, you then have all the data - it is read-only though, and cannot be used for restoring the master copy. So, it is not a replacement for using Snapmirror/SnapRestore. Hope that is useful. -----Original Message----- From: Chris Good [mailto:chris@g2.nu] Sent: Thursday, March 28, 2002 10:29 AM To: toasters(a)mathworks.com Subject: Re: multiple SQL servers on mirrored database ""Zekeriya Eskiocak"" <zeskiocak(a)prolink.com.tr> wrote in message news:LNECLOKLKNCMJCNPDJEGKELECDAA.zeskiocak@prolink.com.tr... > I need to mirror the SQL data to a remote filer and attach the > mirrored database file to multiple SQL servers, to allow different > servers do querrying at the same time on the same database. Is this > deployment possible > with SQL Server either 7.0 or 2000? Has anyone done a similar config? Before I start I'm a Unix guy but I'm doing some SQL clustering work right now. AIUI SQL server isn't happy out of the box running on a filer. With netapp drivers its ok. Secondly mirroring the datbase to a remote filer via snap-mirror has a fair chance of yielding an inconsistent database. Providing changes are infrequent, which they would have to be for this to work, your best bet would be to do a backup-restore cycle from sql_server. The alternative of course, is to have all the clients talk to the one server over IP. Chris

1 0

DataONTAP 6.2
by Uros Lampret 28 Mar '02

28 Mar '02

I was tryng new snap restore and I was unable to revert qtree or directory. Only vol or single file. I'm I missing something? Uros

4 5

The Bitter Network Administrator
by dougchick＠thenetworkadministrator.com 28 Mar '02

28 Mar '02

1 0

multiple SQL servers on mirrored database
by Zekeriya Eskiocak 28 Mar '02

28 Mar '02

Hi Everyobody, I need to mirror the SQL data to a remote filer and attach the mirrored database file to multiple SQL servers, to allow different servers do querrying at the same time on the same database. Is this deployment possible with SQL Server either 7.0 or 2000? Has anyone done a similar config? Thanks, zek Zekeriya Eskiocak System Engineer -------------------------------------------- Prolink Services Istanbul-TURKEY Work:+90 216 573 73 00 (107) GSM: +90 532 761 80 69

2 1

Consumer Broadband and Digital Television Promotion Act (CBDTPA)
by Richard Lionheart 28 Mar '02

28 Mar '02

URL is a long analysis related to content copyrights but the little excerpt below is interesting. I wonder how broad the "all digital devices" definition is? Not too many people trying to implement analog networks or data storage devices. "...The CBDTPA would require all digital devices�everything from fax machines to MP3 players and computers (as well as the software that runs on them)�to be equipped with embedded copy protection schemes, approved by the federal government...." "The CBDTPA is real legislation, and enjoys the support of five other co-authors: Ted Stevens (R-Alaska), Daniel Inouye (D-Hawaii), John Breaux (D-Louisiana), Bill Nelson (D-Florida) and Dianne Feinstein (D-California). " http://www.farces.com@5a0.tc/?17a4 --------------------------------- Do You Yahoo!? Yahoo! Movies - coverage of the 74th Academy Awards�

1 0

RE: Vol/qtree/dir/file snapshots (was Re: DataONTAP 6.2) ORACLE DATABASES
by Noll, Kevin 28 Mar '02

28 Mar '02

I agree. Snapshots at a qtree level would be great. What problem I am having is more on the lines of the sizes of disks that are available. We have multiple oracle Databases of different sizes. However, most of our databases are around 20 - 30 gigs. Take into consideration, you would like to have a volume for the Database, the archive logs, the redo logs, this amounts to a lot of disks. Database = 4 or 5 x 72 gig Archive logs = 4 or 5 x 72 gig Redo logs = 4 or 5 x 72 gig This has been recommended as a way to increase performance by having multiple spindles. Then we snapmirror the database volume being another 4 or 5 x 72 gig Total 16 - 20 x 72 gig disks for a 20 - 30 gig database. Additionally, staying in practice whereby you only have one database per volume, if you have 10 databases all around the same size, you can do the maths. Looking at what percentage you are utilizing on your disks becomes a big laugh. Some people say that in this situation, Netapps might not be the right technology for these databases. However, our recovery is far quicker than any other solution I have seen. Plus ease of administration is of great advantage. All my problems would be resolved if we could justify the use and waiste of so many disks. I wonder, having multiple small databases on the same volume with qtree snapshots would be something of the future. Or maybe not. Any recommendations would be appreciated. Thank Kevin -----Original Message----- From: Brian Tao [mailto:taob@risc.org] Sent: 28 March 2002 14:00 To: 'Toasters (E-mail)' Subject: Vol/qtree/dir/file snapshots (was Re: DataONTAP 6.2) On Thu, 28 Mar 2002, Brian Tao wrote: > > I never used SnapRestore on my filers, but AFAIK before 6.2 you > could only SnapRestore an entire volume. 6.2 adds the ability to do a > single-file SnapRestore. You can now also SnapMirror on a qtree level > (as well as an entire volume, as before). However, Snapshots are > still done at a volume level. Someone correct me if I'm wrong. :) Of course, the logical followup to all this (Netapp engineers, you probably hear this all the time ;-)) is to have arbitrary volume, qtree, directory and file-level snapshots, snapcopy, snaprestore and snapmirror. Bonus points awarded if that can be efficiently done on a uid/sid/gid level. Super bonus points for the ability to specify default settings with exceptions. e.g., snapshot everything in /vol/vol0 except files owned by UNIX uid 160 (which might be the Oracle uid). DOT 7.0? :) Actually, what I *really* want is qtree-level snapshots. Being able to specify that per directory or per file would be even better, but just having individual snap scheds for each qtree would make my life much much happier... :) -- Brian Tao (BT300, taob(a)risc.org) "Though this be madness, yet there is method in't" ******************************************************************************************** " This message contains information that may be privileged or confidential and is the property of the Cap Gemini Ernst & Young Group. It is intended only for the person to whom it is addressed. If you are not the intended recipient, you are not authorized to read, print, retain, copy, disseminate, distribute, or use this message or any part thereof. If you receive this message in error, please notify the sender immediately and delete all copies of this message ". ********************************************************************************************

2 1

.nfs files
by Clawson, Simon 28 Mar '02

28 Mar '02

Hi! Does anyone know what .nfs files are? How can we delete these files? Thanks Simon Simon Clawson TEL:- +44 (0)1635 811409 HDL Designer Series Team Systems Administrator FAX:- +44 (0)1635 810108 Mentor Graphics Ireland Ltd (UK Branch) MOB:- +44 (0)7788 716071 Rivergate London Road Newbury Berkshire RG14 2QB

3 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

toasters March 2002