ITPub博客

首页 > 数据库 > SQL Server > SQL Server收缩数据库

SQL Server收缩数据库

原创 SQL Server 作者:lhrbest 时间:2019-04-24 17:05:41 0 删除 编辑

SQL Server收缩数据库

官网:

https://docs.microsoft.com/zh-cn/sql/t-sql/database-console-commands/dbcc-shrinkfile-transact-sql?view=sql-server-2017


Exec sp_spaceused;
 
 
ALTER DATABASE HKMNewsDB MODIFY FILE ( NAME = N'HKMNewsDB', SIZE = 310390MB );
 
DBCC SHRINKDATABASE(tempdb,1) ;
DBCC SHRINKFILE(1,TRUNCATEONLY);
DBCC SHRINKFILE(1,238238);
 
 
select * from sys.database_files;
 
 
SELECT name ,size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS AvailableSpaceInMB
FROM sys.database_files;


1.1   不能收缩 ID %s 的数据库中 ID %s 的文件,因为它正由其他进程收缩或为空

SQLServer 数据库通常都不建议进行 SHRINKFILE 操作,因为 SHRINKFILE 不当会造成一定的性能问题。

但是当进行了某些操作 ( 例如某个超大的日志类型表转成分区表切换了数据文件 ) ,数据库某个文件组中的剩余空间占了整个磁盘的很大一部分,而且磁盘空间已经吃紧的情况下,你也许会考虑收缩一下某个数据文件。

收缩数据文件时,可以每次收缩一点点(例如每次 5GB )来进行。

然而博主最近对某个数据库进行数据库收缩时碰到了标题所示的困扰。在 DBCC SHRINKFILE (db_name , target_size) 执行了几次之后。

DBCC SHRINKFILE (db_name , target_size)

莫名出现了如下错误:

不能收缩 ID 6 的数据库中 ID 1 的文件,因为它正由其他进程收缩或为空。

据网上的经验,备份之后仍然不变,重启也无效,尝试重建某些表的索引,也无效。

但博主在尝试将数据库文件增加 10MB ,然后再次收缩数据库的时候这个错误消失了。

ALTER DATABASE db_name MODIFY FILE ( NAME = file_name, SIZE = target_size )

后来从官方社区找到了答案:应该是我在进行 DBCC SHRINKFILE 的时候正好同时进行了备份操作(定时日志备份)。

官方给的解决方法就是将要收缩的数据文件增加一点点,哪怕 1MB

 


参考相关文档:

https://msdn.microsoft.com/zh-cn/library/ms189493.aspx



DBCC SHRINKDATABASE (Transact-SQL)

语法

SQL 复制

DBCC SHRINKDATABASE    ( database_name | database_id | 0         [ , target_percent ]         [ , { NOTRUNCATE | TRUNCATEONLY } ]    )   [ WITH NO_INFOMSGS ]

参数

database_name  |  database_id  | 0
要收缩的数据库名称或 ID。   0 指定使用当前数据库。

target_percent
数据库收缩后的数据库文件中所需的剩余可用空间百分比。

NOTRUNCATE
将分配的页面从文件的末尾移动到文件前面的未分配页面。   此操作会压缩文件中的数据。   target_percent  是可选的。   Azure SQL 数据仓库不支持此选项。

文件末尾的可用空间不会返回给操作系统,并且文件的物理大小也不会更改。   因此,指定 NOTRUNCATE 时,数据库似乎不会收缩。

NOTRUNCATE 只适用于数据文件。   NONTRUNCATE 不会影响日志文件。

TRUNCATEONLY
将文件末尾的所有可用空间释放给操作系统。   不移动文件内的任何页面。   数据文件仅收缩到最后指定的盘区。 如果使用 TRUNCATEONLY 指定,则会忽略  target_percent   Azure SQL 数据仓库不支持此选项。

TRUNCATEONLY 将影响日志文件。   若要仅截断数据文件,请使用 DBCC SHRINKFILE。

WITH NO_INFOMSGS
取消严重级别从 0 到 10 的所有信息性消息。

结果集

下表对结果集中的列进行了说明。

列名 描述
DbId 数据库引擎 试图收缩的文件的数据库标识号。
FileId 数据库引擎 尝试收缩的文件的文件标识号。
CurrentSize 文件当前占用的 8 KB 页数。
MinimumSize 文件最低可以占用的 8 KB 页数。   此值与文件的最小大小或最初创建时的大小相对应。
UsedPages 文件当前使用的 8 KB 页数。
EstimatedPages 数据库引擎 估计文件能够收缩到的 8 KB 页数。

 备注

