Progress Report & Working Schedule

1. 文章

更新了有参考文献的版本，如果没什么大问题准备往latex里整。如果有必要的话可以写个latex语法的blog。

sad

2.有关SQL Server ErrorLog的简单解释

我们远程电脑的C盘空间占满了，可能对某些程序的运行会造成影响。本来以为是因为某个DB建在了C盘导致数据文件不断增长，但把位于C盘的DB移到D盘后C盘还是处于被占满的情况。这个时候据我所知可以有几种方法可以清理空间：

1. 右键属性磁盘清理。由于本人水平比较低因此只敢勾选默认项以免造成不良影响。确实清除了一点，但起不到决定性的作用。

2. 打开C盘一个一个文件夹属性看大小，以此类推。

3. 用这个好用的工具方便的看磁盘占用情况

   传送门（感谢巨神的大力支持）

用工具可以得到C盘的空间是这样被占满的：

之前根据那边的说法是Temp太大了（指的应该是AppData里的Temp）。大部分情况temp文件夹里的东西应当是可以删掉的。但当我搜索相关信息后发现有勇者删掉之后SQL Server的某些配置似乎发生了改变导致不能用了。所以我打消了这个念头。Temp里mcplugin文件夹有大量的xlog文件(deletable)。但由于我没有搜到mcplugin的具体用途(搜出来全是MC插件...)先暂时没有动。

除了Temp之外还有两个文件夹占地很大，分别是winsxs(16.4G)以及SQL Server里存放日志的文件夹。winsxs包含了2W+的文件夹，且最近的修改日期都在很久很久以前。

因此最后来看一下SQL Server里的ErrorLog

默认情况下，SQL Server会保留7个错误日志文件，分别是ErrorLog， ErrorLog.1~.6。在每次启动SQL Server实例的时候，就会创建新的ErrorLog文件，而把之前的ErrorLog更名为ErrorLog1，以此类推直至6。每个ErrorLog文件记录了“重启数据库服务前”至“上一次重启数据库服务后”的全部错误日志信息。尤其像我们需要不断采集数据，使得数据库服务一直不断，很容易导致错误日志爆表。(这增长速度简直快的离谱啊，这才一天就有100M+)

解决方法：

1. 手动清除

新建查询，输入

EXEC sp_cycle_errorlog  # 关闭当前错误日志文件，循环错误日志编号

执行七次

1. 自动化处理

新建作业(JOB)，自己设置步骤和频率啥的，原理是一样的。

但上述文件是不能够直接删除的，只能通过 EXEC sp_cycle_errorlog 来删除。这是因为ErrorLog默认在服务重启后更新。只要服务跑着ErrorLog就会一直被系统进程占用。

3.最后两个站点的模型修改

先放结论：NN在一些场合下表现真的不如线性模型

这周跑的两个站点分别是泾源和固原，我们先来看一下地理位置(也许可以一部分解释为什么模型表现的不尽如人意)

四个站点中二者一个位于最北，一个位于最南。相比于隆德和六盘山，二者都缺乏了一定的位置信息。且固原肉眼可见的离其他三个站点相距遥远，相关性就比较弱了。

首先看一下泾源的表现情况。

线性模型的残差分布已经很均匀，且残差的绝对值在5以内。说明线性模型已经能够做出比较好的拟合。

全连接层的表现就不是那么尽人意了...一方面残差的绝对值和分布情况都不如线性模型表现得好。另一方面，这张残差图是我目前调节超参数得到的网络中表现最好的一个，而这个网络是可以得到的有科学性的最简单的网络(输入层+输出层only，activation=linear)。

激活函数、神经元个数、网络层数，都不能增强网络的performance(改了之后会得到分布类似，残差绝对值增大的残差图)。在线性模型表现确实优秀的情况下，神经网络好像真的无法PK过...（当然也有很大的可能是我什么地方又搞错了）

然后再看固原的：

固原的线性模型表现得本来就不咋地。强线性的残差，惨淡的 \(R^2\) ...

另外从线性模型的系数上看，是温湿度占了大头，其他三个站点的影响虽然是有的，但没有自身的气象数据影响大。

这是我目前能挑出来的最棒的残差图...更强线性的残差，稍好一点的 \(R^2\)...

我感觉这个拟合的不好就可以让数据背锅了。固原离其他几个站点确实挺远的，主导风向也不太能搭上边，相关性也不是特别强。气象数据的能耐我们之前也已经见识过了...在目前的条件下用神经网络可能确实不太适合。

下周计划

1. 继续处理乌鞘岭的数据然后玩一下，如果乌鞘岭之前没有人工降雨作业我保持乐观态度

2. 复习(重学)一下latex

3. 想一下软件训练营那个东西怎么玩

---

本文章使用limfx的vsocde插件快速发布