Well, the first bad thing I see is that you are comparing a date (tran_eff_dt) with strings.
Never do that - always use to_date with a format mask.
Also, please post explain plan for above query, read Re: 3. How to improve the performance of my query? / My query is running slow.
and follow the advice there.
TRAN_EFF_DT BETWEEN '2012-01-01' AND '2012-12-31'
If you're comparing a DATE (at least, I suspect/hope TRAN_EFF_DT is of DATE datatype) to STRINGS, you'rein for trouble. Use TO_DATE and a proper format mask.
If BRANCH_CD is indexed, Optimizer will not use it since you're using a function on it. A function based index might help. ORACLE-BASE - Oracle Function Based Indexes
What is the exact database version? (the result of: select * from v$version; )
Are the table statistics up to date?
How many is "some"? It may be quicker to copy the rows you want to keep to a temporary table, then truncate Table1 and finally put the to-keep rows back into table1. But firstly, as PaulHorth says, you need to know what is slow - the deletion or the query that is finding the rows to be deleted.
Why the filter WHERE ID=100 AND SRCE_NM='CHECK' can be used in the 2nd not in but can not be used in the 1st not in?