数据库引擎 不显示未收缩的文件的行。

Remarks

 备注

当前,Azure SQL 数据仓库不支持 DBCC SHRINKDATABASE。   不建议运行此命令,因为这是 I/O 密集型操作,可能会使数据仓库离线。   此外,运行此命令后,还会对数据仓库快照产生成本影响。

若要收缩特定数据库的所有数据和日志文件,请执行 DBCC SHRINKDATABASE 命令。   若要一次收缩一个特定数据库中的一个数据或日志文件,请执行  DBCC SHRINKFILE  命令。

若要查看数据库中当前的可用(未分配)空间量,请运行  sp_spaceused

可在进程中的任一点停止 DBCC SHRINKDATABASE 操作,任何已完成的工作都将保留。

数据库不能小于配置的数据库最小大小。   在最初创建数据库时指定最小大小。   或者,最小大小可以是使用文件大小更改操作显式设置的最后大小。   DBCC SHRINKFILE 或 ALTER DATABASE 等操作是文件大小更改操作的示例。

假设最初创建的数据库大小为 10 MB。   然后,它增长到 100 MB。   即使数据库中的所有数据都已删除,数据库可以减少到的最小大小也为 10 MB。

运行 DBCC SHRINKDATABASE 时,请指定 NOTRUNCATE 选项或 TRUNCATEONLY 选项。   如果不这样做,结果与使用 NOTRUNCATE 运行 DBCC SHRINKDATABASE 操作,然后再使用 TRUNCATEONLY 运行 DBCC SHRINKDATABASE 操作相同。

收缩数据库不必处于单用户模式。   其他用户可以在数据库收缩时在其中工作,包括系统数据库。

备份数据库时,无法收缩数据库。   反之,也不能在数据库执行收缩操作时备份数据库。

DBCC SHRINKDATABASE 的工作原理

DBCC SHRINKDATABASE 以每个文件为单位对数据文件进行收缩。然而,DBCC SHRINKDATABASE 在对日志文件进行收缩时,它将视为所有的日志文件都存在于一个连续的日志池中。   文件始终从末尾开始收缩。

假设拥有几个日志文件、一个数据文件和一个名为  mydb  的数据库。   数据文件和日志文件分别是 10 MB,并且数据文件包含 6 MB 数据。   数据库引擎  计算每个文件的目标大小。   此值是文件要收缩到的大小。   如果使用  target_percent  指定 DBCC SHRINKDATABASE ,则  数据库引擎  计算得出的目标大小为收缩后文件中可用空间的  target_percent  数量。

例如,如果为收缩  mydb  将  target_percent  指定为 25,则  数据库引擎  计算得出此文件的目标大小为 8 MB(6 MB 数据加上 2 MB 可用空间)。   因此, 数据库引擎  将数据文件后 2 MB 中的所有数据移动到数据文件前 8 MB 的任何可用空间中,然后对该文件进行收缩。

假设 mydb 的数据文件包含 7 MB 的数据。   将  target_percent  指定为 30,以允许将此数据文件收缩到可用空间的 30%。   但是,将  target_percent  指定为 40 不会收缩数据文件,因为  数据库引擎  将文件收缩到的大小不能小于数据当前占用的空间大小。

还可以用另一种方法来思考此问题:40% 的所要求可用空间加上 70% 的整个数据文件大小(10 MB 中的 7 MB)超过了 100%。   任何大于 30 的  target_size  都不会收缩数据文件。   它不会收缩是因为所需的可用百分比加上数据文件当前占用的百分比大于 100%。

对于日志文件, 数据库引擎  使用  target_percent  计算整个日志的目标大小。   这就是为什么  target_percent  是收缩操作后日志中的可用空间量的原因。   之后,整个日志的目标大小转换为每个日志文件的目标大小。

DBCC SHRINKDATABASE 尝试立即将每个物理日志文件收缩到其目标大小。   假设逻辑日志没有任何部分位于超出日志文件目标大小的虚拟日志中。   然后文件成功截断,DBCC SHRINKDATABASE 完成且没有生成任何消息。 但是,如果部分逻辑日志位于超出目标大小的虚拟日志中,则  数据库引擎  将释放尽可能多的空间,并发出一条信息性消息。   该消息说明需要执行哪些操作来将逻辑日志移出位于文件末尾的虚拟日志。   运行操作后,DBCC SHRINKDATABASE 可用于释放剩余空间。

