数据库中的事务(Transaction)的ACID指的是什么

事务是由一组SQL语句组成的逻辑处理单元，事务具有以下4个属性，通常简称为事务的ACID属性。

ACID是Atomic（原子性）

Consistency（一致性）

Isolation（隔离性）

Durability（持久性）的英文缩写。

Atomic（原子性）：指整个数据库事务是不可分割的工作单位。只有使据库中所有的 *** 作执行成功，才算整个事务成功；事务中任何一个SQL语句执行失败，那么已经执行成功的SQL语句也必须撤销，数据库状态应该退回到执行事务前的状态。

Consistency（一致性）：指数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。例如对银行转帐事务，不管事务成功还是失败，应该保证事务结束后ACCOUNTS表中Tom和Jack的存款总额为2000元。

Isolation（隔离性）：指的是在并发环境中，当不同的事务同时 *** 纵相同的数据时，每个事务都有各自的完整数据空间。

Durability（持久性）：指的是只要事务成功结束，它对数据库所做的更新就必须永久保存下来。即使发生系统崩溃，重新启动数据库系统后，数据库还能恢复到事务成功结束时的状态。

1原子性:就是begin开始一个事务后,在commit或rollback前时全部是一个整体,要全部都完成执行才能进行提交---->>>原子性也就是所有是一个整体

2一致性:事物中有错误的 *** 作所有其他语句不能执行要执行回滚(可能和原子性很像,注意区别开)

3隔离性:不赘述

4持久性:提交事务后不可逆 *** 作

connection就相当于数据库 *** 作中打开了一个事务的连接

此示例中包含了事务的一个批处理Batch

思路是一样的,先将预状态通道中的sql语句添加到批处理中进行就绪等待

等待调用预状态通道执行executeBatch()是开始进行批处理更新数据

之后返回一个int型的状态码数组--->>>产生改变的数据库行数

注意:添加到batch中后执行一定是进行Batch,而不是代码中注释的一行错误示范

数据库日常维护(参考) 数据库日常维护工作是系统管理员的重要职责。其内容主要包括以下几个部分： 一、备份系统数据 SYBASE 系统的备份与恢复机制保证了在系统失败时重新获取数据的可能性。SQL Server 提供了两种不同类型的恢复机制：一类是系统自动完成的恢复，这种措施在每次系统启动时都自动进行，保证了在系统瘫痪前完成的事务都写到数据库设备上，而未完成的事务都被回退；另一类是人工完成的恢复，这是通过 DUMP 和 LOAD 命令来执行人工备份和恢复工作。因此定期备份事务日志和数据库是一项十分重要的日常维护工作。 1、备份数据库 每一个数据库都应在创建之后卸出，从而提供一个装入基点。在此之后按排定的时间周期表卸出。比如每周五卸出数据库。对一般数据库系统卸出数据库周期建议为每周一次。 除了按计划周期卸出数据库之外，还需在每次运行没有日志的 *** 作后卸出数据库。例如： ·每次强制地运行了 DUMP TRAN WITH NO_LOG （因为数据库的磁盘空溢出）； ·每次用 sp_dboption 允许 select into/bulkcopy 做快速拷贝，或用 SELECT INTO 命令创建一个永久性的表，或使用了 WRITETEXT 命令。 卸出数据库的命令为： DUMP DATABASE database_name TO dump_device database_name 是要卸出的数据库名称，dump_device 是卸出设备的名称。用系统过程 sp_helpdevice 可以获得设备的信息。 下面一条命令用来卸出数据库 my_db ： DUMP DATABASE my_db TO db_bk_dev 2、备份事务日志 如果事务日志与数据库放在同一个设备上，则事务日志不应与数据库分开备份。master 数据库和小于 4M 的用户数据库就是这种情况。一般数据库系统的数据库和日志分别放在不同的设备上，因此，可以用 DUMP TRAN 命令单独备份日志。 备份事务日志的周期直接影响数据的恢复程度，因此建议每天备份。 备份事务日志的命令格式为： DUMP TRANsaction database_name [TO dump_device] [WITH TRUNCATE_ONLY|WITH NO_LOG|WITH NO_TRUNCATE] 其中 database_name 是要备份事务的数据库名称，dump_device 是备份设备名称，仅当包含了 WITH TRUNCATE_ONLY 或 WITH NO_LOG 子句时，才可以备份到设备。 注意：如果总是用 DUMP DATEBASE （备份数据库及其日志），而不用 DUMP TRAN ，事务日志将不会刷新，而变得非常庞大。 对于 master 数据库和小型数据库每次运行 DUMP DATEBASE 之后应当运行 DUMP TRANsaction 命令刷新日志 。 下面一条命令备份数据库 db160 的事务日志到备份设备上： DUMP TRANsaction db160 TO db_log_bk_dev WITH TRUNCATE_ONLY 3、备份数据库及其日志间的相互作用 在至少卸出一次数据库前，卸出事务日志是毫无意义的。下图显示了备份数据库及其日志间的关系 如果在星期二下午5：01出现非硬件故障，需要做的所有工作是装入磁带5（参见下一节：数据恢复），由于磁带5是下午5：00刚备份的，因此只有备份和装入之间的一分钟内的数据损失。 但是，如果在星期二下午4：49失效会怎么样呢？在这种情况下，要装入磁带1（在星期五下午5：00的卸出）。然后，依次装入磁带2，3以及4。这样，系统将恢复到星期二上午10：00点的状态，星期二的大部分工作丢失了。此例显示了经常卸出事务的重要性。 二、万一系统失败时恢复数据库系统 如果用户数据库存储的设备失效，从而数据库被破坏或不可存取，通过装入最新的数据库备份以及后来的事务日志备份可以恢复数据库。假设当前的事务日志存在于一个并没有毁坏的设备上，带着 WITH NO_TRUNCATE 选项的 DUMP TRANsaction 命令卸出它。 要恢复数据库按如下步骤去做： 1、如果日志存在于一个分离的设备上，用带着 NO_TRUN

