Page 1 of 3 123 LastLast
Results 1 to 15 of 31

Thread: Table Space

  1. #1
    Join Date
    May 2009
    Posts
    25

    Unanswered: Table Space

    Can someone tell me exactly what are table spaces?

  2. #2
    Join Date
    Jan 2003
    Posts
    4,292
    Provided Answers: 5
    Straight from the DB2 documentation, from the glossary:

    table space
    A logical unit of storage in a database. In DB2 for z/OS, a table space is a page set and can contain one or more tables. In DB2 Database for Linux, UNIX, and Windows, a table space is a collection of containers, and the data, index, long field, and LOB portions of a table can be stored in the same table space or in separate table spaces. See also page set, container.

    Andy

  3. #3
    Join Date
    May 2009
    Posts
    25
    What's the benefit of having table spaces?

  4. #4
    Join Date
    Aug 2008
    Location
    Toronto, Canada
    Posts
    2,367
    so that you can start growing tables

  5. #5
    Join Date
    May 2009
    Posts
    25
    It seems to me that you could grow tables without having table spaces. Here's a definition of table space from the IBM documentation:

    table space
    (1) An abstraction of a collection of containers into which database objects are stored. A table space provides a level of indirection between a database and the tables stored within the database. A table space has space on media storage devices assigned to it. The data, index, long field, and LOB portions of a table can be stored in the same table space, or can be individually broken out into separate table spaces.
    (2) In DB2 Universal Database for z/OS and OS/390, a page set that is used to store the records in one or more tables.

    How does having this abstraction help with growing tables?

  6. #6
    Join Date
    Aug 2008
    Location
    Toronto, Canada
    Posts
    2,367
    show me how you grow tables without having tablespaces.


    Here is another definition of a tablespace:
    A table space is a database object that is used by DB2 to specify the physical
    location of data in a database; it is the layer between the table metadata and the actual container that holds table data. Tables and indexes reside within tablespaces. A table space can contain one or many tables/indexes.

  7. #7
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    This thread reinforces my theory that people with a handle that contains the letters "db2" know almost nothing about DB2. db2girl is an exception, but a large percentage of the totally idiotic posts come from people with "db2' in their handle name.
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  8. #8
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    Quote Originally Posted by db2farmer
    What's the benefit of having table spaces?
    You don't have a choice. All tables must be created in a tablespace. If you don't specify the tablespace when the table is created, then DB2 will pick one for you that was created by default when the database was created (or in the case of DB2 z/OS, when the DB2 sub-system was created).

    If you are using DB2 for i/Series, then God help you.
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  9. #9
    Join Date
    Jan 2007
    Location
    Jena, Germany
    Posts
    2,721
    The only sensible answer here is: RTFM

    And maybe participate in a course that teaches the basics on relational database systems...
    Knut Stolze
    IBM DB2 Analytics Accelerator
    IBM Germany Research & Development

  10. #10
    Join Date
    Jan 2007
    Location
    Jena, Germany
    Posts
    2,721
    The only sensible answer here is: RTFM

    And maybe participate in a course that teaches the basics on relational database systems...
    Knut Stolze
    IBM DB2 Analytics Accelerator
    IBM Germany Research & Development

  11. #11
    Join Date
    May 2009
    Posts
    25
    @stolze & Marcus A: What's the point of posting self-important flame bait?

    @db2girl: In some references table spaces are referred to as physical entities and in some references they are referred to as logical entities. In some refereces they are referred to as both. If a table space really is a logical entity -- an abstraction of other elements such as files -- then those elements exist regardless of the logical association provided by the abstraction. This is why it seemed to me that one should be able to grow tables without a table space -- provided that a table space really is just a logical entity. Since databases, and schemas within databases, already provide logical groupings of tables (and other objects) I wondered what extra value was being added by yet another logical grouping.
    Last edited by db2farmer; 05-15-09 at 20:37.

  12. #12
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    Quote Originally Posted by db2farmer
    @stolze & Marcus A: What's the point of posting self-important flame bait?

    @db2girl: In some references table spaces are referred to as physical entities and in some references they are referred to as logical entities. In some refereces they are referred to as both. If a table space really is a logical entity -- an abstraction of other elements such as files -- then those elements exist regardless of the logical association provided by the abstraction. This is why it seemed to me that one should be able to grow tables without a table space -- provided that a table space really is just a logical entity. Since databases, and schemas within databases, already provide logical groupings of tables (and other objects) I wondered what extra value was being added by yet another logical grouping.
    1. What is the point of asking stupid questions?

    2. The value of an abstraction such as a tablespace is that it can consist of one or more containers (or VSAM files in z/OS), whose specifications are cumbersome to define. Once defined, the tablespace name (instead of the detailed specifications) can be referenced in the create table statement as the place where a table will physically reside. This is useful since a tablespace can hold more than one table.

    3. What is meant by "grow"? You keep asking about growing a table. You need a tablespace to create a table, not just to grow it. I don't know if there is translation problem here, or where you got the terms "grow a table" from, but it makes no sense in the context of your question, so maybe you should elaborate. .

    4. Just about all relational databases that I know have the concept of a tablespace that specifies the physical location of where the table resides, so it is not unique to DB2.

    5. I would suggest you install DB2, and then add a tablespace, then add tables using that tablespace, and you will understand. Or you could read the DB2 manuals.
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  13. #13
    Join Date
    Aug 2008
    Location
    Toronto, Canada
    Posts
    2,367
    "grow" came from me...

    db2 farmer "grows" db2 tables

  14. #14
    Join Date
    May 2003
    Location
    USA
    Posts
    5,737
    Quote Originally Posted by db2girl
    "grow" came from me...

    db2 farmer "grows" db2 tables
    Good, as if this person is not totally confused already...
    M. A. Feldman
    IBM Certified DBA on DB2 for Linux, UNIX, and Windows
    IBM Certified DBA on DB2 for z/OS and OS/390

  15. #15
    Join Date
    May 2009
    Posts
    508
    Provided Answers: 1
    On z/OS Table Spaces are simple and straight forward. They are the physical object that is created on disks (actually VSAM files as Marcus A states). A combination of Database.Tablespace gives a unique name. The table is the logical object contained in this physical space.

    On LUW it is a little more complicated. Containers are the actual physical objects you will see on Disk. You can define a table space to use one or more containers. The Table spaces / Containers contain the logical Tables, indexes, etc. So the abstraction form the table point of view is not having to defined the containers to uses since the Table space takes care of this.

    Now, a theoretical discussion could be made that you could do away with the Table spaces and just have Tables, Indexes, etc and Containers. But, I am guessing that, since z/OS was around a long time before LUW, that the Table Space / Table paradigm was already set and would just introduce some confusion (and complicate the already complicated Universal Database goal).

    But the fact remains that DB2 uses the Table Space / Table structure and, I believe, Containers were added to deal with the different disk storage structures on LUW computers (as compared to z/OS).

Posting Permissions

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