This refactoring from cursor on a dblink'ed Oracle table OK? The data is being compared from the local version of the table to one in the contracts linked server.  I'm not certain what the goal of this code is in the first place, but I'm trying to get a handle on simplifying it a little.

CURSOR c3 IS
    SELECT bs.billing_service_id, bs.oser_id
    FROM   (SELECT oser_id
            FROM   other_services
            MINUS
            SELECT oser_id
            FROM   other_services@contracts) a,
           billing_service bs
    WHERE  bs.oser_id = a.oser_id
           AND bs.sent = 0
           AND bs.billing_service_id NOT IN (
               SELECT bd.billing_service_id
               FROM   billing_details bd);

-- snip

FOR c_rec3 IN c3 LOOP
    DELETE FROM billing_service
          WHERE billing_service_id = c_rec3.billing_service_id;
END LOOP;


Seems to me that this could be naively refactored (without fooling with any other issues it has like the implicit joins and other garbage) simply as:

    DELETE FROM billing_service
          WHERE billing_service_id IN
(
    SELECT bs.billing_service_id
    FROM   (SELECT oser_id
            FROM   other_services
            MINUS
            SELECT oser_id
            FROM   other_services@contracts) a,
           billing_service bs
    WHERE  bs.oser_id = a.oser_id
           AND bs.sent = 0
           AND bs.billing_service_id NOT IN (
               SELECT bd.billing_service_id
               FROM   billing_details bd)
);


I don't think it's a significant amount of data in these tables - about 26000 rows on each side, and I don't think the set of differences is that big of a subset of the two.

But I was wondering if there are issues with DB Links which make cursors preferable to regular set-oriented methods?  This operation is part of a stored procedure which is run from an Oracle job on a daily basis.
Joins across database links can lead to sub-optimal execution plans as Oracle doesn't have all the information available about both sites. Queries across db links can (and do) perform just fine when joined to local tables though. 

If writing a new query with local and remote tables I'd start joining it all together (set-based) then only break it into separate queries if performance is unacceptable and other tuning hasn't worked.

Given your query is just a simple minus with no joins to the remote site, I would expect the refactored set-based approach to be quicker. Make sure you test it though!