Sb -- Problem depends on different kinds as to what we are trying to solve.
The numbers just provide with IO that being currently being performed and doesn't solve any problem as per question raised by user if i understand it correct, Correct me if i took it in wrong sense.
I am not guru in here but if you can be more precise as to what you are looking for then i can see if i can answer it.
+"My aim is to supervise "I/O" performance from the database( not from OS tools) and alerting when the degradation ( = speed of IO) occurs."+
I/O should be something that your system administrators will be able to monitor. You can monitor what affect slow I/O has on your database, but, very likely, you'll be seeing symptoms and not the cause, unless you're absolutely burying the system with lots of heavy, parallelized, I/O-intensive work.
You might not even be reading/writing from the disk - you might be doing so from the memory caches.
OEM Grid Control is precisely the tool you're after. If you use ASM, it even gives you average response times of your ASM datafiles - you can even monitor it in real-time or historically. It's so easy, my senior management tend to look at it and try and catch me out with stuff they notice before me ;)
Oracle have often told me '20ms average response good, 200ms average response bad'.
I think you're looking at this from the wrong side. The waits you're seeing aren't necessarily bad (depending on your timeframe) that I can tell. Where's the indication that the database is causing the I/O?
If you're seeing a lot of 'db file sequential reads', this indicates you're using indexes, so that's fine (probably)
I don't think I saw your configuration details either. Which version of the database are you using, on which operating system, are you using ASM/Grid Infrastructure and where are your disks (SAN?)