数据库文件

一、简介： 尽管SQLite的数据库是由单一文件构成，然而事实上在SQLite运行时却存在着一些隐含的临时文件，这些临时文件是出于不同的目的而存在的，对于开发者而言，它们是透明的，因此在开发的过程中我们并不需要关注它们的存在。尽管如此，如果能对这些临时文件的产生机制和应用场景有着很好的理解，那么对我们今后应用程序的优化和维护都是极有帮助的。在SQLite中主要产生以下七种临时文件，如： 1). 回滚日志。 2). 主数据库日志。 3). SQL语句日志。 4). 临时数据库文件。 5). 视图和子查询的临时持久化文件。 6). 临时索引文件。 7). VACUUM命令使用的临时数据库文件。 二、具体说明： 1. 回滚日志： SQLite为了保证事物的原子性提交和回滚，在事物开始时创建了该临时文件。此文件始终位于和数据库文件相同的目录下，其文件名格式为: 数据库文件名 + " -journal " 。换句话说，如果没有该临时文件的存在，当程序运行的系统出现任何故障时，SQLite将无法保证事物的完整性，以及数据状态的一致性。该文件在事物提交或回滚后将被立刻删除。 在事物运行期间，如果当前主机因电源故障而宕机，而此时由于回滚日志文件已经保存在磁盘上，那么当下一次程序启动时，SQLite在打开数据库文件的过程中将会发现该临时文件的存在，我们称这种日志文件为"Hot Journal"

工欲善其事，必先利其器。学好SQLite的命令行工具，对于我们学习SQLite本身而言是非常非常有帮助的。最基本的一条就是，它让我们学习SQLite的过程更加轻松愉快。言归正传吧，在SQLite的官方 下载 网站，提供了支持多个平台的命令行工具，使用该工具我们可以完成大多数常用的SQLite操作，就像sqlplus之于Oracle。以下列表给出了该工具的内置命令： 命令名 命令说明 .help 列出所有内置命令。 .backup DBNAME FILE 备份指定的 数据库 到指定的文件，缺省为当前连接的main数据库。 .databases 列出当前连接中所有attached数据库名和文件名。 .dump TABLENAME ... 以SQL文本的格式DUMP当前连接的main数据库，如果指定了表名，则只是DUMP和表名匹配的数据表。参数TABLENAME支持LIKE表达式支持的通配符。 .echo ON|OFF 打开或关闭显示输出。 .exit 退出当前程序。 .explain ON|OFF 打开或关闭当前连接的SELECT输出到Human Readable形式。 .header(s) ON|OFF 在显示SELECT结果时，是否显示列的标题。 .import FILE TABLE 导入指定文件的数据到指定表。 .indices TABLENAME 显示所有索引的名字

一，Redis作缓存服务器 ​ 本篇博客是接着 上一篇 博客未分享完的技术点。 ​ redis作为缓存服务器是众多企业中的选择之一，虽然该技术很成熟但也是存在一定的问题。就是缓存带来的缓存穿透，缓存击穿，缓存失效问题，继而引用分布式锁。 1.1，缓存穿透 ​ 在如今的项目中大多采用垂直的MVC架构，由service层去调用DAO层，然后DAO层再去查询数据库。而redis作为缓存服务器就是在service层去调用DAO层去查询时先去缓存服务器查询，如果存在则直接返回该数据，否则再去查询数据库。由此可知，这么做大量减少了对磁盘I/O的操作，减轻了数据库的压力。 ​ 现在我们假设一种情况，在数据库中存在有id为1到1000的数据。现在如果有人手动去模拟一个id为1001的请求，那么该数据在缓存服务器中是不存在的，因而便会去查询数据库。那么问题来了，如果是一个大量无效的请求去查询数据库。则势必会对数据库造成难以承受的压力，这种情况就是所谓的缓存穿透。 ​ 那如何解决呢？ ​ 1，将查询到的null值直接保存到缓存服务器中，但是这种做法并不推荐，因为如果是大量不同的请求id同样会去查询数据库。 ​ 2，接口的限流，降级与熔断 ​ 在项目中对于重要的接口一定要做限流，对于以上恶意攻击的请求除了要限流，还要做好降级准备，并且进行熔断，这种做法可以有效控制大量无效请求。 ​ 3，布隆过滤器 ​

