Subscribe

due to WAFL ,we write data fastter,on the other hand ,it could led to a database table become discontinous,and read the table become slowly.did you have solution for this ? thanks!

due to WAFL ,we write data fastter,on the other hand ,it could led to a database table become discontinous,and read the table become slowly.did you have solution for this ? thanks!

Re: due to WAFL ,we write data fastter,on the other hand ,it could led to a database table become discontinous,and read the table become slowly.did you have solution for this ? thanks!

Your question is a little difficult to understand, but depending on whether you are using NFS or a LUN via FC/iSCSI, it can be more or less of a problem. I've never had a problem with NFS based Oracle filesystems, but that doesn't mean it can't happen.

Basically, these topics are covered in the system administration guides.

For LUN based storage, "fragmentation" can be routinely measured and "de-fragmented" with the 'reallocate' command and is a recommended practices.  It can be used on other volumes as well.

Re: due to WAFL ,we write data fastter,on the other hand ,it could led to a database table become discontinous,and read the table become slowly.did you have solution for this ? thanks!

I don't especially see why it would be inherently more of a problem for a LUN than it would be if the database was files over NFS. Ultimately a LUN is a file which is shared over a block protocol rather than over a file protocol, the only differences with a LUN relate to whatever the host's filesystem does to the data being stored within it and how the host does its own caching etc. The best practice requirement for reallocate still applies.

That aside, things aren't as a bad as they otherwise might be since ONTAP optimizes read access on temporal lines using readsets. Great article here :

http://storagewithoutborders.com/2010/07/19/data-storage-for-vdi-part-6-data-ontap-improving-read-performance/