Originally posted by V6163

1) In this case of tablespaces it can come to 60-70 in number. Will there be any
problem in having these many tablespaces in cases like maintenance and backups.
This might be a little overkill for one controller and all your disks in a RAID5 configuration. However, your plan will carry you into the future if you get more disks and controllers.


2) Till now i didn't plan for a backup strategy. And also please let us know
how we should proceed for backup strategy also.

How you implement your backup is dependant on your Mean Time To Recovery (MTTR). If your MTTR is short, you want frequent backups. If your MTTR is long, you can get by with longer intervals between backups.

If this is production, put your database in archivelog mode.

After you have your backup working, test, test, test the recovery.

Don't rely on imp/exp as your sole method of recovery.


3) We are planning to have a datafile of 1GB size, for easy maintenance at
Operating System level. Please comment on this.
This is fine. On a big database, I limit my datafiles to 2G, but 1G is fine.

4) As my server has only one disk controller, can I place all my indexes and data tablespaces together in one disk. I am asking this because documents says RBS tablespace should be away from data tablespace, redo log files should be
away from data tablespaces and etc... Will this hold good when there is one disk controller.
You single point of failure will be your disk controller. If you have a good number of disks, you may want to consider splitting them up into a combination of RAID5, RAID 0 and RAID 0+1 and split your data accordingly. This way, when you get another disk controller you are already set to take advantage of it.