I am increasingly liking baselines these days. Main reason is that you can have multiple plans which is really helpful if you have bind sensitive statements. The other thing that’s cool is that once you have a baseline, additional plans are collected automatically for that statement (even if optimizer_capture_sql_plan_baselines is set to false). So you are bulding a repository for potentially better plans as well. :)

More detail on the process I followed:
— Use HINTS and SQL Profile to get good plan
–1) Run bad sql to fill cusor cache, but kill after short while
— Get SQL_ID and PLAN_HASH_VALUE from v$sql
SELECT sql_id, child_number, plan_hash_value from v$sql where sql_text like ‘%BLA BLA BLA%’;

–3) Now generate new plan using hints /*+ ORDERED */ could be starting point. You just need to get it to execute in reasonable time.
— Run hinted SQL through SQL Tuning Advisor in EM and accept SQL profile
SELECT * FROM dba_sql_profiles;

–6) Validate by running SQL to see performance improvement
— Check v$sql should have entry connected to SQL PROFILE plan for both BAD and hinted SQL
SELECT * from v$sql where plan_hash_value=’2233217598′;

Thanks a lot this article really helped me solve performance issue with complex SQL, which try as I may I could not get the CBO to come up with a good plan. What I then did was:
1) hinted the SQL to get a better plan
2) used EM SQL Tuning Advisor to check my hinted SQL
3) a SQL profile was subsequently created which improved the hinted plan
4) using your article linked the SQL profile PLAN to a BASELINE created against the original SQL