Database architecture – MS SQL 2000 and SAP R/3 4.6C

pts.
Tags:
Basis
SQL
I am upgrading the disk arrays on my production server over the Christmas holiday, and would love to hear some opinions on how you would recommend partitioning the new array. Currently, I have four disk arrays on the production server, divided into four drive letters (and hence four database files) for a total database size of approximately 305 GB. Tentatively, I am thinking of making the new array one single drive letter (this would be approximately 870 GB) and locating the four database files on that volume, allowing only the fourth file to grow as required. Your thoughts and opinions on this configuration would be appreciated. Thank you! Sylv

Answer Wiki

Thanks. We'll let you know when a new response is added.

Are these disks part of some sort of RAID setup? It doesn’t sound like it is, in which case striping the drives would, if one of the drives failed, result in the loss of all files on the drives…that’s a pretty risky strategy in any environment, whether development or production. You might want to read up on RAID configurations before deciding how you want to reconfigure your drives.

Discuss This Question: 5  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • SylvJumaga
    I'm sorry that I wasn't clearer in my original message. All four of the original arrays are RAID 5. The new array I am installing will also be RAID 5. I would never consider running a production SAP database on volumes that didn't have redundancy! The RAID 5 has saved my behind more than once. :-) Sylv
    0 pointsBadges:
    report
  • Jolora
    I agree with the last post. Security and Data integrity need to be your first concerns. Also, it seems a little late to be asking/thinking about this now. Better late than never, but...
    0 pointsBadges:
    report
  • SylvJumaga
    Please rest assured that data integrity has been taken care of. My question remains - What, in your opinion, would be the optimal way to set up the database on the new blank array?
    0 pointsBadges:
    report
  • JodyIV
    If the four arrays are of equal size and the existing files will each fit on one of the four arrays, put one file on each array either use drive letters or mountpoints. I would recommend against making the array appear as one drive. If you let one file grow too large, what will happen when its time to upgrade again? You will be looking to move a very large file and would be forced to continue building large drive arrays to keep up with one file. I work with several 1TB plus SQL databases and handle the sizes by creating only 100GB mountpoints and placing 1 file on each mountpoint. We use mountpoints to keep from running out of drive letters. Each 100GB drive gets mounted to its own folder, such as E:Data1, E:Data2. This will also allow SQL to perform better by spreading IO over serveral drives and files, instead of just endloading one file.
    0 pointsBadges:
    report
  • SylvJumaga
    Thank you very much, JodyIV, that is exactly the sort of input I was looking for! Sylv
    0 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following