If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

 
Go Back  dBforums > Database Server Software > DB2 > Recommended Filesystem Layout

Reply
 
LinkBack Thread Tools Search this Thread Display Modes
  #1 (permalink)  
Old 12-12-03, 11:31
bkretch bkretch is offline
Registered User
 
Join Date: Dec 2003
Posts: 4
Recommended Filesystem Layout

Does anyone have suggestions on how to lay out the filesystems in UNIX for DB2 in a large OLTP environment? We are going to have the following:

/db2home - home filesystem for all instances
/db2log_p - filesystem for primary logs
/db2log_s - filesystem for mirrored logs

Any other suggestions from experience? As filesystems can get corrupted, we are separating them out for reliability, and not performance reasons. The filesystems are all located on a SAN.

Thanks for the help.
Reply With Quote
  #2 (permalink)  
Old 12-12-03, 11:53
jsander jsander is offline
Registered User
 
Join Date: Apr 2003
Posts: 191
Re: Recommended Filesystem Layout

Hi,

add

/db2dbcfg/db2instx/dbnamey

and create your dbs on /db2dbcfg.

Instead of a general /db2home for all instances, I recommend a database specific filesystem

/db2home/db2instx/dbnamey

for each of your databases. Same with logs.

Also, you may want to consider if separating each database's temp space would make sense.

Johann

Quote:
Originally posted by bkretch
Does anyone have suggestions on how to lay out the filesystems in UNIX for DB2 in a large OLTP environment? We are going to have the following:

/db2home - home filesystem for all instances
/db2log_p - filesystem for primary logs
/db2log_s - filesystem for mirrored logs

Any other suggestions from experience? As filesystems can get corrupted, we are separating them out for reliability, and not performance reasons. The filesystems are all located on a SAN.

Thanks for the help.
Reply With Quote
  #3 (permalink)  
Old 12-16-03, 22:18
bkretch bkretch is offline
Registered User
 
Join Date: Dec 2003
Posts: 4
Re: Recommended Filesystem Layout

Quote:
Originally posted by jsander
Hi,

add

/db2dbcfg/db2instx/dbnamey

and create your dbs on /db2dbcfg.

Instead of a general /db2home for all instances, I recommend a database specific filesystem

/db2home/db2instx/dbnamey

for each of your databases. Same with logs.

Also, you may want to consider if separating each database's temp space would make sense.

Johann
Thanks!! This is exactly how I am doing it. Just curious - what is the rationale for separating temp space? Thanks.
Reply With Quote
  #4 (permalink)  
Old 12-17-03, 05:48
nitingm nitingm is offline
Registered User
 
Join Date: Jul 2003
Location: Austin, TX, USA
Posts: 278
Rationale

Hi,

One of the rationale for seperating TempSpace is that it avoids sorts and all temperoary operations in the same area.

Hence it improves performance to a good degree.

HTH

Nitin
Reply With Quote
  #5 (permalink)  
Old 12-17-03, 10:46
jsander jsander is offline
Registered User
 
Join Date: Apr 2003
Posts: 191
Re: Rationale

Hi,

another point is it becomes easier to tell why your filesystems or containers are getting full. If it is the temp space, it is probably enough to force an application, if it is data, you need to enlarge containers.

Johann

Quote:
Originally posted by nitingm
Hi,

One of the rationale for seperating TempSpace is that it avoids sorts and all temperoary operations in the same area.

Hence it improves performance to a good degree.

HTH

Nitin
Reply With Quote
  #6 (permalink)  
Old 12-17-03, 23:48
bkretch bkretch is offline
Registered User
 
Join Date: Dec 2003
Posts: 4
When I first read your response, I thought that when you said to separate out the "temp" space, I thought that you meant the /tmp operating system temp space. What you are really saying is to have a filesystem hold the userspace tablespaces for the database tables, and another filesystem hold the temporary tablespaces for the temporary tables (when they grow due to sort overflows, etc.). This makes sense in the case of separate disks. Does it buy me anything when I have a SAN on the back end and I am just allocating disk (from the same virtual pool of disk) for these tablespaces? If the tablespaces were on different RAID drives, I can see how the performance would improve. If the RAID drives were the same, I would not expect any improvement in performance. What are your thoughts. Thanks again.
Reply With Quote
  #7 (permalink)  
Old 12-18-03, 06:43
jsander jsander is offline
Registered User
 
Join Date: Apr 2003
Posts: 191
Hi,

when your disks are represented by SAN, it is probably not so much a question about performance, but it is still a question about managability and ease of monitoring.

Johann

Quote:
Originally posted by bkretch
When I first read your response, I thought that when you said to separate out the "temp" space, I thought that you meant the /tmp operating system temp space. What you are really saying is to have a filesystem hold the userspace tablespaces for the database tables, and another filesystem hold the temporary tablespaces for the temporary tables (when they grow due to sort overflows, etc.). This makes sense in the case of separate disks. Does it buy me anything when I have a SAN on the back end and I am just allocating disk (from the same virtual pool of disk) for these tablespaces? If the tablespaces were on different RAID drives, I can see how the performance would improve. If the RAID drives were the same, I would not expect any improvement in performance. What are your thoughts. Thanks again.
Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On