相信大家对内存数据库的 概念并不陌生，之前园子里也有多位大牛介绍过SQL内存数据库的创建方法，我曾仔细 拜读过，有了大致了解，不过仍有很多细节不清晰，比如 ： （1）内存数据库是把整个数据库放到内存中的吗？ （2）数据都在内存里面，那宕机或者断电了，数据不是没有了吗？ （3）据在内存是怎么存放的，还是按照页的方式吗，一行的大小有限制吗？ （4）内存数据库号称无锁式设计，SQL是如何处理并发冲突的呢？ 相信这些疑问也是大家在思考内存数据库时经常遇到的难题，下文将为大家一一揭开这些问题的面纱，如有不对之处，还请各位看官帮我指出。 一、 内存数据库是如何存储的，只放在内存吗？是把整个数据库放在内存吗？ 答案：不是。 如果你还没有看过宋大侠的博客，建议现在就看看。 http://www.cnblogs.com/CareySon/p/3155753.html 在这篇文章中，我想着重引用如下两个信息： （1） 内存数据库其实就是将指定的表放到内存中，而不是整个数据库； （2）内存数据库用文件流的方式组织磁盘中的数据文件； 我再补充一个信息 （3）内存数据库的数据文件分data file和delta file，而且是成对出现； 1、内存数据库其实就是将指定的表放到内存中，而不是整个数据库； 从宋大侠的博客中可以知道，内存数据库的创建过程其实就是将表存放到内存中，而不是整个数据库。下图展示

导出数据库数据： 首先打开cmd进入MySQL的bin文件夹下 1.导出education数据库里面的users表的表数据和表结构（下面以users表为例） mysqldump -u[用户名] -h[ip] -p[密码] -P[端口号] 数据库名 表名 >导出的文件名.sql mysqldump -uroot -h127.0.0.1 -proot -P3306 education users>d:/user.sql 导出多张表： mysqldump -uroot -proot --databases test --tables t1 t2>two.sql 2. 只导出表结构不导表数据，添加“-d”命令参数 mysqldump -uroot -h127.0.0.1 -proot -P3306 -d education users>d:/user.sql 3.只导出表数据不导表结构，添加“-t”命令参数 mysqldump -uroot -h127.0.0.1 -proot -P3306 -t education users>d:/user.sql 4.导出数据库的表结构和表数据（导入的时候需要指定数据库，保证指定的数据库存在） 导出命令：mysqldump -h127.0.0.1 -P3306 -uroot -proot education >d:/database.sql 导入命令

本文主要介绍如何使用CodeFirst模式来新建并更新数据库 在使用Entity Framwork的三种方式（ModelFist、DBFirst、CodeFirst）中，CodeFirst方式书写的代码最为干净。 至于CodeFist方式的详细优缺点请各位读者自行搜索，这里不多赘述。 1. 使用CodeFirst方式创建数据库 我们新建一个控制台项目，项目中添加两个Model:Author和Blog以及DbContext。 DbContext的添加方式如下： 项目上右键->添加->新建项->ADO.NET Entity Data Model->Empty Code First model 项目代码如下： 1 //默认生成的数据表名为类名+字母s，这里使用TableAttribute来指定数据表名为T_Authors 2 [Table("T_Authors")] 3 public class Author 4 { 5 public int Id { set; get; } 6 public string Name { set; get; } 7 /* 8 此处定义了Blog类型的属性，所以要确保Blog类中至少要有一个表示主键的字段，即public int Id { set; get; }。　　　　　　否则在生成数据表时会报错："EntityType 'Blog' has no

内容摘要：用于管理 ASM 实例的新的 SYSASM 角色、用于降低共享池使用的可变的区大小，以及实例能够读取磁盘组的特定磁盘，这些都是 Oracle 数据库 11g ASM 中引入的一些重要新特性。 　　SYSASM 角色 　　自动存储管理 （ASM） 是在 Oracle 数据库 10g 中引入的，它在某种程度上打破了 DBA 和系统管理员之间在存储分配功能上的界限。ASM 实例由 DBA 管理，正如常规的 DBA 工作需要以 SYSDBA 角色进行连接一样。但是随着时间的推移，角色变得更加清楚，我们看到发生了基本的分工。因此，一些 ASM 操作返还给系统管理员。在某些情况下，会出现单独的一类“ASM 管理员”，他们只进行 ASM 管理，并不涉及数据库管理。 　　然而，这个新角色的出现引发了一个冲突：需要用 SYSDBA 角色来管理 ASM 实例，但运行在同一台服务器上的生产数据库的许多 DBA 感觉很难共享该角色。 　　Oracle 数据库 11g 消除了这个冲突。有一个新角色 SYSASM，只用于管理 ASM 实例。这类似于针对 ASM 实例的 SYSDBA 角色。下面将演示如何连接到 ASM 实例： $ sqlplus / as sysasm SQL*Plus: Release 11.1.0.6.0 - Production on Fri Sep 28 20:37:39

