[Scripts]分享一段有趣的 VBScript 让计算机讲出你想说的
使用 VBScript 让计算机讲出你想说的话
gOxiA 对 Scripts 和其他开发语言都并不熟悉，这段脚本程序也是从新浪微博上转过来的，转载率非常之高，到底是因为什么引人关注呢？！将下面这段脚本命令输入到记事本中，并存储为 vbs 扩展名，打开音箱或带上耳机，最后双击运行。
Yeh，你将会听到一段计算机语音朗读出“I Love You”，是不是很有意思。简单的一段命令便能够让计算机讲出你想说的话，看来还是很有使用价值的。
这段脚本其实是使用了 Windows API 来调用了“Windows 讲述人”功能，Microsoft 为我们提供了强大的接口能够让我们利用 Windows 的功能实现更多的应用！而且利用脚本我们能高效的完成很多工作！
Microsoft Scripts Center 提供了非常有价值的脚本学习资料，如果你有兴趣不妨学习学习！也许你也能利用 Windows 搞出来有意思的应用或提高你的工作效率。
[WAIK] imagex 恢复系统备份映像经验分享 - 解决 winload 0xC000000E 故障
使用集成 imagex 等小工具的 WinPE v3.0 工具盘可以说为很多朋友解决了不少的问题。gOxiA 一直以来也都擅长喜好使用 imagex 来执行系统备份，诸如此类的优势说明在过去的日志中也经常提到，这里就不再复述。而今天要与大家分享的经验是最近 gOxiA 遇到一个问题，而过去也曾经历过只不过未有留意，而这次遭遇同类问题在解决之后认为有必要大家分享，帮助大家避免发生同类的问题。
起因是这样，gOxiA 的 Blog 服务器前段时间曾出现不稳定的状况，在对系统执行优化后决定对磁盘执行一次碎片整理，毕竟这个基于 Windows Server 2008 Web 的虚拟服务器已经运行了近17个月。随即在夜间进行了磁盘整理工作，第二天一早发现悲剧降临了，在执行碎片操作前，gOxiA 忽略了这台虚拟服务器使用的是动态类型的磁盘，而虚拟磁盘文件所在的分区卷容量还小于这个动态类型磁盘的容量，结果可想而知。系统启动后无法登录，提示磁盘已满，而存储卷显示剩余0字节。之前决定使用 VMWare 的压缩工具进行压缩，但都以失败告终。现在唯一的可行办法就是使用 WinPE 引导系统，挂载一个空的虚拟磁盘并使用 imagex 将原系统映像备份出来，因为 imagex 是以文件方式来执行数据拷贝的，所以新生成的映像恢复到新的虚拟磁盘上将不会有任何问题，初次之外还起到了磁盘整理的效果，因为 imagex 恢复后的文件时顺序排列的。经过一番折腾，总算把备份的映像释放到了新的虚拟磁盘上，然后挂载到虚拟机上启动系统，但是出现了 winload.exe 0xC000000E 故障。
该故障引发的原因很简单，因为 bcdboot 中的引导信息是与硬盘所关联的，因为映像释放到了新的虚拟磁盘上，就相当于更换了硬盘，那么势必导致硬盘唯一标识变更，最终导致该故障的发生。而早先 gOxiA 使用 imagex 用于部署系统，不是将备份恢复到原硬盘就是使用 sysprep 后部署到其他硬盘上。此外，在部署 Windows 7 和 Windows Server 2008 R2 时因为系统设计的变化，默认安装系统时会自动生成一个 100M 大小的分区存储引导信息，而通常我们只备份系统盘，而在使用 imagex 恢复映像后都需要使用 bcdboot 命令创建引导信息。OK，到这里我们已经改如何解决这个故障信息了，除了使用 Windows 安装光盘引导进行修复以外，我们还可以使用手头现有的 WinPE 光盘进行命令行方式的修复。为此，我们使用 WinPE 引导盘引导系统，执行如下命令：
执行完这条命令之后我们就可以进行正常的启动了，但是问题还并未真正解决完。因为你会发现启动过程会显示 boot manager 菜单，而其中包含了两个名称相同的系统引导项，此外还会发现当前的引导菜单无法正确显示出中文字符。所以我们在前面使用 bcdboot 命令创建完引导信息之后还需要再执行如下命令，使 boot manager 采用中文版本。
执行完上面两行命令后再退出 WinPE 重新引导计算机，最后使用 bcdedit 命令删除之前失败的系统引导项，整个恢复过程才算正式结束。
保持清醒的头脑，认真分析之后再进行操作才能万无一失！
[MySQL]快速解决"is marked as crashed and should be repaired"故障
快速解决“is marked as crashed and should be repaired”故障
细心的朋友可能已经察觉到前几天本Blog出现不稳定的状况，事情起因是 Windows Server 2008 Web 运行异常的慢，明显感觉是 CPU 占用率高，之后对系统进行了优化并对相关服务进行了升级（中间还遇到了灾难性的故障，后篇日志会单独向大家介绍分享经验），其中就包括 MySQL，因为一直以来 MySQL 都采用的手工安装，这次升级还是如此，由于系统响应速度慢所以此次升级将 my.ini 也进行了修改采用了 my-small.ini 作为蓝本，以缓解内存占用的问题。之后运行了半天发现速度正常便开放了 Blog，第二天上午再次打开 Blog 提示”is marked as crashed and should be repaired“故障，要求重新安装 Blog！（太悲剧了！）
在网上查找了解决办法，看来很多 Bo-Blog 用户都有遇到这个问题，回忆起过去也曾遇到过此故障。而且之前也是使用的 my-small.ini 作为配置文件蓝本，早期采用的解决办法非常繁琐，而且稍有不慎就只能回档到过去的备份，损失将会非常大。过去1年未发生此类故障貌似是跟当时使用了 my-large.ini有关，因为当时增加了虚拟服务器的内存故使用了 large 配置。而造成”is marked as crashed and should be repaired“故障的主要原因加之网上现有资料分析，应该与内存有很大关系。
为了不冒失修复，故采取保守做法，我们知道 MySQL 一个高效的管理工具便是 PhpMyAdmin，而在该管理软件中就包含了对表的检查、分析、修复、优化功能，比起网上提供的含糊命令行来说更安全更简便。
通过实践，在使用检查表功能后确实发现了问题，之后使用修复功能进行了修复，反馈结果每个表都已经 ok，再执行一次优化，重新测试访问网站终于恢复了正常。一场灾难就此避免……
