Ah, now I see the problem. The merge did what you expected for the first three rows. The reason it didn't merge for the second instance of 836 (row 5 of table A) is because there is only one record in B for A2=836 and that was used when merging with row 2 of table A. DATA step merges don't merge one record in B with all matching records in A. If there is one record in B and 5 matching records in A then only the first record will be 'merged' the other four records will only have table A data.
I like to use PROC SQL in these cases (and because you don't have to sort first). It merges differently than the DATA step. Here's an example. In the coalesce command, you have to list the column from Table B first because you want the result from Table B to take priority.
[pre]
proc sql;
create table C as
select A.A1, A.A2, coalesce(B.A3, A.A3) as A3
from A left join B
on A.A2 = B.A2
order by A.A1, A.A2;
quit;
[/pre]
If you want to stick with the DATA step, try renaming the A3 variable in Table B to a new name. Then, when you merge, the B values are "retained" in the new variable. You can use an IF statement to assign these values back to A3. Here's an example:
[pre]
data C;
merge A (in=A) B (in=B rename=(A3=A4));
by A2;
if A;
if B then A3=A4;
drop A4;
run;
[/pre]