You can't / shouldn't use truncate in a log shipping solution because it is a minimal logged operation and that would break the logshipping. Delete on the other hand is slower but is fully supported in a logshipping solution. Deletes in primary database will also delete from the target database. > In addition, TRUNCATE TABLE statements > cannot be used for tables involved in > replication or log shipping, since > both depend on the transaction log to > keep remote databases consistent. > TRUNCATE TABLE cannot used be used > when a foreign key references the > table to be truncated, since TRUNCATE > statements do not fire triggers. This > could result in inconsistent data > because ON DELETE/UPDATE triggers > would not fire. If all table rows need > to be deleted and there is a foreign > key referencing the table, you must > drop the index and recreate it. If a > TRUNCATE TABLE statement is issued > against a table that has foreign key > references, the following error is > returned [
TRUNCATE is a logged operation in SQL Server 200x. If you are using FULL RECOVERY you will still be able to restore the database as normal from your log backups after you do a TRUNCATE. The only difference is that TRUNCATE logs whole pages at a time while DELETE logs each row deletion. TRUNCATE is sometimes called a "minimally logged" operation but that's really a misleading term because the same information is being logged, it's just that it happens faster.
Thanks for all the replies, I have tested logshipping by truncating the table, and i see the table is truncated on the secondary DB and logshipping is running smooth. Now can i use truncate on DB(tables) which are using logshipping? What are the cautions that I should take while using logshipping.