> 1) A "write cache" in the EMC unit may be used (we do not know),
We know for _sure_, trust me. EMC have very strict policy.
You even cannot have a bad configured Symetrix because they
don't allow you. You cannot just request some little cache
and lot of storage space just because they don't want
rummors about EMC not have performance. Ask your EMC support
Quote:> but that again introduces risks unless it has a UPS to ensure
> disk write even after power fail. Being a DBMS developer and
> supporter, I have acquired some scepticism here.
You cannot damage EMC. Even the power fail or goes up/down
randomly, the UPS have capacity for 15 minutes of more, suficiently
for destaging cache on disks and powerdown procedure. I can't
emphasys more: EMC or ESS or any other high performance storange
simply cannot aford such silly things like power failure. They
have redundant power supply and almost all internals are redundant.
ESS "Shark" even have redundant cache!
> 2) A "read cache" will probably not help much when the backup
> reads all the data - the access is once only, not repeated.
Yes, but as say data is splited accross many disks, lets
say 5-6 and on different SCSI buses. This translate to huge
Quote:> For the continued DB operation, I trust that any decent DBMS
> will do better caching (due to its knowledge of page type
> and access pattern) than the EMC cache (which has no such
DBMS have no knwoledge about filesystems internals and even
physical disks. The recomandation is to split database to more
filesystems in the hope these corespond to different physical disks
While we use LVM which hide physical aspect, is up to system
administrator that logical volumes for database indeed reside on
physical different HDDs. This is very important for performance
especially when working with SSAs or SCSI drives.
When come to storages like EMC or ESS, this simply will not make
sense. The storage give you LUNs and it follow own internal
information organization to minimize IO "hot spots".
> 1+2) "Cache" sounds great, but for DB operation one had better
> invest in RAM that the DBMS can administer.
When working with SAN storages which employ large caches,
the AIX disk IO cache affect performance because EMC/ESS over FC
have very low latency and high bandwidth. AIX IO cache just
add another processing layer.
> 3) The fact remains that it is a copy operation within the same
> drives that makes the disk arms alternate between positions.
As I said above this statement is false for EMC or ESS.
> A very good question for which I would like to see an answer.
> By the design principle of RAID 5, any write operation needs to
> access several disks, so its response time must be longer than
> that of a single disk, also AFAIK it may require a previous read
> to compute the new redundancy pattern - the performance must be
> worse than that of a single (similar) disk.
It's very clear that. But the real point is that IO read
bandwidth is very high. But EMC isn't a plain RAID5, but a storage
with big cache. It can afford to delay destaging your IO writes.
You just write to cache and not to disks. The performance
will drop when you fill the cache before it can write all on disk.
Like on a very huge copy. I wonder if RAID5 is not a plain one,
but with chunks accross many disks. For the moment I don't know.
> Whether one accepts that performance loss in order to get a
> fail-safe improvement at moderate costs is a completely different
> issue. IMO, it should only be done for areas where performance
> is not critical.
I can't follow.
> In the DBMS area, you might use it for "data", but do not use it
> for "log" (log write must be synchronous) if you want high
> transaction throughput. If Maj also has the log areas on the
> same RAID 5 disks, the perfrmance breakdown does not surprise me.
Not true as I said above.
> My remark about "any damage to any drive" is more oriented towards
> the fact that this backup onto the same disk spindles does _not_
> give protection against catastrophic disk failures (like double
> faults, ...) or admin errors ("rm -rf ...") - the backup is as
> safe as the original data area. It only protects against (some)
> internal DBMS malfunction, whereas a tape backup does more.
disk faults are different animal from user/program errors.
EMC protect from hardware errors, so here come RAID5 + hotspare.
User, programs errors or disasters are managed by backups.
>> > Setting all that aside: RAID 5 has no good write performance, AFAIK.
>> It's a trade off of safeness and performance. Considering the EMC
>> big cache and also the fact that it use RAID5, then it clear
>> it can _sustain_ easyly >40MB/s (if I'm not wrong)
> I do not know the figures - you may be right. However, depending
> on the area placement this disk-to-disk copy may be a case with
> large seek distances, yielding figures worse than average.
Cache is the solution and that's why is implemented at HDD level
on it's electronics. The more cache your HDD have the more performance
(and of course lot of money :^)
> I readily admit that the real issue may be with hdisk0 & hdisk1,
> I have no idea why there is so much write traffic to them.
I suspect the backup program allocate huge ammount of memory
so it just goes system on trashing.
have a nice day,