事务管理对于一系列数据库 *** 作进行管理。

一个事务包含一个或多个SQL语句，是逻辑管理的工作单元（原子单元）。

一个事务开始于第一次执行的SQL语句，结束于Commit或Rollback或DDL语句。

注意：其中Commit,Rollback是显示的提交事务，而DDL语句是隐式的提交事务的。DDL语句的 *** 作是没有办法回滚的。

事务处理（TRANSACTION）是由一个或多个SQL语句序列结合在一起所形成的一个逻辑处理单元。事务处理中的每个语句都是完成整个任务的一部分工作，所有的语句组织在一起能够完成某一特定的任务。DBMS在对事务处理中的语句进行处理时，是按照下面的约定来进行的，这就是“事务处理中的所有语句被作为一个原子工作单位，所有的语句既可成功地被执行，也可以没有任何一个语句被执行”。DBMS负责完成这种约定，即使在事务处理中应用程序异常退出，或者是硬件出现故障等各种意外情况下，也是如此。在任何意外情况下，DBMS都负责确保在系统恢复正常后，数据库内容决不会出现“部分事务处理中的语句被执行完”的情况。

CREATE DATABASE database_name

[ ON

[ < filespec > [ ,n ] ]

[ , < filegroup > [ ,n ] ]

]

[ LOG ON { < filespec > [ ,n ] } ]

[ COLLATE collation_name ]

[ FOR LOAD | FOR ATTACH ]

< filespec > ::=

[ PRIMARY ]

( [ NAME = logical_file_name , ]

FILENAME = 'os_file_name'

[ , SIZE = size ]

[ , MAXSIZE = { max_size | UNLIMITED } ]

[ , FILEGROWTH = growth_increment ] ) [ ,n ]

< filegroup > ::=

FILEGROUP filegroup_name < filespec > [ ,n ]

eg

USE master

GO

CREATE DATABASE Mydb

ON

( NAME = Mydb_dat,

FILENAME = 'mydb_datamdf',

SIZE = 2,

MAXSIZE = 50,

FILEGROWTH = 5 )

LOG ON

( NAME = 'Sales_log',

FILENAME = 'mydblogldf',

SIZE = 1MB,

MAXSIZE = 25MB,

FILEGROWTH = 1MB )

GO

只有日志模式的数据库才能进行事务处理

创建时指定数据库日志模式：

CREATE DATABASE database-name [IN DBspace-name]

