Results 1 to 8 of 8
  1. #1
    Join Date
    Oct 2003
    Posts
    7

    Unanswered: Problem dropping partitions on replicate server

    I recently materialized a big database using the Sybase Replication Server. Many tables are quite big so I added a few new partitions to be able to handle the queues. Note that the tables don't look the same on the two sites so I use stored procedure calls for insert, update, delete. When the materialization was finished I can't drop the temporary partitions since the contain some data (1 Mb typically).

    I have verified that all the data has infact materialized so why exactly isn't the partitions empty?

    Version:
    Replication Server/11.5.1/P/HP9000/800/HP-UX 10.01/1/OPT

    /oligus

  2. #2
    Join Date
    Aug 2003
    Location
    South Africa
    Posts
    10

    Re: Problem dropping partitions on replicate server

    Originally posted by oligus
    I recently materialized a big database using the Sybase Replication Server. Many tables are quite big so I added a few new partitions to be able to handle the queues. Note that the tables don't look the same on the two sites so I use stored procedure calls for insert, update, delete. When the materialization was finished I can't drop the temporary partitions since the contain some data (1 Mb typically).

    I have verified that all the data has infact materialized so why exactly isn't the partitions empty?

    Version:
    Replication Server/11.5.1/P/HP9000/800/HP-UX 10.01/1/OPT

    /oligus
    I've always found that sometimes it takes a few minutes or hours for the queue to actually drop.
    When you issue an 'admin disk_space' after issuing the command, is the status "ON-LINE/DROPPED/"?

  3. #3
    Join Date
    Oct 2003
    Posts
    7

    Re: Problem dropping partitions on replicate server

    Originally posted by fruitbat
    I've always found that sometimes it takes a few minutes or hours for the queue to actually drop.
    When you issue an 'admin disk_space' after issuing the command, is the status "ON-LINE/DROPPED/"?
    The status is indeed ON-LINE/DROPPED/ and has been so for ages. Do you figure one might be able to empty the partition somehow?

  4. #4
    Join Date
    Sep 2003
    Location
    Switzerland
    Posts
    443
    Hi

    How long the status has been like this ?

    You could manually delete a partition using the following commands but be very careful doing this.

    delete RSSD..rs_segments where partition_id = <bad_par_num>
    delete RSSD..rs_diskpartitions where id = <bad_par_num>
    REBOOT RS

  5. #5
    Join Date
    Sep 2003
    Location
    Switzerland
    Posts
    443
    Hi,

    Sorry, forgot to include this.

    After Rebooting RS, if you get any errors about "failure to write to quue", you may have to "rebuild queues"

    Vishi

  6. #6
    Join Date
    Oct 2003
    Posts
    7
    Originally posted by trvishi
    Hi,

    Sorry, forgot to include this.

    After Rebooting RS, if you get any errors about "failure to write to quue", you may have to "rebuild queues"

    Vishi
    Actually, on of the partitions dropped. I have dropped the rest aswell but they are still there but I'll think I will just let them be over the night and see if they aren't gone tomorrow. If they are not I will try to remove them manually. Thank you for the tip.

    Ages in my world btw is a couple of hours ;-)

  7. #7
    Join Date
    Aug 2002
    Location
    Madrid, Spain
    Posts
    97

    Re: Problem dropping partitions on replicate server

    Originally posted by oligus
    I recently materialized a big database using the Sybase Replication Server. Many tables are quite big so I added a few new partitions to be able to handle the queues. Note that the tables don't look the same on the two sites so I use stored procedure calls for insert, update, delete. When the materialization was finished I can't drop the temporary partitions since the contain some data (1 Mb typically).

    I have verified that all the data has infact materialized so why exactly isn't the partitions empty?
    Even if every queue is empty, there's an "active" segment
    for each queue, which is the segment show as "Last Seg.Block"
    by "admin who, sqm". This is the segment the queue will use
    if new data needs to be stored. They may be now in any partition;
    bad luck if one is still sitting on your temporary partitions.

    The clean way is, first, to drop the partition, what you did and
    simply marked it DROPPED (but didn't remove it). Now, RepServer
    will use only those "active" segments on the partition; once the
    64 blocks of them are used, RepServer will allocate a new segment
    on a different partition, and when there's no used segment on it
    it will remove the partition. When this happens, "admin disk_space"
    no longer shows the partition, and you may safely remove the
    underlying file.

    To know which queues are still using a partition, get the
    partition number with "admin disk_space" and then query
    this at the RSSD:
    select q_number, q_type from rs_segments
    where partition_id= nnnn and q_number > 0

    Personally, I prefer to force RepServer to spend the remaining
    blocks of the problem segment by generating some activity.
    For instance, modify thousands of times a non-vital column, or
    open and commit thousands of transactions with no statements
    inside, etc.

    Regards,
    Mariano Corral

  8. #8
    Join Date
    Oct 2003
    Posts
    7

    Re: Problem dropping partitions on replicate server

    Originally posted by corral
    Even if every queue is empty, there's an "active" segment
    for each queue, which is the segment show as "Last Seg.Block"
    by "admin who, sqm". This is the segment the queue will use
    if new data needs to be stored. They may be now in any partition;
    bad luck if one is still sitting on your temporary partitions.

    The clean way is, first, to drop the partition, what you did and
    simply marked it DROPPED (but didn't remove it). Now, RepServer
    will use only those "active" segments on the partition; once the
    64 blocks of them are used, RepServer will allocate a new segment
    on a different partition, and when there's no used segment on it
    it will remove the partition. When this happens, "admin disk_space"
    no longer shows the partition, and you may safely remove the
    underlying file.

    To know which queues are still using a partition, get the
    partition number with "admin disk_space" and then query
    this at the RSSD:
    select q_number, q_type from rs_segments
    where partition_id= nnnn and q_number > 0

    Personally, I prefer to force RepServer to spend the remaining
    blocks of the problem segment by generating some activity.
    For instance, modify thousands of times a non-vital column, or
    open and commit thousands of transactions with no statements
    inside, etc.

    Regards,
    Mariano Corral
    Thank you for taking time to explain. The partitions were dropped when I came in the next morning. This might be due to the fact that there is constant activity on the two sites and as you explained that would help the replicate server to re-allocate to an active partition. Another wonderful tip on how to empty them by "faking" activity might come in handy one day though, thank you very much.

    /oligus

Posting Permissions

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