Hi Charles,

Your DBA doesn't understand what qtrees are about. Not his fault, he's probably used to working with block I/O storage.

A tree quota applied to a qtree will incur the same performance hit regardless of the state of the qtree "capacity". i.e. every write will require a hash table comparison, which may cause it to respond with a "disk full" if the quota limit is reached, or an alteration (usually an increment) to the hash table if the write is completed successfully. One of the NetApp guys can provide a more accurate technical description, but that's the general idea. You can resize the tree quota both ways in front of the DBA to help him understand that tree quotas have nothing to do with the layout of data on the disks. (i.e. increase the tree quota so the qtree is only 40% full, run a DB test, shrink the tree quota so it's 99% full then run the same test).

However, he is correct of course that there will be a performance impact when the parent VOLUME is nearly full.

-----Original Message----- From: Charles Bartels [mailto:cbartels@openharbor.com] Sent: Friday, 22 August 2003 3:03 AM To: toasters@mathworks.com Subject: full qtree performance hit?

Hi,

We're running a test oracle DB connected to a netapp filer.

Our DBA is convinced that when the qtrees are close to full (>90%) the performance goes down despite the fact that the parent volume is only 50% full.

Does this make sense or is it more likely the apparently slowdown is coming from somewhere else?

-C.

**** ASI Solutions Disclaimer **** The material transmitted may contain confidential and/or privileged material and is intended only for the addressee. If you receive this in error, please notify the sender and destroy any copies of the material immediately. ASI will protect your Privacy according to the 10 Privacy Principles outlined under the new Privacy Act, Dec 2001.

This email is also subject to copyright. Any use of or reliance upon this material by persons or entities other than the addressee is prohibited.

E-mails may be interfered with, may contain computer viruses or other defects. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments. **** END OF MESSAGE ****