When you kill the linked server query somet times it will say 100% complete and rollbck 0% ... which means

You killed the query on source server but it is...

If your db recovery model is full your full backup will backup the tlog but it will not truncate the log which may cuase disk to run of space...

If you don't...

Check your maintenance plan configuration... I think you have enable the option to repair the db incase of any errors...

When sql tries to repair the db as part of maintenace...

Here is the proc from Andrew Zanevsky.

CREATE proc sp_force_shrink_log

@target_percent tinyint = 0,

@target_size_MB int = 10,

@max_iterations int = 1000,

@backup_log_opt nvarchar(1000) = 'with truncate_only'

as

set nocount on

declare @db sysname,

@last_row int,

@log_size decimal(25,2),

@unused1...

I will prefer running the integrity checks separately using WITH TABLERESULTS.. insert into a table and You can check programatically and send email notification...

DBCC CHECKDB(pubs) WITH TABLERESULTS

Replace your update with the following...

 SET @V_UPDATE_SYS_DB = N'UPDATE '+@V_TABLE_NAME+'  SET SYS__DB = 20202'

In sql 2000 when you create a table with with LOB data type (text, ntext, image...) sql automatically adds a row to the sysindexes table with some index name ttablename...I think...

Some other job or process or person may be diabling the job...

But any way check job end date in schedule table...if this is wrong this should disable the schedule but...

I think some one might have granted the execlusive CREATE PROCEDURE permissons to the login.

GRANT CREATE PROCEDURE TO <User name>

Execute "Revoke CREATE PROCEDURE TO <User name>" and see what happens.

Note:...

If you want to learn performance tuning you need to learn everything SW as well as HW.

Always ask what you want exactly...instead open question...

I think you can use sp_repldone command but becareful this may invalidate log but not sure...

Google sp_repldone you should more info...

Try using sp_dropsubscription procedure... Check BOL for more details...

Replication cluster aware...

On fail over Replication works fine without any issues because when you install SQL on cluster it installs binaries on both nodes...

Try running sp_removedbreplication procedure.

Read BOL for details.

I did get it... but you can make use of the following script...

drop

table #temp

set

nocount