Wednesday, August 3, 2011

How to insert macros (DFP...) for iframe Ad code?

Use the BOLD text to identify where to insert the DFP Macro. I have edited out sensitive information from the code below, use it to only identify where to place the macro. Use Bannerconnect's javascript tags not their default iframe tags.

**300x250
<**!-- BEGIN STANDARD TAG - 300 x 250 - ROS: Run-of-site - DO NOT MODIFY -->
<**SCRIPT TYPE="text/javascript" SRC="http://ad.bannerconnect.
**net/st?ad_type=ad&ad_size=300x250&section=******&pub_redirect_unencoded=1&pub_redirect=[insert --macro here]">
<**--!-- END TAG -->

**728x90
<**!-- BEGIN STANDARD TAG - 728 x 90 - ROS: Run-of-site - DO NOT MODIFY -->
<**SCRIPT TYPE="text/javascript" SRC="http://ad.bannerconnect.net/st?ad_type=ad&ad_size=728x90&section=*****&pub_redirect_unencoded=1&pub_redirect=[insert macro here]">
<**!-- END TAG -->

source: http://www.google.com/support/forum/p/dfp/thread?tid=0d83afaea2fa892f&hl=en

SQL Server 2008镜像实例

SQL Server 2008镜像的运行模式有3种:1.高性能(异步)2.不带自动故转移功能障的高安全(同步)3.带自动故转移功能障的高安全(同步)。前段时间,为某区市的两台监察数据库做了镜像,模式为高性能(异步),不使用见证服务器。现将步骤总结如下:
1.场景为主体服务器和镜像服务器都没有加入域,在工作组中。
2.主体服务器和镜像服务器上的SQL主服务账户都指定为.\Administrator,并且密码一致。
3.主体服务器和镜像服务器上都在防火墙上设置例外“sqlmirror-5022”,打开TCP5022端口。
4.主体服务器上的准备镜像的数据库LS_SUPERVISIONDB恢复模式必须指定为完整。
5.在主体服务器上不仅要备份数据库文件,还要备份事务日志文件(必须指定为截断选项),用企业管理器操作即可。
6.在镜像服务器分别还原数据库文件和事务日志文件,必须指定为RESTORE WITH NORECOVERY选项。
7.在主体服务器上用企业管理器开始设置镜像,运行模式制定为高性能(异步)。在制定服务账户步骤时,主体和镜像都指定为空即可。
8.镜像成功后,主体服务器显示(主体,已同步),镜像服务器显示(正在还原...)。
以上就是建立镜像的几个步骤。
另外,讲一下如何进行故障恢复的方法。主服务器Down掉后,备机紧急启动并且开始服务的方法:在镜像服务器上执行
USE master
ALTER DATABASE LS_SUPERVISIONDB SET PARTNER FORCE_SERVICE_ALLOW_DATA_LOSS
以上代码执行成功后,镜像服务器上的LS_SUPERVISIONDB显示状态为(主体,已断开连接)。

主体服务器开机后,镜像服务器未进行主备切换前的状态如下:
镜像服务器上LS_SUPERVISIONDB显示状态为(主体,挂起)
主体服务器上LS_SUPERVISIONDB显示状态为(正在还原...)

原来的主服务器恢复,可以继续工作,需要重新设定镜像。将主体服务器启动后,在镜像服务器上执行
USE master
ALTER DATABASE LS_SUPERVISIONDB SET PARTNER RESUME; --恢复镜像
ALTER DATABASE LS_SUPERVISIONDB SET PARTNER SAFETY FULL --事务安全,同步模式
ALTER DATABASE LS_SUPERVISIONDB SET PARTNER FAILOVER; --切换主备
以上代码执行成功后,主体服务器显示(主体,已同步),镜像服务器显示(正在还原...)。在主体服务器上使用企业管理器将镜像的运行模式由“不带自动故转移功能障的高安全(同步)”改为高性能(异步)。到此,一次故障转移成功实现。

source: http://www.cnblogs.com/qdzhbsh/archive/2010/12/03/1895664.html

数据库服务器高可用、高性能和高保护配置

