数据库服务正在运行，但是。 有没有简单的方法来恢复数据库，也许到了可以重新运行备份作业和恢复服务的地步？
假设没有超越tnsping的 Oracle知识;-)
从alert_mydatabase.log文件（ <orahome>\admin\mydatabase\bdump\ ），
ORA-15041: diskgroup space exhausted ... ARCH: Archival stopped, error occurred. Will continue retrying ...
ORA-15041：磁盘组空间耗尽
好像你正在使用ASM来存储你的归档日志/备份，你可能已经填满了（可能是因为旧的备份没有被清除）
正如cagcowboy已经告诉你，你的数据库可能是挂起的， 因为它不能存档和切换其当前的日志文件，但似乎你不得不恢复/恢复什么的。 一旦你能释放一些空间的实例将继续其活动。
正如已经build议的那样，我应该尝试与Oracle支持联系以获得适当的build议。
问候。
一些随意的想法：
假设你有一个Oracle支持合同，我会让他们参与。 不一定，因为这是一个不寻常的或特别困难的问题; 但同样因为你对Oracle不熟悉。 得到一些错误，你可能会搞砸你的数据库。
你为什么认为恢复是必要的？ 当磁盘满了，写入数据库是“冻结”（正如你所看到的），但不应该有数据丢失/损坏。
你有你的DB系统密码？
这是一个生活/生产系统吗？
有没有其他的方式来访问SAN文件系统？
回答这些问题，我们可以从那里拿走。
这里有更多的随机想法：
1）dba在哪里？
2）由于数据库卷不能在Windows中查看，我假定数据库使用原始分区或ASM。 你知道哪一个？ 如果不是asm或raw，那么底层数据磁盘是什么文件系统？
3）备份数据库时，如何处理归档日志的删除/归档？
4）如果不使用raw / asm并使用文件系统，则查看是否可以扩展/增大归档日志的san卷以允许归档继续。 然后立即得到一个备份，并删除/归档较旧的归档日志。
5）您也可以尝试为归档日志创build新卷，进入数据库并更改数据库以归档到新的归档日志目标。
至于你的档案日志，似乎数据库有地面停止等待空间，但没有坠毁。 如果你腾出空间，它会继续。 你最好的办法是把dba和sanpipe理员一起，确定可以做些什么来腾出空间。 如果遇到困难，请致电oracle支持部门寻求帮助。