作为一名开发人员，在日常的工作中会难以避免地接触到数据库，无论是基于文件的 sqlite 还是工程上使用非常广泛的 MySQL、PostgreSQL，但是一直以来也没有对数据库有一个非常清晰并且成体系的认知，所以最近两个月的时间看了几本数据库相关的书籍并且阅读了 MySQL 的官方文档，希望对各位了解数据库的、不了解数据库的有所帮助。  添加描述 本文中对于数据库的介绍以及研究都是在 MySQL 上进行的，如果涉及到了其他数据库的内容或者实现会在文中单独指出。 数据库的定义 很多开发者在最开始时其实都对数据库有一个比较模糊的认识，觉得数据库就是一堆数据的集合，但是实际却比这复杂的多，数据库领域中有两个词非常容易混淆，也就是数据库和实例： 数据库：物理操作文件系统或其他形式文件类型的集合； 实例：MySQL 数据库由后台线程以及一个共享内存区组成； 对于数据库和实例的定义都来自于 MySQL 技术内幕：InnoDB 存储引擎 一书，想要了解 InnoDB 存储引擎的读者可以阅读这本书籍。 数据库和实例 在 MySQL 中，实例和数据库往往都是一一对应的，而我们也无法直接操作数据库

Zabbix是什么： Zabbix是由工程师Alexei Vladishev创建，目前有Zabbix SIA在持续开发和支持。Zabbix是一个企业级的分布式开源监控方案。Zabbix是一款能够监控各种网络参数以及服务器健康性和完整性的软件。Zabbix使用灵活的通知机制，允许用户为几乎任何事件配置基于邮件的告警。这样可以快速反馈服务器的问题。基于已存储的数据，Zabbix提供了出色的报告和数据可视化功能。这些功能使得Zabbix成为容量规划的理想方案。Zabbix支持主动轮询和被动捕获。Zabbix所有的报告、统计信息和配置参数都可以通过基于Web前端页面进行访问。基于Web的前端页面可以确保您从任何方面评估您的网络状态和服务器的健康性。适当的配置后，Zabbix可以在IT基础架构监控方面扮演重要的角色。对于只有少量服务器的小型组织和拥有大量服务器的大型公司也同样如此。Zabbix是免费的，Zabbix是根据GPL通用公共许可证第二版编写和发行的。意味着它的源代码都是免费发行的，可供公众任意使用。目前世界各地许多不同规模的组织将Zabbix作为主要的监控平台。 Zabbix监控是一个基于WEB界面的提供分布式系统监控以及网络监控功能的企业级的开源解决方案。Zabbix能监视各种网络参数，保证服务器系统的安全运营，并提供灵活的通知机制让系统管理员快速定位并解决存在的各种问题

Lowdb是轻量化的基于Node的JSON文件数据库。对于构建不依赖服务器的小型项目，使用LowDB存储和管理数据是非常不错的选择。 一：lowdb 使用及安装 在项目中的根目录安装 lowdb 命令如下： npm install --save-dev lowdb lowdb是基于 lodash 构建的，因此我们可以使用任何 lodash 强大的函数。并且我们可以串联使用。 下面我们的目录结构比如是如下： |--- lowdb | |--- node_modules | |--- app.js | |--- package.json 然后我们在app.js 添加如下代码： const low = require('lowdb'); const FileSync = require('lowdb/adapters/FileSync'); const adapter = new FileSync('./db.json'); const db = low(adapter); db.defaults({posts: [], user: {}, count: 0 }).write(); 如上保存后，我们在命令行中执行 node app.js 后，会在我们的项目中的根目录下新建一个叫 db.json 文件，该文件代码变成如下所示： { "posts": [], "user": {},