Seems like a good reason to visit the Oracle Documentation site. The 2-day dba documents are very good.
If your database is running in ARCHIVELOG mode, it copies all transactions to the archivelog destination. The transactions are always written to the redolog files but when they are full, they are only saved when running in archivelog mode. This enables you to restore your database to any point in time. This restore operation starts with restoring a full backup where you can apply the archives until you reach the point in time where you want to stop the recovery. For example, close before a table was dropped.
Normally production backups are made with the database online. Again, a reason to run your databases in archivelog mode. IF not running archivelog mode, in a disaster scenario you might loose all transactions made since the last backup. If your transactions are really important it could be smart to copy the archivedlog files to a second DC on a very regularly basis. How regularly depends on the cost of loosing transactions. If you can handle loosing one day, you copy daily, most sites copy a few times/hour or even use standby databases that receive the transactions in a near sync way.
In general you start restoring the database and perform a recovery until time. Normally we use rman to do this, something like
rman
run
{
set until time to_date('20140914 14:22','yyyymmdd hh24:mi');
restore database;
recover database;
}
when ready and not done a full media recovery, open the database with a reset logs option.
alter database open resetlogs;
To prevent nightmares from happening, it might be smarter to get involvement from a dba.