日志文件只能收缩到虚拟日志文件边界。   这就是为什么不可能将日志文件收缩到小于虚拟日志文件大小的原因。   即使未在使用它也可能无法实现。   虚拟日志文件的大小在创建或扩展这些日志文件时由 数据库引擎 动态选择。

最佳实践

当您计划收缩数据库时,请考虑以下信息:

  • 收缩操作在执行某个操作后最有效。   此操作会创建未使用的空间,例如截断表或删除表操作。
  • 大多数数据库都需要一些可用空间,以供常规日常操作使用。   可能会反复收缩数据库,并注意到数据库大小再次增长。   这种增长表明常规操作需要使用收缩的空间。   在这种情况下,反复收缩数据库是一种无谓的操作。
  • 收缩操作不保留数据库中索引的碎片状态,通常还会在一定程度上增加碎片。   此结果是不要反复收缩数据库的另一个原因。
  • 除非有特定要求,否则不要将 AUTO_SHRINK 数据库选项设置为 ON。

故障排除

收缩操作可能会被在 基于行版本控制的隔离级别 下运行的事务阻止。   例如,在执行 DBCC SHRINK DATABASE 操作时,正在基于行版本控制的隔离级别下运行大型删除操作。   当这种情况发生时,收缩操作会等到删除操作完成后再收缩文件。   收缩操作在等待时,DBCC SHRINKFILE 和 DBCC SHRINKDATABASE 操作会打印输出信息性消息(对于 SHRINKDATABASE 为 5202,对于 SHRINKFILE 为 5203)。   此消息在第一个小时内每五分钟打印到  SQL Server  错误日志一次,然后在后续每个小时打印一次。   例如,如果错误日志包含以下错误消息:

SQL 复制

DBCC SHRINKDATABASE for database ID 9 is waiting for the snapshot    transaction with timestamp 15 and other snapshot transactions linked to    timestamp 15 or with timestamps older than 109 to finish.

此错误表示时间戳早于 109 的快照事务将阻止收缩操作。   该事务是收缩操作完成的最后一个事务。   它还说明  sys.dm_tran_active_snapshot_database_transactions (Transact-SQL)  动态管理视图中的  transaction_sequence_num  或  first_snapshot_sequence_num  列包含值 15。   该视图中的  transaction_sequence_num  或  first_snapshot_sequence_num  列可能包含小于收缩操作完成的最后一个事务 (109) 的数字。   如果是这样,收缩操作将等待这些事务完成。

若要解决此问题,请执行下列任务之一:

  • 终止阻止收缩操作的事务。
  • 终止收缩操作。   所有已完成的工作都会保留。
  • 不执行任何操作,并允许收缩操作等到阻塞事务完成。

权限

要求具有  sysadmin  固定服务器角色或  db_owner  固定数据库角色的成员身份。

示例

A.   收缩数据库并指定可用空间的百分比

以下示例将减小  UserDB  用户数据库中数据文件和日志文件的大小,以便在数据库中留出 10% 的可用空间。

SQL 复制

DBCC SHRINKDATABASE (UserDB, 10);   GO

B.   截断数据库

以下示例将  AdventureWorks  示例数据库中的数据和日志文件收缩到最后指定的盘区。

SQL 复制

DBCC SHRINKDATABASE (AdventureWorks2012, TRUNCATEONLY);


DBCC SHRINKFILE (Transact-SQL)

适用对象: yes SQL Server(从 2008 版开始) yes Azure SQL 数据库 no Azure SQL 数据仓库 no 并行数据仓库

收缩当前数据库的指定数据或日志文件大小。   可以使用它将一个文件中的数据移到同一文件组中的其他文件,这会清空文件,从而允许删除数据库。   可以将文件收缩到小于创建大小,同时将最小文件大小重置为新值。

文章链接图标   Transact-SQL 语法约定

语法

SQL 复制

   DBCC SHRINKFILE    (       { file_name | file_id }        { [ , EMPTYFILE ]        | [ [ , target_size ] [ , { NOTRUNCATE | TRUNCATEONLY } ] ]       }   )   [ WITH NO_INFOMSGS ]

参数

file_name
要收缩的文件的逻辑名称。

file_id
要收缩的文件的标识 (ID) 号。   若要获取文件 ID,请使用  FILE_IDEX  系统函数,或查询当前数据库中的  sys.database_files  目录视图。

