给DBMS和File System开发者推荐一...-fishcat论 RMAN备份中加filesperset...-使用MAXDOP重复利用多处理器启用SQL Server数据压缩功能

当前位置: 数据库>其它

本页文章导读:

▪给DBMS和File System开发者推荐一篇老文章：Metadata Logging in an NFS Server http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.160.3215&rep=rep1&type=pdf 从年份上看，文章内容有点老。但是，从基本原理来看，对于DBMS和File System的开发者还是有些参考价值的。如果.........

▪fishcat论 RMAN备份中加filesperset的重要性续 fishcat论 RMAN备份中加filesperset的重要性续上篇实验留下了疑问：到底是input到备份集中的所有文件备份完成了，下次备份就不用重复备份，还是因为DELETE INPUT把备份过的文件删除了，下次.........

▪使用MAXDOP重复利用多处理器启用SQL Server数据压缩功能随着数据的越来越大，数据库也越来越大，同时伴随着磁盘空间的增长以及性能的下降。使用SQLServer 2008的数据压缩功能可以大大的减小数据量提高查询性能，尤其对于数据仓库非常有用。（B.........

[1]给DBMS和File System开发者推荐一篇老文章：Metadata Logging in an NFS Server

来源: 互联网发布时间: 2013-11-07

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.160.3215&rep=rep1&type=pdf

从年份上看，文章内容有点老。但是，从基本原理来看，对于DBMS和File System的开发者还是有些参考价值的。

如果你对这些系统的历史有点兴趣，或者因为某些原因需要从历史的角度来理解产品和技术的演变，以它入手

还是不错的选择。做过DBMS的人，不妨从DBMS的角度看看二者有何区别，也可以看到DBMS是如何影响当时

的File System的设计的。记得科泰的陈榕最近说过历史还是很重要的。哈哈。做产品和做科研不一样，产品的

核心和关键点一旦形成后可能很多年都不会做大的改变，因此了解产品的历史确实有助于对它的理解和把握。

作者：zedware 发表于2013-1-6 22:10:55 原文链接

阅读：74 评论：0 查看评论

[2]fishcat论 RMAN备份中加filesperset的重要性续

来源: 互联网发布时间: 2013-11-07

fishcat论 RMAN备份中加filesperset的重要性续

上篇实验留下了疑问：到底是input到备份集中的所有文件备份完成了，下次备份就不用重复备份，
还是因为DELETE INPUT把备份过的文件删除了，下次备份就不用重复备份呢？

今天为了证明，实验如下：

RMAN> run{
2> BACKUP FILESPERSET 2
3> FORMAT '/backup/arch_%T_%s_%p'
4> ARCHIVELOG ALL;
5> }

Starting backup at 07-JAN-13
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=45 recid=56 stamp=803342776
input archive log thread=1 sequence=46 recid=57 stamp=803425515
channel ORA_DISK_1: starting piece 1 at 07-JAN-13
channel ORA_DISK_1: finished piece 1 at 07-JAN-13
piece handle=/backup/arch_20130107_80_1 tag=TAG20130107T053134 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:09
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=50 recid=61 stamp=803968227
input archive log thread=1 sequence=51 recid=62 stamp=803969590
channel ORA_DISK_1: starting piece 1 at 07-JAN-13
c
user interrupt received
Finished backup at 07-JAN-13
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03099: job cancelled at user request

RMAN> run{
2> BACKUP FILESPERSET 2
3> FORMAT '/backup/arch_%T_%s_%p'
4> ARCHIVELOG ALL;
5> }

Starting backup at 07-JAN-13
current log archived
using channel ORA_DISK_1
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=45 recid=56 stamp=803342776
input archive log thread=1 sequence=46 recid=57 stamp=803425515
channel ORA_DISK_1: starting piece 1 at 07-JAN-13
channel ORA_DISK_1: finished piece 1 at 07-JAN-13
piece handle=/backup/arch_20130107_82_1 tag=TAG20130107T053326 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=50 recid=61 stamp=803968227
input archive log thread=1 sequence=51 recid=62 stamp=803969590
channel ORA_DISK_1: starting piece 1 at 07-JAN-13
channel ORA_DISK_1: finished piece 1 at 07-JAN-13
piece handle=/backup/arch_20130107_83_1 tag=TAG20130107T053326 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:02
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=49 recid=60 stamp=803706266
channel ORA_DISK_1: starting piece 1 at 07-JAN-13

