Root DBspace confusion 
Author Message
 Root DBspace confusion

Hi all,

        A bit of confusion upon reading the Administrator's Guide prior to
installing IDS 9.2.  (After reading the following I went back to the 7.3
manual and found the same passage)

In Chapter 14 (Data Storage):
     If you plan to move the physical and logical logs, the initial
     configuration for the root dbspace might differ markedly from
     the final configuration. You can resize the root dbspace after
     you remove the physical and logical logs.  However, the root
     dbspace must be large enough for the minimum size configuration
     during disk initialization.

(on page 14-46 in 9.2, 14-32 in 7.3)

Am I mistaken, or is this totally wrong?  Doesn't resizing the root dbspace
entail reinitializing the Database, thus wiping out all data (logspaces
included)?  I figure you can *add* to the root dbspace easily enough, but
the context of this passage (and my necessity, thus my curiousity) relates
to *shrinking* the root dbspace size.

Thanks for any info,
Michael Hoffman



Wed, 18 Jun 1902 08:00:00 GMT
 Root DBspace confusion

Quote:

> Hi all,

>         A bit of confusion upon reading the Administrator's Guide prior to
> installing IDS 9.2.  (After reading the following I went back to the 7.3
> manual and found the same passage)

> In Chapter 14 (Data Storage):
>      If you plan to move the physical and logical logs, the initial
>      configuration for the root dbspace might differ markedly from
>      the final configuration. You can resize the root dbspace after
>      you remove the physical and logical logs.  However, the root
>      dbspace must be large enough for the minimum size configuration
>      during disk initialization.

> (on page 14-46 in 9.2, 14-32 in 7.3)

> Am I mistaken, or is this totally wrong?  Doesn't resizing the root dbspace
> entail reinitializing the Database, thus wiping out all data (logspaces
> included)?  I figure you can *add* to the root dbspace easily enough, but
> the context of this passage (and my necessity, thus my curiousity) relates
> to *shrinking* the root dbspace size.

Mmmm, I would say you have a valid point there. It does look like it's
implying that you can reduce the size after you move your logs out. As
you rightly state, you cannot resize the 1st chunk of the rootdbs.

Cheers,
--
Mark.

+----------------------------------------------------------+-----------+

| http://www.informix.com  http://www.informixhandbook.com |/////  / //|
| http://www.iiug.org  +-----------------------------------+////  / ///|
|                      |This email will self-destruct in   |///  / ////|
|                      |10 sec. If you received this email |//  / /////|
|                      |in error, sorry about the mess.    |/  ////////|
+----------------------+-----------------------------------+-----------+



Wed, 18 Jun 1902 08:00:00 GMT
 Root DBspace confusion

Hi Michael and Mark,

Yes, this paragraph does not address what to do when you resize the
root dbspace after you've already defined your dbspaces, chunks, etc.
This section addresses sizing estimates BEFORE you start the
database server the first time.  We recommend elsewhere that the
physical and logical logs should be in separate dbspaces from the
root dbspace for better performance, and I think this paragraph was
alluding to that recommendation for the initial sizing.

We will clarify this section in the next version of the Administrator's
Guide to indicate the following:

  - this estimate is the initial root dbspace size prior initializing
    the database server the first time

  - the initial size of the root dbspace depends on whether or not you
    plan to store other physical and logical units of storage (such as
    logs or temp tables) there. If you're expecting a lot of update
    activity, you might want to start with the logs in separate dbspaces
    from the root.

  - if you want to move the logs out of the root dbspace after the
    database server has been running for a while, use the procedure
    in "Moving a Logical-Log File to Another Dbspace" [in chapter 20
    of 9.2 Admin Guide].

Thanks for the feedback!
{*filter*}ia Panlasigui
Principal Tech Writer


Quote:

>> Hi all,

>>         A bit of confusion upon reading the Administrator's Guide prior to
>> installing IDS 9.2.  (After reading the following I went back to the 7.3
>> manual and found the same passage)

>> In Chapter 14 (Data Storage):
>>      If you plan to move the physical and logical logs, the initial
>>      configuration for the root dbspace might differ markedly from
>>      the final configuration. You can resize the root dbspace after
>>      you remove the physical and logical logs.  However, the root
>>      dbspace must be large enough for the minimum size configuration
>>      during disk initialization.

>> (on page 14-46 in 9.2, 14-32 in 7.3)

>> Am I mistaken, or is this totally wrong?  Doesn't resizing the root dbspace
>> entail reinitializing the Database, thus wiping out all data (logspaces
>> included)?  I figure you can *add* to the root dbspace easily enough, but
>> the context of this passage (and my necessity, thus my curiousity) relates
>> to *shrinking* the root dbspace size.

>Mmmm, I would say you have a valid point there. It does look like it's
>implying that you can reduce the size after you move your logs out. As
>you rightly state, you cannot resize the 1st chunk of the rootdbs.

>Cheers,
>--
>Mark.

>+----------------------------------------------------------+-----------+

>| http://www.***.com/   http://www.***.com/ |/////  / //|
>| http://www.***.com/  +-----------------------------------+////  / ///|
>|                      |This email will self-destruct in   |///  / ////|
>|                      |10 sec. If you received this email |//  / /////|
>|                      |in error, sorry about the mess.    |/  ////////|
>+----------------------+-----------------------------------+-----------+