target_size
整数,文件的新大小(以 MB 为单位)。   如果未指定,DBCC SHRINKFILE 缩小到文件创建大小。

 备注

可以使用 DBCC SHRINKFILE target_size 缩小空文件的默认大小。   例如,如果创建一个 5 MB 的文件,然后在文件仍然为空的时候将文件收缩为 3 MB,默认文件大小将设置为 3 MB。   这只适用于永远不会包含数据的空文件。

FILESTREAM 文件组容器不支持此选项。
如果 target_size 已指定,DBCC SHRINKFILE 会尝试将文件收缩到目标大小。   要释放的文件区域中的已用页移到文件保留区域中的可用空间。   例如,对于 10MB 数据文件,target_size 为 8 的 DBCC SHRINKFILE 操作会将文件最后 2MB 中的所有已用页移到文件前 8MB 中的任何未分配页区域中。   DBCC SHRINKFILE 不会收缩已超过所需存储数据大小的文件。   例如,如果使用 10 MB 数据文件中的 7 MB,则带有 target_size 为 6 的 DBCC SHRINKFILE 语句只能将该文件收缩到 7 MB,而不能收缩到 6 MB。

EMPTYFILE
将指定文件中的所有数据迁移到同一文件组中的其他文件。   也就是说,EMPTYFILE 将指定文件中的数据迁移到同一文件组中的其他文件。   EMPTYFILE 确保不会将任何新数据添加到文件中(尽管此文件不是只读文件)。   可以使用  ALTER DATABASE  语句删除文件。   如果你使用  ALTER DATABASE  语句更改文件大小,只读标志会重置,并能添加数据。

对于 FILESTREAM 文件组容器,无法使用 ALTER DATABASE 删除文件,除非 FILESTREAM 垃圾回收器已运行,并删除了 EMPTYFILE 已复制到另一个容器的所有不必要文件组容器文件。   有关详细信息,请参阅  sp_filestream_force_garbage_collection (Transact-SQL)

 备注

有关删除 FILESTREAM 容器的信息,请参阅  ALTER DATABASE 文件和文件组选项 (Transact-SQL)  中的相应章节

NOTRUNCATE
无论是否指定 target_percent,将数据文件末尾中的已分配页移到文件开头的未分配页区域中。   操作系统不会回收文件末尾的可用空间,文件的物理大小也不会改变。   因此,如果指定 NOTRUNCATE,文件看起来就像没有收缩一样。   NOTRUNCATE 只适用于数据文件。   日志文件不受影响。   FILESTREAM 文件组容器不支持此选项。

TRUNCATEONLY
将文件末尾的所有可用空间释放给操作系统,但不在文件内部移动任何页。   数据文件只收缩到最后分配的区。 如果使用 TRUNCATEONLY 指定,则会忽略 target_size。
TRUNCATEONLY 选项不会移动日志中的信息,但会删除日志文件末尾的失效 VLF。   FILESTREAM 文件组容器不支持此选项。

WITH NO_INFOMSGS
取消显示所有信息性消息。

结果集

下表描述了结果集列。

列名 描述
DbId 数据库引擎 试图收缩的文件的数据库标识号。
FileId 数据库引擎 试图收缩的文件的文件标识号。
CurrentSize 文件当前占用的 8 KB 页数。
MinimumSize 文件最低可以占用的 8 KB 页数。   此数字对应于文件的大小下限或最初创建大小。
UsedPages 文件当前使用的 8 KB 页数。
EstimatedPages 数据库引擎 估计文件能够收缩到的 8 KB 页数。

Remarks

DBCC SHRINKFILE 适用于当前数据库的文件。   有关如何更改当前数据库的详细信息,请参阅  USE (Transact-SQL)

可以随时停止执行 DBCC SHRINKFILE 操作,并保留任何已完成的工作。   如果你使用 EMPTYFILE 参数并取消操作,文件不会被标记,以防添加其他数据。

当 DBCC SHRINKFILE 操作失败时,则会引发错误。

其他用户可以在文件收缩期间使用数据库,数据库不必处于单用户模式。   无需在单用户模式下运行  SQL Server 实例,即可收缩系统数据库。

收缩日志文件

