SQL Server logical consistency-based I/O error
First; ensure you have a reliable, recent backup of the database in question.  Test the backup by restoring it to some other server, then run DBCC CHECKDB against it to determine if the backup contains the corrupted page(s).  If the backup shows no corruption, and DBCC CHECKDB returns a clean bill-of-health for the database, you might consider just restoring the backup if it's recent enough to meet your recovery point objective.

Second, backup the database (while ensuring you don't overwrite any existing backups you may need), and restore it to some other machine.  Run DBCC TRACEON (3604);  DBCC PAGE (5, 1, 9545681) to see what kind of data is stored in the page - look for m_objId and m_indexId in the output, then check that against sys.objects and sys.indexes.  Best case scenario, the data will be part of a non-clustered index that you can simply drop and recreate with ALTER INDEX ... REBUILD.  If the data on the page belongs to a clustered index, or a heap, you run the risk that DBCC CHECKDB (repair_allow_data_loss) will cause you to lose access to the entire table, or at least part of the data stored in it.  

If you manage to get the corruption issue resolved, you should determine the root cause so you can mitigate the issue, and prevent future corruption.  If hardware is an issue, replace it. 

Brent Ozar has a great article detailing how to approach this problem on his blog.