原理
（如上图）HANA的在线日志是由一个一个的日志段（log segment）组成的，他们存放的地点默认在/hana/log目录下，在这个目录中的日志会自动增长，在遇到savepoint的时候，日志段会被备份到备份目录中，然后空间会被释放出来。这样周而复始的循环使用。（如下图）
那么什么是日志段呢？简单的来说，它具有已在内存中提交并已作为到达日志卷文件系统的事务的记录，并且还来不及保存到仅在保存点（savepoint）之后发生的数据卷。
如果日志卷内的日志段遇到保存点
- 在log_mode=normal 和 enable_auto_log_backup=yes 的情况下，在日志段备份后，来自日志段的数据将传输到数据卷。
- 当log_mode=overwrite时，来自日志段的数据被传输到数据卷，并且将在没有日志备份的情况下以循环方式覆盖
执行上述任一操作后，日志段将变为 Free 状态，可以重新使用。
注意：日志段不同于日志备份。换句话说，当日志段遇到保存点时，它的数据会被转移到数据卷中。日志段是应该在覆盖前备份还是直接覆盖取决于参数log_mode =(normal / Overwrite)
2.HANA中日志段的状态是什么？它们有 5 种不同的日志段状态：Writing、Closed、Truncated、BackedUp、Free
有以下三种方式可以查看：
- 通过SQL语句
select b.host, b.service_name, a.state, count(*) from “PUBLIC”.”M_LOG_SEGMENTS” a join “PUBLIC”.”M_SERVICES” b on (a.host = b.host AND a.port = b.port) group by b.host, b.service_name, a.state
2. 通过hana studio
3. 在OS层面查看
1、花式作死
某年某月某一天，群里热闹非常，大家在讨论万一误删了HANA数据库的在线日志该怎么办
不知道为什么，作者就很想知道删库跑路是个什么感觉，于是就自告奋勇的说：都闪开，我来试试！
刚说完就后悔了，但又不好意思反悔，俗话说自己约的那啥，含着泪也要那啥啊！
于是接上系统，开始在群里直播删库，rm –rf命令走起！
删掉的是位于/hana/log//mnt00001/hdb00001下的log文件，删除后，HANA数据库还处于运行状态，没有马上挂掉。
接下来试试能不能正常重启，首先把HANA库停下来
果然，再次启动HANA库，真的起不来了。
这下作了大死了！
大家纷纷在群里开始吐槽自己的苦逼遭遇
想想以后还要在圈子里混饭吃，提起裤子不认人这种事也不是咱好意思干的，善良的人总是会有善报，还是修复一下算了。
2、重建日志
首先在目录/usr/sap//HDB00/hana/trace下，查看最近的
nameserver_alert_hana.trc这个日志文件，里面记载了因为丢失日志无法启动的记录。
我们有两个选择：
一是用备份恢复数据库
二是重建日志
但是，作者并没有事先做备份，所以只能选择重建日志。假如日志重建失败，那可就真要跑路了。
没有撤退可言了，只能死马当作活马医了。
切换到用户sidadm下，执行下面的命令
hdblogdiagdirectory –recreate /hana/log/SID/mnt0000X/hdb0000X/
“X”是目录编号，如果是“1”就写“1”，是“2”就写“2”
可以看到执行命令后，该目录下删除的log重建了
再试试能不能启动HANA库，运气不错，成功启动了
这下终于可以不用跑路了。
后记：这次删库操作使用作者自己的服务器，请勿模仿。删日志和删库在性质上是一致的，是一项极其危险的操作，系统随时面临宕机的风险，并且会高概率伴随数据丢失。