Disable Log Shipping 2000 while Index rebuild Jobs are running

I would rather recommend that you change the way you do your index maintenance, rebuilding only when necessary will drastically reduce log file growth issues.

There are a number of "smart" index maintenance scripts available on the internet, my personal favourite is supplied by Ola Hallengren. There is also Michelle Ufford's Index Defrag v4.0 which is also very good.

However, as you are on SQL 2000, you are limited in you index interrogation abilities. Something like this would at least get you started:

/* Minimum Fragementation level used to drive index rebuild */
DECLARE @MinFragmentation tinyint
SELECT @MinFragmentation = 30

DECLARE @RebuildCommand varchar(8000)
SELECT @RebuildCommand = ''
/* Temp table for Index Interrogation */
CREATE TABLE #Results
    (ObjectName sysname,
     ObjectId int,
     IndexName sysname,
     Indexid tinyint,
     [Level] int,
     Pages int,
     [Rows] int,
     MinimumRecordSize int,
     MaximumRecordSize int,
     AverageRecordSize int,
     ForwardedRecords int,
     Extents int,
     ExtentSwitches int,
     AverageFreeBytes int,
     AveragePageDensity int,
     ScanDensity int,
     BestCount int,
     ActualCount int,
     LogFragmentation tinyint,
     ExtentFragmentation int)

/* Interrogate Indexes and store info in temp table */
INSERT  #Results
        EXEC ('DBCC SHOWCONTIG With TableResults')

/* Build Command to Reindex Indexes */
SELECT  @RebuildCommand = @RebuildCommand + 'DBCC DBREINDEX (''' + ObjectName + ''' , ' + IndexName + ');'
FROM    #Results R
INNER JOIN sysindexes si ON si.id = r.ObjectId
                            AND si.indid = r.Indexid
INNER JOIN sysobjects so ON so.id = si.id
WHERE   so.type = 'U'
        AND Indexid > 0
        AND LogFragmentation > @MinFragmentation

/* Execute Rebuild Command */
--SELECT @RebuildCommand
EXEC (@RebuildCommand)

There is no error handling and it could be done better, but it is a starting point to getting your index rebuilds to only work on indexes that really need work.

The problem is that maintenance jobs update a lot of pages and all those changes get recorded in the transaction log. I'm afraid there isn't a way round it if you want to log ship. In fact the log shipping is probably stopping your logs from getting even bigger because the frequent backups mark space in the log file for re-use, preventing file growth.

Unless you are willing to re-initialize Log Shipping after every Maintenance run then the short answer is no.

Log Shipping faithfully applies logged transactions to ensure synchronization. About the only workarounds I can think of would be to drop the indexes and then re-create them (though that is basically what a rebuild does anyway) or re-evaluate and reduce your indexes (which of course may impact your performance).

I'm afraid you will have to accept the log sizes as an artifact of Log Shipping and the size of your data. If you want smaller logs - ship more often, every 10 or 5 minutes.