Defragment SAN disks -- Good or bad?

I think defrag at the SAN / filesystem level is doing it in the wrong place. I've always felt that way.

I have only worked with EMC and Netapp, and the Netapp work was very brief. I had more in-depth experience with EMC and EMC engineers used to chide us at IBM to let the cache do the work and not worry about hot-spots until they happened. It turned out to be good advice, mostly. I never once remember having to actually defrag anything on an EMC SAN, but we did _rarely_ move a LUN due to a hot-spot. (ie. multiple slices on a physical disk were contending, so we'd move one slice to a different spindle) but this is different than defrag. I just bring it up because its the only maintenance on an EMC I was ever involved in. Defrag is SAN/filesystem dependant. What are you using? I assume you are not using ASM, based on the fact that your SA has setup a defrag process, so what are the specifics? Cooked filesystem, LVM?

You might point out to your SA that filesystem fragmentation and tablespace level fragmentation are totally different things. In Oracle the most critical fragmentation is segment level fragmentation. Defragmentation of a SAN volume does not imply defragmentation of Oracle segments. As we know, intra-tablespace object fragmentation that can be completely different than the filesystem, based on growth of multiple object segments causing interleaving. The OS is blind to this. This is why I pre-allocate most of my tablespaces, avoid using auto-extend features, and then take care of fragmentation maintenance at the Oracle extent level. The OS /SAN is handicapped in that it cannot see into the Oracle tablespace so I don't want it involved in the first place.

Historically, with the EMC systems I've been involved with, defragging is not done, period. As I said, we did monitor for hot-spots are, and periodically migrated a LUN.

With filesystems and storage, I prefer reactive approach vs. compulsively preemptive. Too many cooks in the kitchen can cause trouble. Your SA might have his SAN defrag running while your index defrags are running or your backups are running. That could result in a disasterous tax on the IO, all for maintenance tasks.

I place it in the realm of optimization. Don't do it until its observably necessary, then do it at the most productive layers. That is Oracle, first, filesystem second.

ASM should be a consideration, that gets the SA out of the kitchen altogether. :)

At least the EVA isn't thinly provisioned so a defrag won't suddenly cause thin volumes to become fat. You might have multiple LUNs on one disk group though in which case defrag will cause unnecessary I/Os which will slow down the other LUNs.