[WITH {[BUFFERED] LOG | LOG MODE ANSI}]

其中WITH LOG建立非缓冲日志模式数据库；WITH BUFFERED LOG为建立缓冲日志模式数据库；没有WITH LOG时建立的是无日志数据库，此时无法进行事务处理

修改数据库日志模式：

ontape -s -N database-name #无日志模式

ontape -s -B database-name #缓冲日志模式

ontape -s -U database-name #非缓冲日志模式

一、备份系统数据

SYBASE 系统的备份与恢复机制保证了在系统失败时重新获取数据的可能性。SQL Server 提供了两种不同类型的恢

复机制：一类是系统自动完成的恢复，这种措施在每次系统启动时都自动进行，保证了在系统瘫痪前完成的事务都

写到数据库设备上，而未完成的事务都被回退；另一类是人工完成的恢复，这是通过 DUMP 和 LOAD 命令来执行人

工备份和恢复工作。因此定期备份事务日志和数据库是一项十分重要的日常维护工作。

1、备份数据库

每一个数据库都应在创建之后卸出，从而提供一个装入基点。在此之后按排定的时间周期表卸出。比如每周五卸出

数据库。对一般数据库系统卸出数据库周期建议为每周一次。

除了按计划周期卸出数据库之外，还需在每次运行没有日志的 *** 作后卸出数据库。例如：

·每次强制地运行了 DUMP TRAN WITH NO_LOG （因为数据库的磁盘空溢出）；

·每次用 sp_dboption 允许 select into/bulkcopy 做快速拷贝，或用 SELECT INTO 命令创建一个永久性的表，

或使用了 WRITETEXT 命令。

卸出数据库的命令为：

DUMP DATABASE database_name

TO dump_device

database_name 是要卸出的数据库名称，dump_device 是卸出设备的名称。用系统过程 sp_helpdevice 可以获得

设备的信息。

下面一条命令用来卸出数据库 my_db ：

DUMP DATABASE my_db

TO db_bk_dev

2、备份事务日志

如果事务日志与数据库放在同一个设备上，则事务日志不应与数据库分开备份。master 数据库和小于 4M 的用户

数据库就是这种情况。一般数据库系统的数据库和日志分别放在不同的设备上，因此，可以用 DUMP TRAN 命令单

独备份日志。

备份事务日志的周期直接影响数据的恢复程度，因此建议每天备份。

备份事务日志的命令格式为：

DUMP TRANsaction database_name

[TO dump_device]

[WITH TRUNCATE_ONLY|WITH NO_LOG|WITH NO_TRUNCATE]

其中 database_name 是要备份事务的数据库名称，dump_device 是备份设备名称，仅当包含了 WITH

TRUNCATE_ONLY 或 WITH NO_LOG 子句时，才可以备份到设备。

注意：如果总是用 DUMP DATEBASE （备份数据库及其日志），而不用 DUMP TRAN ，事务日志将不会刷新，而变得

非常庞大。

对于 master 数据库和小型数据库每次运行 DUMP DATEBASE 之后应当运行 DUMP TRANsaction 命令刷新日志 。

下面一条命令备份数据库 db160 的事务日志到备份设备上：

DUMP TRANsaction db160

TO db_log_bk_dev

WITH TRUNCATE_ONLY

3、备份数据库及其日志间的相互作用

在至少卸出一次数据库前，卸出事务日志是毫无意义的。下图显示了备份数据库及其日志间的关系

如果在星期二下午5：01出现非硬件故障，需要做的所有工作是装入磁带5（参见下一节：数据恢复），由于磁带5

是下午5：00刚备份的，因此只有备份和装入之间的一分钟内的数据损失。

但是，如果在星期二下午4：49失效会怎么样呢？在这种情况下，要装入磁带1（在星期五下午5：00的卸出）。然

后，依次装入磁带2，3以及4。这样，系统将恢复到星期二上午10：00点的状态，星期二的大部分工作丢失了。此

例显示了经常卸出事务的重要性。

以上就是关于数据库中的事务(Transaction)的ACID指的是什么全部的内容，包括:数据库中的事务(Transaction)的ACID指的是什么、数据库事务集合、如何进行数据库的维护,平时需要做些什么等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！