Multiple db parts on same physical disc. Any problems?

pdj
pdj Member Posts: 643
edited 2005-03-14 in NAV/Navision Classic Client
I have two physicals discs (forget about raid and so on) but my database is in 6 parts. Do I get any performance increase by making a new database in only two parts, or is it just a waste of time?

If it just is a waste of time (which I think and hope) should they then be placed 1+3+5 and 2+4+6 or 1+2+3 and 4+5+6?

The reason is that some of our customers are chaning to servers with fewer discs...
Regards
Peter

Comments

  • Kowa
    Kowa Member Posts: 926
    Simple rule : only one database container ( fdb.file) for each physical disc.
    More than one will always impair the performance, since there is only one write/read head and one controller to do the job.
    Kai Kowalewski
  • pdj
    pdj Member Posts: 643
    So you say it is worth the time (i.e. being offline for 24+ hours and paying a consultant (me :-)) for a few hours work) to reduce the number of database parts. What is your source or have you made some tests?
    Regards
    Peter
  • Ian_piddignton
    Ian_piddignton Member Posts: 92
    I agree wioth Kowa. The standing rule has always been 1 datapart to a physical disc. There is no way to know which part any given piece of data will be written to so you cannot reasonably group the parts. As one transaction in Navision could easily write to all of the parts you are create a problem as you only have one read/write head avaiable to you. the same is true when reading. If you are going to drop to having 2 disc's for the database parts only have 2 parts. Its an easy enough process to move from 6 parts to 2 parts.

    Many factors aside from the split of the database parts can effect performance. By making the change you will get an increase in performance at the disc access level, traslating this into a noticeable system performance increase is not so easy. I guess the question is are you seeing performace problems? If so its worth doing, if not its upto you or your client.

    How big is the database? All you are really looking at is a back up and restore process so the limiting factor time wise is the size of the database and therefore the time to do the process. Form a consultants point of view there is next to nothing to do. Create the new database with the correct parts and kick off the restore process.
  • Kowa
    Kowa Member Posts: 926
    If the system is working and the customer is satisfied with the performance I would not invest the time. But changing to fewer discs is liable to slow down the system anyway (even if the new discs are faster than the old ones), and using more than one database part on one disc will make it even slower.

    Also, building up a database from a backup is a good way to check the database integrity. You have a combined database check, reduced table size and a new database in 2 parts instead of 6.

    You can read about server performance issues in Chapter 6 of "Installation and System Management" (w1w1ism.pdf)
    Kai Kowalewski

Categories