对于日志文件, 数据库引擎  使用 target_size 计算整个日志的目标大小。   因此,target_size 是执行收缩操作后的日志可用空间。   随后,整个日志的目标大小转换为每个日志文件的目标大小。   DBCC SHRINKFILE 尝试立即将每个物理日志文件收缩到其目标大小。   但是,如果部分逻辑日志位于超出目标大小的虚拟日志中,则 数据库引擎 将释放尽可能多的空间,并发出一条信息性消息。   该消息说明需要执行哪些操作来将逻辑日志移出位于文件末尾的虚拟日志。   执行这些操作以后,DBCC SHRINKFILE 可用于释放剩余空间。

因为日志文件只能收缩到虚拟日志文件边界,所以可能无法将日志文件收缩到小于虚拟日志文件(即使没在使用它)。   数据库引擎 在日志文件创建或扩展时,动态选择虚拟日志文件大小。

最佳做法

在计划收缩文件时,请考虑以下信息:

  • 在执行会产生大量未用空间的操作(如截断表或删除表操作)后,执行收缩操作最有效。

  • 大多数数据库都需要一些可用空间,以供常规日常操作使用。   如果反复收缩数据库,并且它的大小再次增长,那么常规操作可能需要收缩空间。   在这种情况下,反复收缩数据库是一种无谓的操作。

  • 收缩操作不保留数据库中索引的碎片状态,通常还会在一定程度上增加碎片。   此类碎片是不要反复收缩数据库的另一个原因。

  • 按顺序而非同时缩小同一数据库中的多个文件。   对系统表的争用可能会导致阻塞,进而导致延迟。

故障排除

本部分介绍如何诊断和更正在运行 DBCC SHRINKFILE 命令时可能发生的问题。

文件不收缩

如果在执行无错误收缩操作后文件大小未改变,请尝试执行以下操作,验证文件是否有足够的可用空间:

  • 运行以下查询。

SQL 复制

SELECT name ,size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS AvailableSpaceInMB FROM sys.database_files;
  • 运行  DBCC SQLPERF  命令以返回事务日志中使用的空间。

如果可用空间不足,收缩操作无法进一步缩小文件大小。

通常情况下,似乎不收缩的是日志文件。   导致这种不收缩的原因通常是,日志文件尚未截断。   若要截断日志,可以将数据库恢复模式设置为 SIMPLE,或者先备份日志,再重新运行 DBCC SHRINKFILE 操作。

收缩操作受阻

基于行版本控制的隔离级别 下运行的事务可能会阻止收缩操作。   例如,如果在执行 DBCC SHRINK DATABASE 操作时,正在基于行版本控制的隔离级别下运行大型删除操作,那么收缩操作会等到删除操作完成,然后才会继续。   出现这种阻塞时,DBCC SHRINKFILE 和 DBCC SHRINKDATABASE 操作会将信息性消息(对于 SHRINKDATABASE 为 5202,对于 SHRINKFILE 为 5203)打印输出到 SQL Server 错误日志。   在第一个小时内,此消息每五分钟记录一次,之后每一小时记录一次。   例如,如果错误日志包含以下错误消息,则会发生以下错误:

SQL 复制

DBCC SHRINKFILE for file ID 1 is waiting for the snapshot    transaction with timestamp 15 and other snapshot transactions linked to    timestamp 15 or with timestamps older than 109 to finish.

此消息指明,时间戳早于 109(收缩操作完成的最后一个事务)的快照事务正在阻止收缩操作。   它还指明, sys.dm_tran_active_snapshot_database_transactions  动态管理视图中的 transaction_sequence_num 或 first_snapshot_sequence_num 列包含值 15。   如果 transaction_sequence_num 或 first_snapshot_sequence_num 视图列包含的数字小于收缩操作完成的最后一个事务 (109),收缩操作会等待这些事务完成。

若要解决此问题,请执行下列任务之一:

  • 终止阻止收缩操作的事务。
  • 终止收缩操作。   如果收缩操作终止,所有已完成的工作都会保留。
  • 不执行任何操作,并允许收缩操作等到阻塞事务完成。

权限

要求具有  sysadmin  固定服务器角色或  db_owner  固定数据库角色的成员身份。

示例

将数据文件收缩到指定的目标大小

以下示例将  UserDB  用户数据库中名为  DataFile1  的数据文件的大小收缩到 7 MB。

SQL 复制

USE UserDB;   GO   DBCC SHRINKFILE (DataFile1, 7);   GO

将日志文件收缩到指定的目标大小

以下示例将  AdventureWorks  数据库中的日志文件收缩到 1 MB。   若要允许 DBCC SHRINKFILE 命令收缩文件,首先需要通过将数据库恢复模式设置为 SIMPLE 来截断该文件。

