Results 1 to 7 of 7
  1. #1
    Join Date
    Dec 2003
    Posts
    4

    Unanswered: 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.

  2. #2
    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

    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.

  3. #3
    Join Date
    Dec 2003
    Posts
    4

    Re: Recommended Filesystem Layout

    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.

  4. #4
    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

  5. #5
    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

    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

  6. #6
    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.

  7. #7
    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

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •