re : adding chunks to rootdbs
Faisal Meraj
Hi All:
I am trying to create new dbspace and I get the message ISAM error: no disk
space. Yet I can add
more chunks to existing dbspaces without a problem and can add new dbspaces
from other informix instanes
in the same location without a problem. There is 70 gigs of empty space and
these are cooked files. The only issue
i see is that the rootdbs has filled-up and I thinkthat this might be the
problem. I just added an additional chunk to rootdbs using onspaces -a
rootdbs .........
but it doesn't seem to take affect i.e nothing new inserted in the new
rootdbs chunk. Is there anything else
I ahve to do to make the rootdbs expand.
Thanks in advance.
Faisal
Bernstein, Rick
You can add chunks to rootdbs, just like other dbspaces.
However, certain Informix items must reside in the first rootdbs chunk.
They include pages which track chunks and mirror chunks.
EXT CHUNK RESERVED PAGES
EXT MIRRORED CHUNK RESERVED PAGES
I believe that one workaround to a full 1st chunks is:
1) Drop the sysmaster database
2) Add your new dbspaces and chunks
3) Re-create the sysmaster database.
The sysmaster database does not need to reside in the first rootdbs chunk.
Manuel Daponte
use them.
"Bernstein, Rick" <rber...@alarismed.com> wrote in message
news:9gtpaf$ctt$1...@news.xmission.com...
Andrew Hamm
>You need to do a level 0 backup after adding the chunks, before Informix
can
>use them.
>
pointed out, some structures must reside in the first chunk of rootdbs. His
plan to drop sysmaster however scares the crap out of me. Unless ifx has
dealt with that, I remember that there were warnings not to fiddle with
sysmaster, let alone drop it. If you look into the very interesting script
which builds sysmaster, you'll see that it "fakes up" and messes with a lot
of secret data, and all hell could break loose if you ask it to drop tables
thru the fudged-up links.
But, if you need to make space in the first root chunk, then I suggest
either
1) moving the physlog to another dbspace if it's currently in root
2) Move some or all logical logs to another dbspace (or two - stripe them)
if they are currently in root
3) identify some ordinary tables in rootdbs(chunk1) and move them to another
dbspace, or temporarily export and drop them, then reload after the critical
internal structures in rootdbs(chunk1) have grown.
--
I'd always thought music was too formal, and
I thought "well, I'll get into this and fix it"
- Don Van Vliet
Bernstein, Rick
Andrew,
I agree that the physical log and logical logs should not reside in
rootdbs. Hopefully, most sites move them to different dbspaces when
they initially create a new instance. If the first rootdbs chunk
still fills additional steps are required.
The IDS 9.2 and IDS 9.21 release notes describe a procedure for freeing
up space in the first chunk of rootdbs. See section V.B.5 (Migration for
SAP Customers) in
http://www.informix.com/informix/services/ilink/relnotes/ids2000/921uc43.htm
It involves describes how to drop the sysmaster database, create new
chunks, and then recreate the sysmaster database.
Rick
Andrew Hamm
>
>The IDS 9.2 and IDS 9.21 release notes describe a procedure for freeing
>up space in the first chunk of rootdbs. See section V.B.5 (Migration for
>SAP Customers) in
>http://www.informix.com/informix/services/ilink/relnotes/ids2000/921uc43.ht
m
>It involves describes how to drop the sysmaster database, create new
>chunks, and then recreate the sysmaster database.
>
cleaning up before the drop, but much less than I thought it would need to.
It's not a plain old drop tho, so you have to follow the ritual. I wonder if
it's exactly correct for a 7.XX engine too?
--
I'd always thought music was too formal, and
I thought "well, I'll get into this and fix it"
- Don Van Vliet
.. ... .--. .. - --- -. --- .-. .- -.-. .-.. .
William Rice
I seem to recall pretty clearly you can just drop the sysmaster and
the run the build_smi script to rebuild it without issues. I might be
delusional though. Someone tell me if I am incorrect so I don't put myself
in to bad of a spot.
I think it this is done when you upgrade as well...
Will
P.S. I seem to recall dropping and rebuilding the sysmaster on a system not to
long ago with no issues.
>===== Original Message From "Andrew Hamm" <NOaha...@sanderson.net.au>
=====
>Manuel Daponte wrote in message <9gvl71$eh...@www.na.informix.com>...
>>You need to do a level 0 backup after adding the chunks, before Informix
>can
>>use them.
>>
>NOT TRUE. New chunks are available for use immediately. However, as Rick
>pointed out, some structures must reside in the first chunk of rootdbs. His
>plan to drop sysmaster however scares the crap out of me. Unless ifx has
>dealt with that, I remember that there were warnings not to fiddle with
>sysmaster, let alone drop it. If you look into the very interesting script
>which builds sysmaster, you'll see that it "fakes up" and messes with a lot
>of secret data, and all hell could break loose if you ask it to drop tables
>thru the fudged-up links.
>
>But, if you need to make space in the first root chunk, then I suggest
>either
>
>1) moving the physlog to another dbspace if it's currently in root
>2) Move some or all logical logs to another dbspace (or two - stripe them)
>if they are currently in root
>3) identify some ordinary tables in rootdbs(chunk1) and move them to another
>dbspace, or temporarily export and drop them, then reload after the critical
>internal structures in rootdbs(chunk1) have grown.
>
>--
>I'd always thought music was too formal, and
>I thought "well, I'll get into this and fix it"
> - Don Van Vliet
*************************************************************
- .... .. ... / . -....- -- .- .. .-.. / .... .- ... / -... . . -. /
... . -. - / - --- / -.-- --- ..- / ...- .. .- / ..-. .-. . . /
... . .-. ...- .. -.-. . / ..-. .-. --- -- / --- .--. . .-. .- /
...- .. ... .. - / ..- ... / .- - /
.-- .-- .-- .-.-.- --- .--. . .-. .- .-.-.- -.-. --- --
************************************************************
Mark D. Stock
William Rice wrote:
>
> I seem to recall pretty clearly you can just drop the sysmaster and
> the run the build_smi script to rebuild it without issues. I might be
> delusional though. Someone tell me if I am incorrect so I don't put myself
> in to bad of a spot.
You should be able (not tested it) to run the script
$INFORMIXDIR/etc/buildsmi. Although if you look in that script, it says
that this is unsupported and that the recommended procedure to build SMI
databases is to rerun oninit. I guess that makes more sense as it
ensures there are no users.
> I think it this is done when you upgrade as well...
I wish. I have just noticed that syslocktab changed between 7.31.FC7 and
7.31.FD1, but sysmaster was not changed. It is unusual for the views to
change, it is normally the underlying tables. However, this view was
missing some fundamental join fields. ;-)
Cheers,
--
Mark.
+----------------------------------------------------------+-----------+
| Mark D. Stock mailto:mds...@mydas.freeserve.co.uk |//////// /|
| 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. |/ ////////|
+----------------------+-----------------------------------+-----------+