很多公司保护数据,最先用到的基本都是备份(这个是必不可少,也是最节约成本的方法了),基本的备份有三种,全备、差异和日志(当然还有基于文件、文件 组、Page等的备份方案,不做讨论),如何合理的安排这些备份计划,需要根据应用系统的业务要求和特点来定,还得考虑备份文件的保留时间、备份频率等。
本地备份
image
但是随着数据量的增加,同时考虑一些安全性的原因,将数据都保存到本机硬盘的方案变得不可取,于是考虑购买一台磁带机,将备份的数据从本地磁盘,转 移到磁带机上,本地磁盘只保留一份最新的全套备份;一方面可以解决磁盘空间问题,同时还将数据备份到了其他设备中,增强了数据的安全性。
磁带机备份
image
有了完善的数据库备份方案,视乎我们的数据得到了有效的保护,但是想象下,如果我们的服务器真出现故障,服务器起不来了,该怎么做呢?当然是按我们 的备份计划,将数据从最新的全备份开始,然后差异,然后再日志还原过来;假定我们的备份文件100%的可用(不可用的情况也经常发生哦),如果数据库小, 那不久就可以还原好,但是如果是个几百G的数据库,要按这样一步步还原,而此时后面一堆人都挂着等你的数据库恢复,boss过两分钟过来问下情况,手里的 电话被各个需要使用的部门打爆…,这时候没有强悍的心理素质,估计早就崩溃了;并且备份还有时间选择,比方你一个小时备份一个日志文件,但是如果数据库某 天运行到1:50分左右突然挂掉了,此时如果备份不到最后50分钟的日志信息,那你这50分钟所产生的数据就找不回了。
正因为这样的备份恢复方案无法达到我们及时恢复数据库和最大限度保障数据的要求,于是我们不得不考虑其他更快恢复数据并减少数据丢失的方案,我们先 考虑SQLServer给我们提供的方案(硬件方案后面讨论),数据库里面有两种技术方案可以使用,一种是Mirroring,另一种是Log shipping(两种技术的细节这里不讨论)。
Mirroring/Logshipping
image
有了mirroring和log shipping(称备机),我们不但缩短了数据库恢复的时间,减少了数据丢失的可能,还可以将某些不需要完全实时的操作放到备机上(如:BI抽取数据, 做报表等),真是一举两得;不过,采取Mirroring和Logshipping会增加服务器的负担(不过一般都可以接受),Mirroring技术的 高安全性可以最大限度保护数据不丢失,但对主服务器影响较大(需要等待备服务器响应和回传信息),高可用性能提高恢复数据库上线的速度,但是需要增加一台 见证机,高可用性对数据的保护要稍微差点(主要取决于服务器性能和网络带宽),但对主服务器性能影响较小;而Log shipping是定期备份日志,然后传到备机上还原,数据丢失多少取决于备份和传送的频率,同时这两项技术还增加了部分硬件投入(需要备机)。
这样做之后,对一些普通的系统基本都可以应付了,但是对那些需要7×24小时不间断提供服务的应用还是有所不足;例如:如果我们数据库服务器一块网 卡坏了,或者操作系统崩溃了(但数据库本身没问题),那我们不得不停止业务来进行更换网卡或者启用备机来提供服务,影响了业务的进行;想象一下,淘宝这类 的在线交易购物网站,一天的交易笔数有多少,当机一分钟都可能有上千万的损失(个人估计,没实际调研,淘宝也不用SQLServer,呵呵),为应对这些 在线时间要求高的情况,我们的Cluster就应运而生了。
Cluster通过用两台服务器来连接一个数据库(形式有多种),也就是说两套硬件服务器和两套操作系统来支持一个数据库系统的运行,数据都存放到 磁盘阵列中,磁盘阵列可以采用Raid技术来提供磁盘的冗余;这样相当于为SQLServer提供了两套访问设备,一套坏了,另一套立马可以顶替过来,这 大大缩短了故障恢复的时间,差不多只相当于重启了一次数据库而已,(当然还有资源转移的时间,但一般不会太长),不过这样设备投入就更多了。
Cluster
image
通过这些技术后,数据保护和在线能力都有了很大的提高,但是这么多的操作都集中到了存储上,当访问量很大时,存储就成了数据库系统的瓶颈,那该如何 处理呢?有两种思路,一提高存储系统的性能,使用转速更快,性能更好的磁盘,所以现在出现了很火的SSD;二拆分业务或者是使用读写分离,将对一台数据库 的访问分散到多台机器上,减轻单台的压力。
SSD磁盘
image
读写分离
image
业务拆分
image
这样就足够了吗?知道911吗?像911那样的事故,可能我们都不会遇到,但是,电信机房起火事件发生的概率还是有的(里面机器多呀),如果这样的 情况发生,如果我们没有提前做好应对方案的话,一切就都over了;于是异地容灾就被提出来了,主要有异地备份和异地机房方案(异地备份就不讲啦);如果 建了异地机房,那怎么样同步数据就是个头大的问题,目前大部分硬件提供商提供的方案是磁盘同步的方案,两地机房之间用光纤相连(成本呀),当A机房的某个 磁盘写数据时,通过光纤将这些数据传到B机房对应的磁盘上,这样就完成了两个磁盘数据的同步(至于这个同步有多大的延时,就不好说啦);A、B机房采用同 样的架构,正常情况下只有A机房的磁盘对外提供服务,B机房的磁盘不提供对外访问(起码不能写),一旦A机房真的被毁了,那B机房的这些设备就可以开启, 用来提供对外的服务。
异地容灾(磁盘同步技术)
image