Wed, 18 Jun 1902 08:00:00 GMT
 Root DBspace confusion

Quote:

> Hi Michael and Mark,

> Yes, this paragraph does not address what to do when you resize the
> root dbspace after you've already defined your dbspaces, chunks, etc.
> This section addresses sizing estimates BEFORE you start the
> database server the first time.  We recommend elsewhere that the
> physical and logical logs should be in separate dbspaces from the
> root dbspace for better performance, and I think this paragraph was
> alluding to that recommendation for the initial sizing.

Maybe we shuld just make the whole thing clear and stop saying "RESIZE the
root dbspace".  I understand that you can *add* space and then drop those
chunks, but the passage in question is specifically dealing with the
original size estimates and the fact that after moving the logs out of the
root, your root will have extra space it doesn't need.  At that point it
mentions the ability to resize the space.... clearly meaning to make it
smaller and reclaim that "wasted" space.

Quote:

> We will clarify this section in the next version of the Administrator's
> Guide to indicate the following:

>   - this estimate is the initial root dbspace size prior initializing
>     the database server the first time

Ok.. that looks right.

Quote:

>   - the initial size of the root dbspace depends on whether or not you
>     plan to store other physical and logical units of storage (such as
>     logs or temp tables) there. If you're expecting a lot of update
>     activity, you might want to start with the logs in separate dbspaces
>     from the root.

Now, hold on.  The original "oninit -i", or 'onmonitor' depending on your
preference, initialization will create the Logical Logs and the Physical Log
in root dbspace automatically.  There is *NO* way around this!  You cannot
"start with the logs in separate dbspaces from the root".  Totally impossible.

What you might want to say, though, is to use as minimal a log size as possible
(I believe 1000K) and as minimal a number (3 logical).  Once initalization is
complete, create new dbspaces, move and resize the logfiles, and drop the logs
from the root dbspace.  This will keep rootdb at a minimal size.

Michael Hoffman



Wed, 18 Jun 1902 08:00:00 GMT
 Root DBspace confusion

Mark,

I like your suggested clarifications for this paragraph -- to
not say "resize", but instead say "use a minimal log size
when you first initialize the database server", and then do
all the steps to move and resize the logs after initialization
to keep the root dbspace small.
We are currently updating this paragraph and will
incorporate your suggestions.

Thanks!
{*filter*}ia


Quote:

>> Hi Michael and Mark,

>> Yes, this paragraph does not address what to do when you resize the
>> root dbspace after you've already defined your dbspaces, chunks, etc.
>> This section addresses sizing estimates BEFORE you start the
>> database server the first time.  We recommend elsewhere that the
>> physical and logical logs should be in separate dbspaces from the
>> root dbspace for better performance, and I think this paragraph was
>> alluding to that recommendation for the initial sizing.

>Maybe we shuld just make the whole thing clear and stop saying "RESIZE the
>root dbspace".  I understand that you can *add* space and then drop those
>chunks, but the passage in question is specifically dealing with the
>original size estimates and the fact that after moving the logs out of the
>root, your root will have extra space it doesn't need.  At that point it
>mentions the ability to resize the space.... clearly meaning to make it
>smaller and reclaim that "wasted" space.

>> We will clarify this section in the next version of the Administrator's
>> Guide to indicate the following:

>>   - this estimate is the initial root dbspace size prior initializing
>>     the database server the first time

>Ok.. that looks right.

>>   - the initial size of the root dbspace depends on whether or not you
>>     plan to store other physical and logical units of storage (such as
>>     logs or temp tables) there. If you're expecting a lot of update
>>     activity, you might want to start with the logs in separate dbspaces
>>     from the root.

>Now, hold on.  The original "oninit -i", or 'onmonitor' depending on your
>preference, initialization will create the Logical Logs and the Physical Log
>in root dbspace automatically.  There is *NO* way around this!  You cannot
>"start with the logs in separate dbspaces from the root".  Totally
impossible.

>What you might want to say, though, is to use as minimal a log size as
possible
>(I believe 1000K) and as minimal a number (3 logical).  Once initalization is
>complete, create new dbspaces, move and resize the logfiles, and drop the
logs
>from the root dbspace.  This will keep rootdb at a minimal size.

>Michael Hoffman



Wed, 18 Jun 1902 08:00:00 GMT
 
 [ 5 post ] 

 Relevant Pages 

1. Restructuring root dbspace.

2. root dbspace

3. How do I initialize the root dbspace?

4. temp tables in root dbspace despite DBSPACETEMP setting

5. Change the chunks name in root dbspace

6. root dbspace chunk offline how recover ?

7. changing root dbspace size

8. ontape -r -D dbspace leaves inconsistent dbspace/chunk...

9. ontape -r -D dbspace leaves inconsistent dbspace/chunk...

10. root dbspace full. Question?. Informix 5.00 UC3

11. DBSPACE shows different amount used for root and dbs0?

12. Wrapping <root> </root> around query results


 
Powered by phpBB® Forum Software