It seems to me that you can avoid the proc sort (the expensive part of your program) entirely, while solving the problem of getting a sample of online transactions equal in size to the total population of onsite transactions (which is presumably about 200K out of millions of records):
data onsite (drop=n_onsite n_online);
set have end=end_of_have;
if account2 in (....) then do;
output;
n_onsite+1;
end;
else n_online+1;
if end_of_have;
call symput('N_onsite',cats(n_onsite));
call symput('N_online',cats(n_online));
run;
data online (drop=remaining_:);
set have;
where not account2 in (....) ;
retain remaining_sample &n_onsite
remaining_available &n_online;
if rand('uniform') <= remaining_sample/remaining_available then do;
output;
remaining_sample=remaining_sample-1;
if remaining_sample=0 then stop;
end;
remaining_available=remaining_available-1;
run;
This program avoids sorting the online transactions (have_need in your program), which means it avoids writing out a big data set just for sampling purposes.
The first data step writes out all the onsite transactions, and counts the number of online and onsite transactions in the initial data set. At the end of this step it puts those counts in macrovars N_ONSITE and N_ONLINE.
The second data step re-reads all the online transactions, and randomly selects (with equal probability) the sample of online transactions having N_ONSITE sample size. It does this by counting down the number of available online transactions, and counting down the number of needed randomly selected transactions.
Edited additional note: The second data step uses a WHERE statement to filter in only online transactions. Using a WHERE to filter incoming instead of an IF allows the use of an unconditional decrement of REMAINING_AVAILABLE, since the WHERE statement (unlike an IF filter) never permits an online transaction to be seen by the data step.
The benefit is that the original data set is read twice, but no large intermediate dataset is written to disk - possibly very time consuming.