SQL 复制

USE AdventureWorks2012;   GO   -- Truncate the log by changing the database recovery model to SIMPLE.   ALTER DATABASE AdventureWorks2012   SET RECOVERY SIMPLE;   GO   -- Shrink the truncated log file to 1 MB.   DBCC SHRINKFILE (AdventureWorks2012_Log, 1);   GO   -- Reset the database recovery model.   ALTER DATABASE AdventureWorks2012   SET RECOVERY FULL;   GO

C.   截断数据文件

下面的示例将截断  AdventureWorks  数据库中的主数据文件。   需要查询  sys.database_files  目录视图以获得数据文件的  file_id

SQL 复制

USE AdventureWorks2012;   GO   SELECT file_id, name   FROM sys.database_files;   GO   DBCC SHRINKFILE (1, TRUNCATEONLY);

D.   清空文件

下面的示例展示了如何清空文件,这样文件就能从数据库中删除。   为了方便此示例进行展示,先创建包含数据的数据文件。

SQL 复制

USE AdventureWorks2012;   GO   -- Create a data file and assume it contains data.   ALTER DATABASE AdventureWorks2012    ADD FILE (       NAME = Test1data,       FILENAME = 'C:\t1data.ndf',       SIZE = 5MB       );   GO   -- Empty the data file.   DBCC SHRINKFILE (Test1data, EMPTYFILE);   GO   -- Remove the data file from the database.   ALTER DATABASE AdventureWorks2012   REMOVE FILE Test1data;   GO

另请参阅

ALTER DATABASE (Transact-SQL)
DBCC (Transact-SQL)
DBCC SHRINKDATABASE (Transact-SQL)
FILE_ID (Transact-SQL)
sys.database_files (Transact-SQL)
收缩文件






About Me

........................................................................................................................

● 本文作者:小麦苗,部分内容整理自网络,若有侵权请联系小麦苗删除

● 本文在itpub( http://blog.itpub.net/26736162 )、博客园( http://www.cnblogs.com/lhrbest )和个人weixin公众号( xiaomaimiaolhr )上有同步更新

● 本文itpub地址: http://blog.itpub.net/26736162

● 本文博客园地址: http://www.cnblogs.com/lhrbest

● 本文pdf版、个人简介及小麦苗云盘地址: http://blog.itpub.net/26736162/viewspace-1624453/

● 数据库笔试面试题库及解答: http://blog.itpub.net/26736162/viewspace-2134706/

● DBA宝典今日头条号地址: http://www.toutiao.com/c/user/6401772890/#mid=1564638659405826

........................................................................................................................

● QQ群号: 230161599 (满) 、618766405

● weixin群:可加我weixin,我拉大家进群,非诚勿扰

● 联系我请加QQ好友 646634621 ,注明添加缘由

● 于 2019-04-01 06:00 ~ 2019-04-30 24:00 在魔都完成

● 最新修改时间:2019-04-01 06:00 ~ 2019-04-30 24:00

● 文章内容来源于小麦苗的学习笔记,部分整理自网络,若有侵权或不当之处还请谅解

● 版权所有,欢迎分享本文,转载请保留出处

........................................................................................................................

小麦苗的微店 https://weidian.com/s/793741433?wfr=c&ifr=shopdetail

小麦苗出版的数据库类丛书 http://blog.itpub.net/26736162/viewspace-2142121/

小麦苗OCP、OCM、高可用网络班 http://blog.itpub.net/26736162/viewspace-2148098/

小麦苗腾讯课堂主页 https://lhr.ke.qq.com/

........................................................................................................................

使用 weixin客户端 扫描下面的二维码来关注小麦苗的weixin公众号( xiaomaimiaolhr )及QQ群(DBA宝典)、添加小麦苗weixin, 学习最实用的数据库技术。

........................................................................................................................

欢迎与我联系

 

 



来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/26736162/viewspace-2642414/,如需转载,请注明出处,否则将追究法律责任。

上一篇: SQL Server的bcp命令
请登录后发表评论 登录
全部评论
QQ:646634621| 网名:小麦苗| 微信公众号:xiaomaimiaolhr| 11g OCM| QQ群:618766405 微信群:私聊| 《数据库笔试面试宝典》作者| OCP、OCM、高可用(RAC+DG+OGG)网络班开讲啦,有需要的小伙伴可以私聊我。

注册时间:2012-09-23

  • 博文量
    1355
  • 访问量
    8249152