user interrupt received
Finished backup at 07-JAN-13
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03099: job cancelled at user request

从边看到sequence45,46,50,51已经完成备份，然而中断后我们继续备份，又开始备份45,46,50,51

list看一下备份情况

RMAN> list backup of archivelog all;
.................................

BS Key Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
61      28.57M     DISK        00:00:05     07-JAN-13
        BP Key: 57   Status: AVAILABLE Compressed: NO Tag: TAG20130107T053134
        Piece Name: /backup/arch_20130107_80_1

List of Archived Logs in backup set 61
Thrd Seq     Low SCN    Low Time Next SCN   Next Time
---- ------- ---------- --------- ---------- ---------
1    45      854175     26-DEC-12 874461     29-DEC-12
1    46      874461     29-DEC-12 913135     30-DEC-12

BS Key Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
62      20.34M     DISK        00:00:02     07-JAN-13
        BP Key: 58   Status: AVAILABLE Compressed: NO Tag: TAG20130107T053134
        Piece Name: /backup/arch_20130107_81_1

List of Archived Logs in backup set 62
Thrd Seq     Low SCN    Low Time Next SCN   Next Time
---- ------- ---------- --------- ---------- ---------
1    50      1016793    03-JAN-13 1045991    06-JAN-13
1    51      1045991    06-JAN-13 1049414    06-JAN-13

BS Key Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
63      28.57M     DISK        00:00:02     07-JAN-13
        BP Key: 59   Status: AVAILABLE Compressed: NO Tag: TAG20130107T053326
        Piece Name: /backup/arch_20130107_82_1

List of Archived Logs in backup set 63
Thrd Seq     Low SCN    Low Time Next SCN   Next Time
---- ------- ---------- --------- ---------- ---------
1    45      854175     26-DEC-12 874461     29-DEC-12
1    46      874461     29-DEC-12 913135     30-DEC-12

BS Key Size       Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
64      20.34M     DISK        00:00:02     07-JAN-13
        BP Key: 60   Status: AVAILABLE Compressed: NO Tag: TAG20130107T053326
        Piece Name: /backup/arch_20130107_83_1

List of Archived Logs in backup set 64
Thrd Seq     Low SCN    Low Time Next SCN   Next Time
---- ------- ---------- --------- ---------- ---------
1    50      1016793    03-JAN-13 1045991    06-JAN-13
1    51      1045991    06-JAN-13 1049414    06-JAN-13

可以看到RMAN备份集中有两份45,46,50,51.

综上证明：是因为DELETE INPUT把备份过的文件删除了（事实上在delete input的时候rman把备份过的文件信息在信息库中删除了，可以用crosscheck archivelog证明），下次备份就不会重复备份。

作者：laoshangxyc 发表于2013-1-6 21:53:18 原文链接

阅读：74 评论：0 查看评论

[3]使用MAXDOP重复利用多处理器启用SQL Server数据压缩功能

来源: 互联网发布时间: 2013-11-07

随着数据的越来越大，数据库也越来越大，同时伴随着磁盘空间的增长以及性能的下降。使用SQLServer 2008的数据压缩功能可以大大的减小数据量提高查询性能，尤其对于数据仓库非常有用。（BestPractices for Data Warehousing with SQL Server 2008：http://msdn.microsoft.com/en-us/library/cc719165.aspx）

但是启用数据压缩是一个很耗费CPU资源的动作，这个过程我们可以充分发挥多CPU的优势？如何实现呢？

比如针对客户表启用PAGE压缩，我们会使用下面的脚本：

ALTER TABLE customerREBUILDWITH(DATA_COMPRESSION=PAGE);

由于数据库使用了8颗CPU在维护期间没有其他应用，这样我们可以充分使用8颗CPU并行执行压缩：

ALTER TABLE customerREBUILDWITH(DATA_COMPRESSION=PAGE,MAXDOP=8);

下面一张图可以看到使用MAXDOP以后的效果。

作者：SmithLiu328 发表于2013-1-7 10:30:22 原文链接

阅读：85 评论：0 查看评论