|
Home > Archive > IQ Server > August 2005 > ASE to IQ 12.6 replication issue?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
ASE to IQ 12.6 replication issue?
|
|
|
| why is it that i am having to create GIGANTIC dbspace(s) to
handle an 18,940 row update to a average size table?? so far
I have had to create 5 extra dbspaces!! I started with a
50gb dbspace (which was 60% free), and have had to add an
additional total of +30gb more!!! oh yeah, the transaction
still isn't complete and it started yesterday!!! i will
proably need to create more dbspaces and i have no more
space. what is going on?!?!?!?
| |
| Esteban Kemp 2005-08-19, 1:27 pm |
| it seems your transaction is eating all your dbspce, I have
a similar problem a few days ago (a transaction eat 20 gb of
dbspace),
And y solve it reducing the size of the transaction, doing
commit each n record inserted..
> why is it that i am having to create GIGANTIC dbspace(s)
> to handle an 18,940 row update to a average size table??
> so far I have had to create 5 extra dbspaces!! I started
> with a 50gb dbspace (which was 60% free), and have had to
> add an additional total of +30gb more!!! oh yeah, the
> transaction still isn't complete and it started
> yesterday!!! i will proably need to create more dbspaces
> and i have no more space. what is going on?!?!?!?
| |
|
| thanks for the response. i agree breaking up the tran is
best, however, i'm stress testing replication with IQ 12.6,
so i did the mass update. it concerns me i only had to
allocate 100mb on the ASE side, and so far have allocated
40gb on the IQ side...makes no sense to me.
another question...the 40gb i allocated, will it be 'freed'
up after the update is done??
[color=darkred]
> it seems your transaction is eating all your dbspce, I
> have a similar problem a few days ago (a transaction eat
> 20 gb of dbspace),
> And y solve it reducing the size of the transaction, doing
> commit each n record inserted..
>
>
| |
| Esteban Kemp 2005-08-19, 1:27 pm |
| when you made commit, all the allocate space will be free..
About why the transaction allocate so many IQ Main Store
space, is a mystery to me too.
Maybe someone else could give us an explication..
> thanks for the response. i agree breaking up the tran is
> best, however, i'm stress testing replication with IQ 12.6
> , so i did the mass update. it concerns me i only had to
> allocate 100mb on the ASE side, and so far have allocated
> 40gb on the IQ side...makes no sense to me.
>
> another question...the 40gb i allocated, will it be
> 'freed' up after the update is done??
>
> what is going on?!?!?!?
| |
| Chris Baker 2005-08-19, 8:26 pm |
| You are maintaining MANY versions of your table (run sp_iqstatus to see the
transaction count), one for each separate insert (copy of last transaction's
pages with this transaction's inserts added). Next transaction will take a
copy and add it's changes, and so on....
The commit will free up those versions not used by any other process and the
space will be reused, as the previous replies have found out.
Each transaction is opening up at least one page (most likely more) per
column, not one per row (as with an OLTP engine). This is why you are using
so much space.
Bulk operations will be better as they will only create 1 version of the
table for all the rows inserted. With that in mind, you may want to stage
the data and use 'load table' or 'insert location' to move the data to IQ.
Remember that IQ is not a transactional engine.
Chris Baker
Remember, your are
<Esteban Kemp> wrote in message news:4306011e.52e2.1681692777@sybase.com...[color=darkred]
> when you made commit, all the allocate space will be free..
>
> About why the transaction allocate so many IQ Main Store
> space, is a mystery to me too.
>
> Maybe someone else could give us an explication..
>
| |
|
| chris- i hear ya, however, i heard replicating into 12.6
was leaps and bounds over previous versions...i know what
was said at techwaves-not to replicate directly into IQ,
however, i heard all that changed with version 12.6. is
that not the case in your opinion?
> You are maintaining MANY versions of your table (run
> sp_iqstatus to see the transaction count), one for each
> separate insert (copy of last transaction's pages with
> this transaction's inserts added). Next transaction will
> take a copy and add it's changes, and so on....
> The commit will free up those versions not used by any
> other process and the space will be reused, as the
> previous replies have found out.
>
> Each transaction is opening up at least one page (most
> likely more) per column, not one per row (as with an OLTP
> engine). This is why you are using so much space.
>
> Bulk operations will be better as they will only create 1
> version of the table for all the rows inserted. With
> that in mind, you may want to stage the data and use
> 'load table' or 'insert location' to move the data to IQ.
>
> Remember that IQ is not a transactional engine.
>
> Chris Baker
>
> Remember, your are
> <Esteban Kemp> wrote in message
> made commit, all the allocate space will be free.. >
> is >> best, however, i'm stress testing replication with
> IQ 12.6 >> , so i did the mass update. it concerns me i
> only had to >> allocate 100mb on the ASE side, and so far
> have allocated >> 40gb on the IQ side...makes no sense to
> me. >>
> I >> > have a similar problem a few days ago (a
> transaction eat >> > 20 gb of dbspace),
> average >> > > size table?? so far I have had to create 5
> extra >> > > dbspaces!! I started with a 50gb dbspace
> (which was >> > > 60% free), and have had to add an
> additional total of >> > > +30gb more!!! oh yeah, the
> transaction still isn't >> > > complete and it started
> yesterday!!! i will proably >> > > need to create more
> dbspaces and i have no more space. >> what is going
> on?!?!?!?
>
>
|
|
|
|
|