°Ò¹¢éÍÁÙÅ·ÕèãªéÃèÇÁ¡Ñ¹ scalable ä´éÃѺ¡ÒÃʹѺʹع â´Â SQL Server 2005

°Ò¹¢éÍÁÙÅ·ÕèãªéÃèÇÁ¡Ñ¹ scalable ä´éÃѺ¡ÒÃʹѺʹع â´Â Microsoft SQL Server 2005 ͧ¤ì¡Ã Edition º·¤ÇÒÁ¹Õé¤×Í µÑÇÍÂèÒ§¢Í§ËÑÇ¢éÍ "¡Òðҹ¢éÍÁÙÅ¡ÒÃãªéÃèÇÁ¡Ñ¹ Scalable" ·Õè¨Ð¶Ù¡»ÃСÒÈ㹡ÒûÃѺ»Ãاã¹Í¹Ò¤µ¢Í§ SQL Server ˹ѧÊ×ÍÍ͹äŹì

scalable °Ò¹¢éÍÁÙÅ·ÕèãªéÃèÇÁ¡Ñ¹

°Ò¹¢éÍÁÙÅ·ÕèãªéÃèÇÁ¡Ñ¹ scalable ªèÇÂãËé¤Ø³á¹º°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹẺÍèÒ¹ÍÂèÒ§à´ÕÂǡѺÍÔ¹Êáµ¹«ì¢Í§à«ÔÃì¿àÇÍÃìËÅÒº¹à¤Ã×Í¢èÒ¾×é¹·Õèà¡çº¢éÍÁÙÅ (SAN) °Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹà»ç¹°Ò¹¢éÍÁÙÅẺÍèÒ¹ÍÂèÒ§à´ÕÂÇ·ÕèÊÃéÒ§¨Ò¡°Ò¹¢éÍÁÙÅ¡ÒüÅÔµÍÂèÒ§ ¹éÍÂ˹Öè§ÃÒ¡Ò÷Õè¨Ðãªéâ´Â੾ÒÐÊÓËÃѺÃÒ§ҹ àÁ×è͵éͧ¡ÒèзÓŧ㹰ҹ¢éÍÁÙÅ·ÕèãªéÃèÇÁ¡Ñ¹áºº scalable °Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹµéͧÍÂÙèã¹ä´Ã¿ìÍÂèÒ§ ¹éÍÂ˹Öè§â´Â੾ÒÐẺÍèÒ¹ÍÂèÒ§à´ÕÂÇ¢éÍÁÙÅ Çѵ¶Ø»ÃÐʧ¤ìËÅÑ¡¢Í§ä´Ã¿ì¢éÍÁÙÅẺÍèÒ¹ÍÂèÒ§à´ÕÂÇàËÅèÒ¹Õéà»ç¹âÎʵì°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹËÃ×ͪش¢Í§¡ÒÃÃÒ§ҹ°Ò¹¢éÍÁÙÅ·ÕèãªéÃèÇÁ¡Ñ¹ ÇÍÅØèÁàËÅèÒ¹Õé·Õè¨ÐàÃÕ¡¡Ñ¹ÇèÒ¡ÒÃÃÒ§ҹ¡ÒÃä´Ã¿ì¢éÍÁÙÅ

»ÃÐ⪹ì

scalable °Ò¹¢éÍÁÙÅ·ÕèãªéÃèÇÁ¡Ñ¹ÁÕ»ÃÐ⪹ìµèÍ仹Õé:

• áÊ´§»ÃÔÁÒ³ÁÒµÃÒÊèǹÍÍ¡¢Í§°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹ â´Âãªéà«ÔÃì¿àÇÍÃìªØ´ÊÔ¹¤éÒ °Ò¹¢éÍÁÙÅ·ÕèãªéÃèÇÁ¡Ñ¹áºº scalable ¤×Í ÇÔ¸Õ cost-effective ¡Ò÷ÓãËé marts ¢éÍÁÙÅẺÍèÒ¹ÍÂèÒ§à´ÕÂÇËÃ×ͤÅѧÊÔ¹¤éҢͧ¢éÍÁÙÅ·Õè¾ÃéÍÁãªé§Ò¹ÊÓËÃѺÍÔ¹Êáµ¹«ìà«ÔÃì¿àÇÍÃìËÅÒÂÊÓËÃѺÃÒ§ҹ àªè¹¡ÒÃÃѹ¡ÒÃÊͺ¶ÒÁ ËÃ×ÍãªéºÃÔ¡ÒÃÃÒ§ҹ¢Í§ SQL Server 2005
• ãËéᡵèÒ§ËÒ¡»ÃÔÁÒ³ áµèÅÐà«ÔÃì¿àÇÍÃìãªé˹èǤÇÒÁ¢Í§µ¹àͧ¨Ó CPU áÅÐtempdbdatabase.
• ÃѺ»ÃСѹÁØÁÁͧà´ÕÂǡѹ¢Í§¡ÒÃÃÒ§ҹ¢éÍÁÙŨҡà«ÔÃì¿àÇÍÃì·Ñé§ËÁ´¶éÒÍÔ¹Êáµ¹«ìà«ÔÃì¿àÇÍÃì·Ñé§ËÁ´¨Ð¶Ù¡¡Ó˹´¤èҵç µÑÇÍÂèÒ§àªè¹ à«ÔÃì¿àÇÍÃì·Ñé§ËÁ´¨Ðãªéà»ÃÕºà·Õº·Õèà´ÕÂǡѹ
  
  ËÁÒÂà˵Ø:ÍÕ¡ÇÔ¸Õ˹Ö觤×Í ¤Ø³ÊÒÁÒö»ÃѺ»Ãا°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹº¹ä´Ã¿ì¢éÍÁÙÅ·ÕèÊͧ·ÕèÃÒ§ҹ ÊÓËÃѺ¢éÍÁÙÅà¾ÔèÁàµÔÁ ãËé´Ù·ÕèÊèǹ "¢ÂÒÂãË­èÊØ´·Õè¾ÃéÍÁãªé§Ò¹¢Í§°Ò¹¢éÍÁÙÅ scalable ·ÕèãªéÃèÇÁ¡Ñ¹"

¢éͨӡѴ

ÁÕ¢éͨӡѴµèÍ仹ÕéÊÓËÃѺ°Ò¹¢éÍÁÙÅ scalable ·ÕèãªéÃèÇÁ¡Ñ¹:

• °Ò¹¢éÍÁÙŵéͧÍÂÙ躹ä´Ã¿ì¢éÍÁÙÅẺÍèÒ¹ÍÂèÒ§à´ÕÂÇ
• á¿éÁ¢éÍÁÙÅ·ÕèÊÒÁÒöà¢éÒ¶Ö§ä´é¼èÒ¹¡Òà SAN
• °Ò¹¢éÍÁÙÅ·ÕèãªéÃèÇÁ¡Ñ¹ scalable ä´éÃѺ¡ÒÃʹѺʹع㹠Microsoft Windows Server 2003 Service Pack 1 (SP1) ËÃ×Í Windows Server 2003 ÃØè¹·ÕèãËÁè¡ÇèÒà·èÒ¹Ñé¹

¡ÒûÃѺ»ÃاÃͺ¢Í§°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹ

àÁ×èͤسãªé°Ò¹¢éÍÁÙÅ scalable ·ÕèãªéÃèÇÁ¡Ñ¹ÊÓËÃѺ°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹ Áѹà¡ÕèÂÇ¢éͧÃͺ¡ÒûÃѺ»Ãا¢Ñ鹵͹·Õè 3:

• ÊÃéÒ§¢Ñ鹵͹: Ãͺ¡ÒûÃѺ»Ãا¢Í§°Ò¹¢éÍÁÙÅ·ÕèÃÒ§ҹàÃÔèÁµé¹ ´éÇ¢Ñ鹵͹¢Í§¡ÒÃÊÃéÒ§ ¡è͹·Õè¨ÐÊÒÁÒö¶Ù¡ÊÃéÒ§°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹ ¼Ùé´ÙáÅÃкº mounts »ÃÔÁÒ³·ÕèÃÒ§ҹã¹Ãкº¡ÒüÅÔµ áÅзÓãËéÍèÒ¹/à¢Õ¹ àÁ×èÍä´Ã¿ì¢éÍÁÙÅ·ÕèÍÂÙèã¹Ê¶Ò¹Ð¡ÒÃÍèÒ¹/à¢Õ¹ ä´Ã¿ì¢éÍÁÙÅ·ÕèÊÒÁÒöà·èÒ¹Ñé¹ÊÒÁÒöàÁҷ캹Ãкº·Õè˹Öè§ ËÒ¡ä´Ã¿ì¢éÍÁÙŶ١àÁҷ캹ÃкºÁÒ¡¡ÇèÒ˹Öè§ ¤ÇÒÁàÊÕÂËÒ filesystem ÍÒ¨à¡Ô´¢Öé¹ ¼Ùé´ÙáÅÃкºáÅéÇÊÃéÒ§°Ò¹¢éÍÁÙÅ â´ÂãªéÇÔ¸Õ¡ÒäѴÅÍ¡¢éÍÁÙÅ·ÕèÁÒ¨Ò¡ SQL Server 2005 ÊÓËÃѺ¡ÒäѴÅÍ¡¢éÍÁÙÅËÃ×Í°Ò¹¢éÍÁÙÅÍÂèÒ§ã´ÍÂèҧ˹Öè§ ËÅѧ¨Ò¡·ÕèÊÃéÒ§°Ò¹¢éÍÁÙÅ ¼Ùé´ÙáŵÑ駤èÒä´Ã¿ì¢éÍÁÙÅẺÍèÒ¹ÍÂèÒ§à´ÕÂÇ áÅШҡ¹Ñé¹ dismounts
• Ṻ¢Ñ鹵͹: ÃÐÂÐ attach ¡ÒÃÁÒËÅѧ¨Ò¡¢Ñ鹵͹¡ÒÃÊÃéÒ§§Ò¹ ¢Ñ鹵͹¡Òà attach ·Ó°Ò¹¢éÍÁÙžÃéÍÁãªé§Ò¹à»ç¹°Ò¹¢éÍÁÙÅ scalable ·ÕèãªéÃèÇÁ¡Ñ¹ ¢Ñ鹵͹¡Òà attach µéͧÊÒÁÒö·Óä´éã¹áµèÅСÒÃÃÒ§ҹà«ÔÃì¿àÇÍÃìáµèÅÐÃÒ¡Òà ¡ÒáÓ˹´¤èÒ°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹà»ç¹°Ò¹¢éÍÁÙÅ·ÕèãªéÃèÇÁ¡Ñ¹áºº scalable ¼Ùé´ÙáÅÃкº mounts ẺÍèÒ¹ÍÂèÒ§à´ÕÂÇà¾×èÍ¡ÒÃÃÒ§ҹÇÍÅØèÁäÇ麹à«ÔÃì¿àÇÍÃìÃÒ§ҹ¼èÒ¹ SAN ËÅѧ¨Ò¡·Õè¼Ùé´ÙáÅ·ÓãËéá¹èã¨ÇèÒ áµèÅÐä´Ã¿ì¢éÍÁÙŶ١µÑ駤èÒ¡ÒÃÍèÒ¹ÍÂèÒ§à´ÕÂÇ ¼Ùé´ÙáÅÃкºá¹º°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹº¹ÍÔ¹Êáµ¹«ì¢Í§ SQL Server °Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹº¹ÍÔ¹Êáµ¹«ì¢Í§ SQL Server ¨ÐàÃÕ¡ÇèÒÍÔ¹Êáµ¹«ì¢Í§à«ÔÃì¿àÇÍÃìÃÒ§ҹ à¹×èͧ¨Ò¡ä´Ã¿ì¢éÍÁÙÅáµèÅÐÃÒ§ҹà»ç¹áººÍèÒ¹ÍÂèÒ§à´ÕÂÇ á¹º°Ò¹¢éÍÁÙÅ¡Ó˹´äÇéà¾×èÍÍèÒ¹ÍÂèÒ§à´ÕÂÇ ³¨Ø´¹Õé °Ò¹¢éÍÁÙÅ·ÕèÁÕ¡ÒÃÃÒ§ҹÁÕ °Ò¹¢éÍÁÙÅãªéÃèÇÁ¡Ñ¹áºº scalable ·ÕèÊÒÁÒöà¢éÒ¶Ö§ä´é â´Âä¤Åà͹µì â´Âãªéà«ÔÃì¿àÇÍÃìÃÒ§ҹ
  
  ËÁÒÂà˵Ø:¶éҤسãªéä´Ã¿ì¢éÍÁÙÅ·ÕèÊͧ·ÕèÃÒ§ҹàÁ×èͤس·Ó¡ÒûÃѺ»Ãا°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹ ¤Ø³µéͧàÅ×Í¡ÃÐËÇèÒ§¡ÒûÃѺÃØè¹ rolling áÅСÒûÃѺÃØè¹·Õè»ÃѺãËéµÃ§¡Ñ¹ For more information, see the "Maximize the availability of a scalable shared database" section.
• Detach phase: The third phase is the detach phase. Typically, the reporting database eventually becomes stale. The database must be refreshed to keep the reporting data current. The detach phase is the process of removing a stale reporting database from service as a scalable shared database. Before you can make an updated reporting database available on a particular reporting server, the detach phase must be completed on that server. When a reporting database must be refreshed, it must be detached from all the server instances. To start the detach phase, the database administrator first stops the query work load that is coming in to the database from all the server instances. On each server instance, the database administrator obtains exclusive access to the database, and then detaches it. The database administrator then dismounts the volume from each host system. When the detach phase is complete, the reporting volume is disconnected from the SAN.

ËÁÒÂà˵Ø:To maximize the availability of reporting data, we recommend that you alternate update cycles between two reporting volumes as a best practice. When the first reporting volume is still mounted to the reporting servers, you can mount the second volume to the production server, and then build an up-to-date version of the reporting database. For more information, see the "Maximize the availability of a scalable shared database" section.

ËÁÒÂà˵Ø:Each phase consists of a series of steps that must be performed by a user who has Database Administrator rights. In this article, that user will be referred to as the database administrator.

ÊÔè§ÊӤѭTo configure a scalable shared database, the SAN environment must already be working correctly.

Examples of scalable shared databases

In subsequent update cycles, the database can be updated or rebuilt. The preferred method depends on your business requirements. You can use scalable shared databases in the following two ways:

• Data mart database: The simplest use of a scalable shared database is a data mart database. A data mart database is extracted periodically from the contents of a data warehouse and is used for reporting. To update the data mart database, drop the database and then replace it with a new version.
• Reporting from an updatable database: When the database that is being reported from does not have to be transformed from the source database, the database can be periodically updated. To periodically update the database, create a full backup of the production database, and then restore the database backup on the reporting volume or volumes.

Make sure that the environment is correct for a scalable shared database

A scalable shared database must be on a read-only volume that can be accessed over a SAN. The reporting servers must be running the following:

• Windows Server 2003 SP1 or a later version of Windows Server 2003
• SQL Server 2005 Enterprise Edition or a later version of SQL Server 2005

For supportability, we recommend that you limit your scalable shared database configurations to eight server instances. However, SQL Server 2005 does not limit the number of concurrent instances that can access a scalable shared database. Typically, each server instance runs on a separate reporting server. However, running multiple reporting server instances on a reporting server is supported.

Configure your environment

To make sure that your environment supports scalable shared databases, we recommend that you follow these guidelines:

• Make sure that the reporting servers for a particular reporting database are running on identical operating systems. Whenever you upgrade a reporting server, upgrade any other reporting servers that serve the same scalable shared database or databases. For example, if you apply a software update or service pack for Windows or SQL Server 2005 to any one of the reporting servers, apply the same software update or service pack to all the reporting servers.
  
  ËÁÒÂà˵Ø:Frequently, you can perform rolling upgrades of the reporting servers as long as you complete the rolling upgrade in a timely manner.
• Scalable shared databases are tested under a concurrent access workload by up to eight server instances of SQL Server 2005 Enterprise Edition. SQL Server 2005 does not enforce an instance limit. However, we recommend that you limit your scalable shared database configurations to eight server instances for each shared database.
• If the data files of the production database span multiple volumes, you must use the same number of reporting volumes. In contrast, because the reporting database is set to read-only, its log files can co-exist with data files on a reporting volume.
• àÁ×è͵éͧ¡Ò÷ÓãËé¡Ãкǹ¡ÒÃÊÃéÒ§ ËÃ×Í»ÃѺ»Ãا°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹ àÃÒ¢Íá¹Ð¹ÓÇèÒ àÊé¹·Ò§¢Í§°Ò¹¢éÍÁÙÅ·ÕèÃÒ§ҹ¨ÐàËÁ×͹¡Ñº°Ò¹¢éÍÁÙÅ¡ÒüÅÔµ «Öè§ÃÇÁ¶Ö§¡ÒÃãªé·Ñé§ÊͧẺà´ÕÂǡѺÍÑ¡ÉÃä´Ã¿ìÊÓËÃѺä´Ã¿ì¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹáÅÐàÊé¹·Ò§ä´àá·ÍÃÕà´ÕÂÇÊÓËÃѺ°Ò¹¢éÍÁÙÅ µÑÇÍÂèÒ§àªè¹ ¶éÒ°Ò¹¢éÍÁÙÅ¡ÒüÅÔµº¹ E:\SQLdata ãªé E à»ç¹ÍÑ¡ÉÃÃкØä´Ã¿ì¢Í§ÇÍÅØèÁÃÒ§ҹ ¶éÒà»ç¹ä» ¹Í¡¨Ò¡¹Õé ãªé \SQLdata à»ç¹ä´àá·ÍÃբͧ°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹ ¶éÒà»ç¹ä» ÍÂèÒ§äáçµÒÁ ʤÃÔ»µì·ÕèÁÕàÊé¹·Ò§·ÕèªÑ´à¨¹ÊÒÁÒö¨Ñ´¡ÒÃÁÕ¤ÇÒÁᵡµèÒ§ ËÒ¡ä´Ã¿ì¢éÍÁÙÅ·ÕèÁÕ¡ÒÃÃÒ§ҹãªéÍÑ¡ÉÃÃкØä´Ã¿ìÍ×蹹͡à˹×ͨҡä´Ã¿ì¢éÍÁÙÅ¡ÒüÅÔµ ¤Ø³ÍÒ¨µéͧ·Ó¡ÒûÃѺà»ÅÕè¹µèÍ仹Õé:
  • ¶éҤسÊÃéÒ§°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹ â´Â¡Òä׹¤èÒÊÓà¹ÒÊÓÃͧ°Ò¹¢éÍÁÙÅ §º¡Òä׹¤èÒ°Ò¹¢éÍÁÙŵéͧÁÕ͹ػÃÐ⤠WITH ÂéÒ·ÕèÃкØàÊ鹷ҧẺàµçÁ¢Í§á¿éÁ¢éÍÁÙÅ·Õè¤×¹¤èÒ
  • ¶éÒ°Ò¹¢éÍÁÙÅ·ÕèÁÕ¡ÒÃÃÒ§ҹ¢Í§¤Ø³ÁÕÊÓà¹Ò¢Í§°Ò¹¢éÍÁÙÅ¡ÒüÅÔµ ͹ػÃÐ⤠FOR Ṻ¢Í§¤ÓªÕéᨧÊÔ·¸Ôì㹡ÒÃÊÃéÒ§°Ò¹¢éÍÁÙŵéͧáÊ´§ÃÒ¡Ò÷ءá¿éÁ ͹ػÃÐ⤠FOR ṺµéͧÃкØàÊ鹷ҧẺàµçÁàÁ×èͤسṺ°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹ ÍÂÙèàÊÁÍà»ç¹ÇÔ¸Õ»¯ÔºÑµÔ·Õè´Õ·ÕèÊØ´
    
    ËÁÒÂà˵Ø:¾Ö§ ãªéÍÑ¡ÉÃÃкØä´Ã¿ìà´ÕÂǡѹº¹à«ÔÃì¿àÇÍÃì·Ø¡ æ àÁ×èͤس¡Ó˹´ãªéä´Ã¿ì¢éÍÁÙÅẺà¾×èÍ¡ÒÃÃÒ§ҹä»Âѧà«ÔÃì¿àÇÍÃìÃÒ§ҹ¢Í§¤Ø³ ¡Òý֡¡ÒùÕéªèǤس㹡ÒèѴ¡ÒÃä´Ã¿ì¢éÍÁÙÅä»Âѧà«ÔÃì¿àÇÍÃì·ÕèᵡµèÒ§¡Ñ¹
• °Ò¹¢éÍÁÙÅ·ÕèÁÕ¡ÒÃÃÒ§ҹµéͧÍÂÙ躹ä´Ã¿ì¢éÍÁÙÅẺÍèÒ¹ÍÂèÒ§à´ÕÂÇ·ÕèÊÒÁÒöà¢éÒ¶Ö§¼èÒ¹ SAN ¨Ò¡à«ÔÃì¿àÇÍÃìÃÒ§ҹ·Ñé§ËÁ´:
  • ËÅѧ¨Ò¡·Õè¤Ø³¡Ó˹´ãªéä´Ã¿ì¢éÍÁÙÅ·Õè¶Ù¡µéͧà¾×èÍ¡ÒÃÃÒ§ҹä»Âѧà«ÔÃì¿àÇÍÃìÃÒ§ҹ µÃǨÊͺãËéá¹èã¨ÇèÒ ä´Ã¿ì¢éÍÁÙÅ·ÕèÁÕ¡ÒÃÃÒ§ҹ·ÕèÁÕ¡ÒáÓ˹´ãªéÍÂèÒ§¶Ù¡µéͧ áÅÐÇèÒ á¿éÁ¢éÍÁÙÅ·ÕèÊÒÁÒöà¢éÒ¶Ö§ àÁ×è͵éͧ¡Ò÷Óàªè¹¹Õé »é͹dir<drive-letter></drive-letter>:\<database-directory></database-directory>˹éҨ;ÃéÍÁÃѺ¤ÓÊÑè§ ·Õèã´<drive-letter></drive-letter>à»ç¹µÑÇÍÑ¡É÷Õè¡Ó˹´ãËé¡Ñºä´Ã¿ì¢éÍÁÙÅÃÒ§ҹ áÅÐ<database-directory></database-directory>ÃкصÓá˹觷ÕèµÑ駢ͧá¿éÁ¢éÍÁÙŢͧ°Ò¹¢éÍÁÙÅ·ÕèÍÂÙ躹ä´Ã¿ì¢éÍÁÙÅ Ãѹ¡Ò÷´Êͺ¹Õé¨Ò¡à«ÔÃì¿àÇÍÃìáµèÅÐÃÒ§ҹà¾×èÍãËéá¹èã¨ÇèÒ ¤Ø³ä´éÃѺ¼ÅÅѾ¸ìà´ÕÂǡѹÊÓËÃѺ·Ñé§ËÁ´
  • àÁ×è͵éͧ¡ÒõÃǨÊͺãËéá¹èã¨ÇèÒ °Ò¹¢éÍÁÙÅ·ÕèÁÕ¡ÒÃÃÒ§ҹ·Õè¶Ù¡µÑ駤èÒẺÍèÒ¹ÍÂèÒ§à´ÕÂÇ ¾ÂÒÂÒÁÊÃéÒ§á¿éÁº¹ä´Ã¿ì¢éÍÁÙÅ ÇÔ¸Õ¡Ò÷Õè§èÒ·ÕèÊØ´¤×Í¡Òà ¾ÂÒÂÒÁ·Õè¨Ð¤Ñ´ÅÍ¡ ËÃ×ͺѹ·Ö¡á¿éÁ¢éͤÇÒÁÅéǹº¹ä´Ã¿ì¢éÍÁÙÅ ¤ÇÒÁ¾ÂÒÂÒÁ㹡Ò÷ӧҹ¤ÇÃÅéÁàËÅÇà¹×èͧ¨Ò¡ä´Ã¿ì¢éÍÁÙÅà»ç¹áººÍèÒ¹ÍÂèÒ§à´ÕÂÇ
    
    ËÁÒÂà˵Ø:ËÒ¡¤Ø³¡ÓÅѧ·Ó¢Ñ鹵͹àËÅèÒ¹Õé´éǵ¹àͧ àÃÒ¢Íá¹Ð¹ÓãËé ¤Ø³·Ó«éÓ¡Ò÷´ÊͺàËÅèÒ¹Õéã¹Ç§¨Ã¡ÒûÃѺ»Ãا·Ñé§ËÁ´àÁ×èͤس remount ä´Ã¿ì¢éÍÁÙÅ·Õè¶Ù¡µéͧà¾×èÍ¡ÒÃÃÒ§ҹã¹áµèÅÐà«ÔÃì¿àÇÍÃìÃÒ§ҹ ¶éҤسʤÃÔ»µì¢Ñ鹵͹㹡ÒÃÂéÒÂä´Ã¿ì¢éÍÁÙÅÃÒ§ҹ¡ÅѺÁÒÃÐÃÐËÇèÒ§à«ÔÃì¿àÇÍÃì¡ÒüÅÔµáÅÐà«ÔÃì¿àÇÍÃì·ÕèÃÒ§ҹ ¡Ò÷´ÊͺäÁè¨Óà»ç¹µéͧãªéËÅѧ¨Ò¡·Õè¤Ø³á¹èã¨ÇèÒ Ê¤ÃÔ»µì¢Í§¤Ø³·Ó§Ò¹ÍÂèÒ§¶Ù¡µéͧ

¢Ñ鹵͹·Õè 1: ¡ÒÃÊÃéÒ§ÃÐÂÐ

ÊÃéÒ§ ËÃ×ÍÃÕà¿Ãª scalable °Ò¹¢éÍÁÙÅãªéÃèÇÁ¡Ñ¹

°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹµéͧà»ç¹ÊÃéÒ§ áÅп×鹿ٴéǵ¹àͧ ¡Ãкǹ¡ÒùÕéà»ç¹¢Ñ鹵͹áá¢Í§Ãͺ¡ÒûÃѺ»ÃاÊÓËÃѺ°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹ áÅÐàÃÕ¡ÇèÒ¢Ñ鹵͹¢Í§¡ÒÃÊÃéÒ§ ¢Ñ鹵͹¡ÒÃÊÃéÒ§ÍÒ¨à¡ÕèÂÇ¢éͧ¡Ñº¡ÒûÃѺ»Ãا°Ò¹¢éÍÁÙÅ·Õèà¡èÒ ËÃ×ÍÊÃéÒ§àÇÍÃìªÑ¹ãËÁè

â´Â·ÑèÇä» ÃØ蹻Ѩ¨ØºÑ¹¢Í§°Ò¹¢éÍÁÙÅ·ÕèÃÒ§ҹ¨¹Áͧà¡èÒ °Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹµéͧÊÒÁÒöà»ç¹ÃÐÂÐ æ ¿×鹿١ÒÃà¡çº¢éÍÁÙÅ·ÕèÁÕ¡ÒÃÃÒ§ҹàÊÁÍ

¢Ñ鹵͹¡ÒÃÊÃéÒ§¡Ò÷ÓãËéàÊÃç¨ÊÁºÙóì

¤Ø³ÊÒÁÒö¿×鹿ٰҹ¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹà¡èÒ â´Â¡ÒûÃѺ»Ãا¢éÍÁÙŵ¡ÃØè¹áÅéÇã¹°Ò¹¢éÍÁÙÅ·ÕèÁÕÍÂÙè ËÃ×Í rebuilding °Ò¹¢éÍÁÙÅ

ËÁÒÂà˵Ø:¡è͹·Õè¤Ø³ÊÒÁÒö¿×鹿ٰҹ¢éÍÁÙÅ¡ÒÃÃÒ§ҹ¢éÍ·ÕèÁÕÍÂÙè °Ò¹¢éÍÁÙŵéͧ¶Ù¡¶Í¹¨Ò¡áµèÅÐÍÔ¹Êáµ¹«ìà«ÔÃì¿àÇÍÃìÃÒ§ҹ ¹Í¡¨Ò¡¹Õé »ÃÔÁÒ³·ÕèÃÒ§ҹµéͧà»ç¹ dismounted ¨Ò¡áµèÅÐà«ÔÃì¿àÇÍÃìÃÒ§ҹ ÊÓËÃѺ¢éÍÁÙÅà¾ÔèÁàµÔÁ ãËé´Ù·ÕèÊèǹ "Detach scalable °Ò¹¢éÍÁÙÅãªéÃèÇÁ¡Ñ¹"

¡Òÿ×鹿ٰҹ¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹà¡èÒ ·ÓµÒÁ¢Ñ鹵͹àËÅèÒ¹Õéã¹à«ÔÃì¿àÇÍÃì¡ÒüÅÔµ:

1. ãªéÍÃö»ÃÐ⪹ìÍ×è¹ æ ¢Í§¼Ùé¨Ó˹èÒÂÎÒÃì´áÇÃì¢Í§¤Ø³à¾×èÍ unmask ËÁÒÂàŢ˹èÇ·ҧµÃáР(LUNs) ·ÕèÊÍ´¤Åéͧ¡Ñºä´Ã¿ì¢éÍÁÙÅÃÒ§ҹ ·Ó¡ÒáÃзӹÕéãËéä´Ã¿ì¢éÍÁÙÅÊÒÁÒöà¢éÒ¶Ö§à«ÔÃì¿àÇÍÃì¡ÒüÅÔµ
2. ¡ÒáÓ˹´ãªéä´Ã¿ì¢éÍÁÙÅÃÒ§ҹ áÅШҡ¹Ñé¹ ¡Ó˹´ÇèÒÍèÒ¹/à¢Õ¹ àÁ×è͵éͧ¡ÒÃãªéÂÙ·ÔÅÔµÕºÃ÷Ѵ¤ÓÊÑè§ Diskpart à¾×èÍ¡Ó˹´ãªéä´Ã¿ì¢éÍÁÙÅ »é͹¤ÓÊÑ觵èÍ仹Õé·Õè¾ÃéÍÁ·ì¤ÓÊÑè§:diskpart
   DISKPART > àÅ×Í¡ä´Ã¿ì¢éÍÁÙÅ =<drive-number></drive-number>
   DISKPART > ¡Ó˹´ÍÑ¡ÉÃÃÐºØ =<drive-letter></drive-letter>
   DISKPART > readonly ¡ÒÃÅéÒ§á͵·ÃÔºÔǵì
   DISKPART> exit
   ã¹¢Ñ鹵͹¹Õé<drive-number></drive-number>is the volume number that is assigned by Windows, and<drive-letter></drive-letter>is the letter that is assigned to the reporting volume.
3. If you are refreshing an existing reporting database, follow these steps:
   1. Attach the database to a server instance. Typically, this would be the production server instance.

      CREATE DATABASE <database_name> ON <filespec_list>
         FOR ATTACH
      

   2. Set the database to read/write access by using the following Transact-SQL statement.

      ALTER DATABASE <database_name> SET READ_WRITE

      For more information, see SQL Server 2005 Books Online.
4. Build the database.
   
   To refresh a reporting database, you can update the outdated data, rebuild the database, or do whatever else you think is required to refresh the data. The administrator builds the database by using any one of the data-copy methods that are provided by SQL Server 2005 for copying data or databases. For more information, see the "Methods for building or updating a database" section.
   
   ËÁÒÂà˵Ø:In reporting databases, we recommend thatpage verifybe set tochecksum, the default. To change this setting, use ALTER DATABASE.
5. Set the database to read-only by using the following Transact-SQL statement.

   ALTER DATABASE <database_name> SET READ_ONLY

6. Detach the database by using the following Transact-SQL statement.

   sp_detach_db @dbname='<database_name>'

   ã¹¢Ñ鹵͹¹Õé<database_name></database_name>is the name of the database.
7. Mark the volume as read-only, and then dismount the volume from the production server. To use the Diskpart command-line utility to dismount the volume, enter the following commands at a command prompt.

   DiskPart
   DISKPART> select volume=<drive-number>
   DISKPART> attribute set readonly
   DISKPART> remove
   

   ã¹¢Ñ鹵͹¹Õé<drive-number></drive-number>is the volume number that is assigned by Windows, and<drive-letter></drive-letter>is the letter that is assigned to the reporting volume.
8. Use your hardware vendor's utilities to mask the LUNs that correspond to the reporting volumes. This action makes the volumes inaccessible to the production server.

Now, the reporting database can be made available as a scalable shared database. For more information, see the "Attach a scalable shared database" section.

Methods for building or refreshing a database

ËÁÒÂà˵Ø:When you build a reporting database, we recommend that you always use the same path for the production database and the reporting databases. Additionally, we recommend that you use the same drive letter for the production and reporting volume when the volume is mounted on the reporting servers, if it is possible.

SQL Server 2005 currently supports the following methods for porting data into a database or for porting a whole database:

• SQL Server Integration Services: You can create or copy a database by running Integration Services packages and by using the Execute SQL task or the Transfer Database task:
  • The Execute SQL task runs SQL statements or stored procedures from a package. When you use the Execute SQL task, you can create a database by running a CREATE DATABASE statement. You can then populate the database by copying in one or more tables or views.
  • The Transfer Database task can copy a database in the same server instance or between instances.
    
    ËÁÒÂà˵Ø:You can also create a database by using the SQL Server Import and Export Wizard, but you must copy at least one table or view.
• Backup and restore: You can restore a backup of a production database on the reporting volume. To do this, restore and recover a full database backup onto the reporting volume:
  • If you are using the same drive letter, mount the reporting volume onto a different host, and then connect to a server instance there to restore the database.
  • If the reporting volume uses a different drive letter than the production volume, the RESTORE DATABASE statement must have a WITH MOVE clause that specifies the drive letter of the reporting volume in the path of the restored database.
• Copy the production database onto the reporting volume: Before you can manually copy a database or use the Detach and Attach method of the Copy Database Wizard, you must take the database offline. After you copy the database, bring the database back online. However, the Copy Database Wizard offers an alternative method. The SMO Transfer method copies the database although the database remains online. Although the SMO Transfer method is slower than the Detach and Attach method, the SMO Transfer method preserves active connections to the database.

´Ù¢éÍÁÙÅà¾ÔèÁàµÔÁà¡ÕèÂǡѺÇÔ¸Õ¡ÒäѴÅÍ¡¢éÍÁÙÅàËÅèÒ¹Õé SQL Server 2005 ˹ѧÊ×ÍÍ͹äŹì

àÁ×èÍ°Ò¹¢éÍÁÙÅ·ÕèÁÕ¡ÒÃÃÒ§ҹ¡ÒÃàÊÃç¨ÊÔé¹áÅéÇ ¤Ø³µéͧ´Óà¹Ô¹¡ÒâÑ鹵͹¢Í§¡ÒÃÊÃéÒ§ ÊÓËÃѺ¢éÍÁÙÅà¾ÔèÁàµÔÁ ãËé´Ù "áÊ´§ÃÐÂзÕè 1: ¢Ñ鹵͹㹡ÒÃÊÃéÒ§¡ÒÃ" Êèǹ

¢Ñ鹵͹·Õè 2: ¡Òà attach ÃÐÂÐ

Ṻ°Ò¹¢éÍÁÙÅ scalable ·ÕèãªéÃèÇÁ¡Ñ¹

ËÅѧ¨Ò¡·Õè¤Ø³ÊÃéÒ§ ËÃ×Í»ÃѺ»Ãا°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹ áÅФس dismount »ÃÔÁÒ³·ÕèÃÒ§ҹ¨Ò¡à«ÔÃì¿àÇÍÃì¡ÒüÅÔµ ¼Ùé´ÙáÅÃкºµéͧ·Ó°Ò¹¢éÍÁÙžÃéÍÁãªé§Ò¹à»ç¹°Ò¹¢éÍÁÙÅ scalable ·ÕèãªéÃèÇÁ¡Ñ¹ ¡Ãкǹ¡ÒùÕéàÃÕ¡ÇèÒ¢Ñ鹵͹¡Òà attach

´Óà¹Ô¹¡ÒâÑ鹵͹¡Òà attach

ã¹¢Ñ鹵͹¹Õé ¼Ùé´ÙáÅÃкºµéͧ·ÓµÒÁ¢Ñ鹵͹µèÍ仹Õé:

1. ãªéÍÃö»ÃÐ⪹ìÍ×è¹ æ ¢Í§¼Ùé¨Ó˹èÒÂÎÒÃì´áÇÃì¢Í§¤Ø³à¾×èÍ unmask LUNs ·ÕèÊÍ´¤Åéͧ¡Ñºä´Ã¿ì¢éÍÁÙÅÃÒ§ҹ ·Ó¡ÒáÃзӹÕéãËéä´Ã¿ì¢éÍÁÙÅÊÒÁÒöà¢éÒ¶Ö§ä»Âѧä¤Åà͹µì¨Ò¡à«ÔÃì¿àÇÍÃìáµèÅÐÃÒ§ҹ
2. º¹à«ÔÃì¿àÇÍÃìáµèÅÐÃÒ§ҹ ¡Ó˹´ãªéä´Ã¿ì¢éÍÁÙÅ·ÕèÊÍ´¤Åéͧ¡Ñº LUN
   
   ËÁÒÂà˵Ø:àÁ×è͵éͧ¡Ò÷ÓãËé¡Ãкǹ¡ÒÃÊÃéÒ§ ËÃ×Í»ÃѺ»Ãا°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹ àÃÒ¢Íá¹Ð¹Ó¡Ó˹´ÇèÒ ¤Ø³àÊÁÍãªéä´Ã¿ì¢éÍÁÙŢͧÃÒ§ҹ â´ÂãªéÍÑ¡ÉÃÃкØä´Ã¿ìà´ÕÂǡѹà»ç¹»ÃÔÁÒ³¡ÒüÅÔµ µÑÇÍÂèÒ§àªè¹ ¶éÒ°Ò¹¢éÍÁÙÅ¡ÒüÅÔµÍÂÙ躹ä´Ã¿ì E ã¹à«ÔÃì¿àÇÍÃì¡ÒüÅÔµ »ÃÔÁÒ³·ÕèÃÒ§ҹ¤ÇÃÂѧÊÒÁÒö¡Ó˹´ãªéà»ç¹ä´Ã¿ì E º¹à«ÔÃì¿àÇÍÃìáµèÅÐÃÒ§ҹ ¶éÒà»ç¹ä»ä´é
   
   àÁ×è͵éͧ¡ÒÃãªéÂÙ·ÔÅÔµÕºÃ÷Ѵ¤ÓÊÑè§ Diskpart à¾×èÍ¡Ó˹´ãªéä´Ã¿ì¢éÍÁÙÅ ãÊè¤ÓÊÑ觵èÍ仹Õé·Õè¾ÃéÍÁ·ì¤ÓÊÑè§

   DiskPart
   DISKPART> select volume=<drive-number>
   DISKPART> assign letter=<drive-letter>
   DISKPART> exit
   

   ã¹¢Ñ鹵͹¹Õé<drive-number></drive-number>ÁÕËÁÒÂàÅ¢ä´Ã¿ì¢éÍÁÙÅ·Õè¶Ù¡¡Ó˹´ â´Â Windows áÅÐ<drive-letter></drive-letter>à»ç¹µÑÇÍÑ¡É÷Õè¤Ø³µéͧ¡ÒÃãªéÊÓËÃѺä´Ã¿ì¢éÍÁÙÅÃÒ§ҹº¹à«ÔÃì¿àÇÍÃìÃÒ§ҹ
   
   ËÁÒÂà˵Ø:»ÃÔÁÒ³·ÕèÃÒ§ҹµéͧà»ç¹áººÍèÒ¹ÍÂèÒ§à´ÕÂÇ àÃÒ¢Íá¹Ð¹ÓãËé ¤Ø³ÊÒÁÒö·Óà¤Ã×èͧËÁÒÂà»ç¹áººÍèÒ¹ÍÂèÒ§à´ÕÂÇ¡è͹·Õèä´Ã¿ì¢éÍÁÙÅà»ç¹ dismounted ¨Ò¡à«ÔÃì¿àÇÍÃì¡ÒüÅÔµ ËÒ¡ä´Ã¿ì¢éÍÁÙÅÁÕäÁè·Óà¤Ã×èͧËÁÒÂà»ç¹áººÍèÒ¹ÍÂèÒ§à´ÕÂÇ ¡Ó˹´ä´Ã¿ì¢éÍÁÙÅà»ç¹áººÍèÒ¹ÍÂèÒ§à´ÕÂÇËÅѧ¨Ò¡·Õè¤Ø³ä´é¡Ó˹´ãªéä´Ã¿ì¢éÍÁÙź¹à«ÔÃì¿àÇÍÃìÃÒ§ҹáá ÊÓËÃѺ¢éÍÁÙÅà¾ÔèÁàµÔÁ ãËé´Ù "áÊ´§ÃÐÂзÕè 1: ¢Ñ鹵͹㹡ÒÃÊÃéÒ§¡ÒÃ" Êèǹ
   
   à»ç¹ÇÔ¸Õ»¯ÔºÑµÔ·Õè´Õ·ÕèÊØ´ ¤Ø³¤ÇõÃǨÊͺÇèÒ ä´Ã¿ì¢éÍÁÙÅà¡Ô¹ÊÒÁÒöà¢éÒ¶Ö§à»ç¹ä´Ã¿ì¢éÍÁÙÅẺÍèÒ¹ÍÂèÒ§à´ÕÂÇ·Õè SAN ËÅѧ¨Ò¡·Õè¤Ø³¡Ó˹´ãªéä´Ã¿ì¢éÍÁÙÅẺà¾×èÍ¡ÒÃÃÒ§ҹä»ÂѧáµèÅÐà«ÔÃì¿àÇÍÃìÃÒ§ҹ ÊÓËÃѺ¢éÍÁÙÅà¾ÔèÁàµÔÁ ãËé´Ù·ÕèÊèǹ "µÃǨÊͺÇèÒ ÊÀÒ¾áÇ´ÅéÍÁ¡Ò÷ӧҹ·ÕèäÁè¶Ù¡µéͧÊÓËÃѺ°Ò¹¢éÍÁÙÅ scalable ·ÕèãªéÃèÇÁ¡Ñ¹"
3. Ṻ°Ò¹¢éÍÁÙÅä»ÂѧÍÔ¹Êáµ¹«ì¢Í§à«ÔÃì¿àÇÍÃìÃÒ§ҹËÃ×ÍÍÔ¹Êáµ¹«ìº¹áµèÅÐà«ÔÃì¿àÇÍÃìÃÒ§ҹ ´Ù¢éÍÁÙÅà¾ÔèÁàµÔÁ SQL Server 2005 ˹ѧÊ×ÍÍ͹äŹì

°Ò¹¢éÍÁÙÅ·ÕèÁÕ¡ÒÃÃÒ§ҹÍÂÙèã¹¢³Ð¹Õéà»ç¹°Ò¹¢éÍÁÙÅ·ÕèãªéÃèÇÁ¡Ñ¹áºº scalable áÅСÒÃÊͺ¶ÒÁÊÒÁÒö´Óà¹Ô¹¡ÒõèÍä»

¢Ñ鹵͹·Õè 3: ¡Òà detach ÃÐÂÐ

á¡ÍÍ¡ scalable °Ò¹¢éÍÁÙÅãªéÃèÇÁ¡Ñ¹

â´Â·ÑèÇä» ÃØ蹻Ѩ¨ØºÑ¹¢Í§°Ò¹¢éÍÁÙÅ·ÕèÃÒ§ҹ¨¹¡ÅÒÂà¡èÒ áÅеéͧ¿×鹿١ÒÃà¡çº¢éÍÁÙÅ·ÕèÁÕ¡ÒÃÃÒ§ҹàÊÁÍ ¡Ãкǹ¡ÒÃź°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹà¡èÒ¨Ò¡ºÃÔ¡ÒÃà»ç¹°Ò¹¢éÍÁÙÅ scalable ·ÕèãªéÃèÇÁ¡Ñ¹¶Ù¡àÃÕ¡ÇèÒÃÐÂÐ detach ¢Ñ鹵͹¹Õéà»ç¹¢Ñ鹵͹¡ÒÃÊÒÁ áÅÐÊØ´·éÒ¢ͧ¡ÒûÃѺ»ÃاÃͺÊÓËÃѺ°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹ ¡è͹·Õè¤Ø³ÊÒÁÒöÊÃéÒ§°Ò¹¢éÍÁÙÅ¡ÒÃÃÒ§ҹ¡ÒûÃѺ»Ãا¾ÃéÍÁãªé§Ò¹º¹à«ÔÃì¿àÇÍÃìÃÒ§ҹ੾ÒÐ ÃÐÂÐ detach µéͧà»ç¹àÊÃç¨ÊÔ鹺¹à«ÔÃì¿àÇÍÃì¹Ñé¹

´Óà¹Ô¹¡ÒâÑ鹵͹¡Òà detach

ã¹¢Ñ鹵͹¹Õé ¼Ùé´ÙáÅÃкºµéͧ·ÓµÒÁ¢Ñ鹵͹µèÍ仹Õ麹à«ÔÃì¿àÇÍÃìáµèÅÐÃÒ§ҹ:

1. »Ô´ãªé§Ò¹¡ÒÃÊͺ¶ÒÁãËÁèã¹°Ò¹¢éÍÁÙÅ áÅéÇ ãËéẺÊͺ¶ÒÁ»Ñ¨¨ØºÑ¹ÊÁºÙóì gracefully ¶éÒà»ç¹ä»
2. á¡°Ò¹¢éÍÁÙŨҡáµèÅÐÍÔ¹Êáµ¹«ìà«ÔÃì¿àÇÍÃìÃÒ§ҹÍÍ¡ â´Âãªé¡ÒÃsp_detach_db @ dbname = ' <database_name> ' </database_name>¤ÓÊÑè§
   
   ã¹¢Ñ鹵͹¹Õé<database_name></database_name>ª×èͧ͢°Ò¹¢éÍÁÙÅ ÊÓËÃѺ¢éÍÁÙÅà¾ÔèÁàµÔÁà¡ÕèÂǡѺ¡ÒÃsp_detach_db¤ÓÊÑè§ ´Ù SQL Server 2005 ˹ѧÊ×ÍÍ͹äŹì
3. º¹à«ÔÃì¿àÇÍÃìáµèÅÐÃÒ§ҹ dismount ÃдѺàÊÕ§¢Í§ÃÒ§ҹ àÁ×è͵éͧ¡Òà dismount ä´Ã¿ì¢éÍÁÙÅ ´éÇ¡ÒÃãªéÂÙ·ÔÅÔµÕºÃ÷Ѵ¤ÓÊÑè§ Diskpart ãÊè¤ÓÊÑ觵èÍ仹Õé·Õè¾ÃéÍÁ·ì¤ÓÊÑè§

   DiskPart
   DISKPART> select volume <drive-number>
   DISKPART> remove
   

   ã¹¢Ñ鹵͹¹Õé<drive-letter></drive-letter>à»ç¹µÑÇÍÑ¡É÷Õè¡Ó˹´ãËé¡Ñºä´Ã¿ì¢éÍÁÙÅã¹ÃÒ§ҹ
4. ãªéÍÃö»ÃÐ⪹ìÍ×è¹ æ ¢Í§¼Ùé¨Ó˹èÒÂÎÒÃì´áÇÃì¢Í§¤Ø³àÁ×è͵éͧ¡Òà mask LUNs ·ÕèÊÍ´¤Åéͧ¡Ñºä´Ã¿ì¢éÍÁÙÅÃÒ§ҹ ·Ó¡ÒáÃзӹÕéãËéä´Ã¿ì¢éÍÁÙÅäÁèÊÒÁÒöà¢éÒ¶Ö§ä»Âѧä¤Åà͹µì¨Ò¡à«ÔÃì¿àÇÍÃìáµèÅÐÃÒ§ҹ

¡ÅÂØ·¸ì¡ÒÃÊÓÃͧÊÓËÃѺ detaching °Ò¹¢éÍÁÙÅ¡ÒÃÃÒ§ҹẺà¡èÒ

àÁ×èͤس᷹·ÕèÃØè¹à¡èҢͧ°Ò¹¢éÍÁÙÅ ¤Ø³µéͧ¾Ô¨ÒóҤÇÒÁµéͧ¡Ò÷ҧ¸ØáԨÊÓËÃѺÊÀÒ¾áÇ´ÅéÍÁ¢Í§¤Ø³à¾×èÍ¡ÒÃÃÒ§ҹ ¤Ø³¤ÇûÃÐàÁÔ¹¢éÍ¡Ó˹´µèÍ仹Õé¢Í§¸ØáԨ·Õèãªé¡è͹˹éÒã¹ÊÀÒ¾áÇ´ÅéÍÁ¡Ò÷ӧҹ¢Í§¤Ø³µèÍ仹Õé:

• ¤Ø³ÊÒÁÒöºÑ¹·Ö¡¢éÍÁÙÅ·Ò§¸ØáÃÃÁ·ÕèÍÂÙèã¹¢³Ð¹Õé¡ÓÅѧ·Ó§Ò¹¨¹¡ÇèÒ¨ÐàÊÃç¨ÊÔé¹
• ¡ÒôÓà¹Ô¹¡ÒûÃѺ»ÃاÀÒÂ㹡ÃͺàÇÅÒ·Õè¨Ó¡Ñ´

µÒÁ¤ÇÒÁµéͧ¡Ò÷ÕèãªéàÇÅÒ¡è͹˹éÒ ¤Ø³ÊÒÁÒöàÅ×Í¡ÇÔ¸Õ¡ÒèѴ¡ÒÃÃÐÂÐ detach º¹áµèÅÐà«ÔÃì¿àÇÍÃìÃÒ§ҹ You can manage the detach phase in the following ways:

• Let the transactions finish before you detach the reporting server: To preserve all in-progress transactions, you must start the detach phase by stopping incoming I/O activity to the reporting volume. Then, on each reporting server instance, wait to detach the database until all the current transactions are finished. When the database has been detached from all the server instances, you can dismount the reporting volume.
• Update the database during a limited timeframe: In this case, you should obtain exclusive access to the database on each server instance with a termination time that allows for your timeframe. If any queries do not finish within that termination time, they will be stopped. Those queries will have to wait until after the update to be restarted. After the queries are stopped, you can detach the database from each server instance, and then dismount the reporting volume from each reporting server.

At this point, you are ready for the next build phase. Alternatively, if you have already refreshed the database on another reporting volume like we recommend, you can now perform the attach phase for the alternative volume. For more information, see the "Maximize the availability of a scalable shared database" section.

Maximize the availability of a scalable shared database

To maximize the availability of reporting data, we recommend that you alternate update cycles between two reporting volumes. When the first reporting volume is still mounted to the reporting servers, you can mount the second volume to the production server and build an up-to-date version of the reporting database.

If you update the reporting database on a second reporting volume, consider the following options:

• If you want all your reporting databases to return identical results to clients, you must detach the old copy from all the server instances before you attach the new copy to any one of them.
• If you can tolerate clients receiving different results on different server instances when you update the reporting database, you can perform a rolling upgrade of the reporting database. You would finish the update cycle on one reporting server at a time.

Synchronized, time-sensitive updates of all reporting servers

This section describes several strategies for updating the content of a scalable shared database, depending on your business requirements:

• You must keep all reporting servers in sync.
• You must accomplish the update within a limited timeframe. This timeframe is more critical than preserving currently running transactions.

When you synchronize the database on all the reporting servers, the reporting database is unavailable between the detach phase for the stale version of the database and the attach phase of the fresh version.

To synchronize the update cycle on all the reporting server instances and finish the update cycle within a limited timeframe, follow these steps:

1. To keep the content in sync, you must finish the detach phase on all the reporting servers before any one of the reporting servers can be updated. If any long-running queries are active on any server, you must stop them.
2. After you dismount the first reporting volume from all the server instances, you can start to update the reporting servers. On each reporting server, mount another volume that contains a more current version of the reporting database. Attach that version to the local reporting server instance. As soon as the database is attached on a particular instance, stopped transactions can be restarted on that instance.

Rolling upgrades of reporting servers

A rolling upgrade lets you to refresh the reporting database on one reporting server when a stale reporting database remains temporarily available on another reporting server. For a while, both the stale version and the refreshed version of the database are available at the same time. Depending on your business requirements, a rolling upgrade can occur in a limited timeframe or the rolling upgrade can be relatively open-ended to let current transactions finish.

Let transactions finish before the rolling upgrade

ã¹¹Õé¡ÅÂØ·¸ì ¡ÒûÃѺÃØè¹ rolling ªèÇÂãËé¼Ùé´ÙáÅ°Ò¹¢éÍÁÙÅ¡ÒÃÃÍÊÓËÃѺ¸ØáÃÃÁ·ÕèÃѹà»ç¹àÇÅÒ¹Ò¹à¾×èÍàÊÃç¨ÊÔ鹺¹à«ÔÃì¿àÇÍÃìÃÒ§ҹ˹Öè§àÁ×èÍÁÕ¿×鹿ٰҹ¢éÍÁÙÅ·ÕèÍÂÙ躹à«ÔÃì¿àÇÍÃìÃÒ§ҹÍ×è¹ ¡ÅÂØ·¸ì¹Õéà¹é¹¤ÇÒÁµéͧ¡Ò÷ҧ¸ØáԨ´Ñ§µèÍ仹Õé:

• äÁèÁÕà«ÔÃì¿àÇÍÃì·ÕèÃÒ§ҹ¨Ðà¡çºäÇéã¹ÊÀÒÇзÕè«Ô§¤ì¡Ñ¹ «Ö觪èÇÂãËé¡ÒûÃѺÃØè¹ rolling ÃÐËÇèÒ§°Ò¹¢éÍÁÙÅ¡ÒÃÃÒ§ҹà¡èÒáÅлÃѺ»Ãا°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹ
• ¤Ø³ÁÕ¡ÃͺàÇÅÒ·ÕèäÁè¨Ó¡Ñ´à¾×èÍ·Ó¡ÒûÃѺ»Ãا ËÃ×Í¡Ó˹´àÇÅÒÊÔé¹ÊØ´¢Í§¤Ø³ÁÕ¤ÇÒÁÊӤѭ¹éÍ¡ÇèÒ¡Òúѹ·Ö¡¢éÍÁÙÅ·Ò§¡ÒøØáÃÃÁ·ÕèàÃÕ¡ãªéÍÂÙè

¡ÒôÓà¹Ô¹¡ÒùÕéÃٻẺ¢Í§¡ÒùӡÒûÃѺÃØè¹ ·ÓµÒÁ¢Ñ鹵͹º¹ÍÔ¹Êáµ¹«ì¢Í§à«ÔÃì¿àÇÍÃì˹Ö觤ÃÑé§:

1. ¡ÒÃÃÑ¡ÉÒ¸ØáÃÃÁã¹ÃÐËÇèÒ§´Óà¹Ô¹¡Ò÷Ñé§ËÁ´ ¤Ø³µéͧàÃÔèÁµé¹¢Ñ鹵͹¡Òà detach â´Â¡ÒÃËÂØ´¡Ô¨¡ÃÃÁ I/O ¢Òà¢éҡѺä´Ã¿ì¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹ ¶éÒẺÊͺ¶ÒÁ·ÕèÃѹà»ç¹àÇÅÒ¹Ò¹ delays ¡ÒÃÍѾà¡Ã´º¹ÍÔ¹Êáµ¹«ì¢Í§à«ÔÃì¿àÇÍÃìà»ç¹ ÃÍÊÓËÃѺ¡ÒÃÊͺ¶ÒÁãËéàÊÃç¨ÊÁºÙóì¡è͹·Õè¤Ø³ãªéÍÔ¹Êáµ¹«ì¢Í§à«ÔÃì¿àÇÍÃìẺÍÍ¿äŹì
2. ËÅѧ¨Ò¡·Õè¸ØáÃÃÁ·Ñé§ËÁ´¨ÐàÊÃç¨ÊÔ鹺¹ÍÔ¹Êáµ¹«ì¢Í§à«ÔÃì¿àÇÍÃì¹Õé °Ò¹¢éÍÁÙÅ·ÕèÁÕ¡ÒÃÃÒ§ҹ¡ÒÃá¡ÍÍ¡
3. ËÅѧ¨Ò¡·Õè¤Ø³´Ö§ÍÍ¡°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹ੾ÒШҡÍÔ¹Êáµ¹«ìà«ÔÃì¿àÇÍÃì·Ñé§ËÁ´ ṺÃØè¹°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹà¾ÔèÁàµÔÁ»Ñ¨¨ØºÑ¹ä»·ÕèÍÔ¹Êáµ¹«ì¢Í§à«ÔÃì¿àÇÍÃì
4. à¾×èÍ·ÓãËé¾ÃéÍÁãªé§Ò¹ÍÕ¡¤ÃÑé§ÊÓËÃѺ¡ÒÃÊͺ¶ÒÁà¾×èÍ¡ÒÃÃÒ§ҹÍÔ¹Êáµ¹«ì¢Í§à«ÔÃì¿àÇÍÃì ṺÊÓà¹Ò»ÃѺ»Ãا¢Í§°Ò¹¢éÍÁÙÅ

àÊÃç¨ÊÔ鹡ÒûÃѺÃØè¹ rolling ã¹àÇÅÒ·Õè¨Ó¡Ñ´

ã¹¹Õé¡ÅÂØ·¸ì ¡ÒûÃѺÃØè¹ rolling ªèÇÂãËé¼Ùé´ÙáÅ°Ò¹¢éÍÁÙÅà¾×èÍÃÑ¡ÉÒºÃÔ¡ÒÃÃÒ§ҹ uninterrupted â´ÂÊÑé¹ æ ãËé°Ò¹¢éÍÁÙÅ·Õè¨ÐÂѧ¤§¾ÃéÍÁÊÓËÃѺ¡ÒÃÊͺ¶ÒÁãËÁ躹à«ÔÃì¿àÇÍÃìÃÒ§ҹºÒ§ÃØè¹à¡èÒ ºÃÔ¡ÒÃÂѧ¤§ uninterrupted àÁ×èͤس·Ó¡ÒûÃѺ»Ãا°Ò¹¢éÍÁÙÅ·ÕèÍÂÙ躹à«ÔÃì¿àÇÍÃìÃÒ§ҹÍ×è¹ ¡ÅÂØ·¸ì¹Õéà¹é¹¤ÇÒÁµéͧ¡Ò÷ҧ¸ØáԨ´Ñ§µèÍ仹Õé:

• äÁèÁÕà«ÔÃì¿àÇÍÃì·ÕèÃÒ§ҹ¨Ðà¡çºäÇéã¹ÊÀÒÇзÕè«Ô§¤ì¡Ñ¹ «Ö觪èÇÂãËé¡ÒûÃѺÃØè¹ rolling ÃÐËÇèÒ§°Ò¹¢éÍÁÙÅ¡ÒÃÃÒ§ҹà¡èÒáÅлÃѺ»Ãا°Ò¹¢éÍÁÙÅà¾×èÍ¡ÒÃÃÒ§ҹ
• ¤Ø³µéͧ·Ó¡ÒûÃѺ»Ãا㹡ÃͺàÇÅÒ·Õè¨Ó¡Ñ´ ¡Ó˹´àÇÅÒÊÔé¹ÊØ´¹Õé¤×ÍÊӤѭÂÔ觡ÇèÒ¡Òúѹ·Ö¡¢éÍÁÙÅ·Ò§¡ÒøØáÃÃÁ·ÕèàÃÕ¡ãªéÍÂÙè

¡ÒôÓà¹Ô¹¡ÒùÕéÃٻẺ¢Í§¡ÒùӡÒûÃѺÃØè¹ ·ÓµÒÁ¢Ñ鹵͹º¹à«ÔÃì¿àÇÍÃìÃÒ§ҹ˹Ö觤ÃÑé§:

1. ËÂØ´¡ÒáԨ¡ÃÃÁ I/O ¢Òà¢éҡѺä´Ã¿ì¢éÍÁÙÅÃÒ§ҹ áÅÐ ËÃ×Í Ã͸ØáÃÃÁÊÑé¹ æ à¾×èͨº¡ÒÃÍÔ¹Êáµ¹«ì¢Í§à«ÔÃì¿àÇÍÃì¡è͹·Õè¤Ø³´Ö§ÍÍ¡°Ò¹¢éÍÁÙŢͧÃÒ§ҹ
2. ¨º¢Ñ鹵͹¡Òà detach º¹à«ÔÃì¿àÇÍÃì¹Ñé¹ ÊÓËÃѺ¢éÍÁÙÅà¾ÔèÁàµÔÁ ãËé´Ù·ÕèÊèǹ "Detach scalable °Ò¹¢éÍÁÙÅãªéÃèÇÁ¡Ñ¹"
3. µÃǨÊͺÃØè¹°Ò¹¢éÍÁÙÅ·ÕèÁÕ¡ÒÃÃÒ§ҹ¡ÒûÃѺ»Ãا¾ÃéÍÁãªé§Ò¹ÍÕ¡¤ÃÑé§ÊÓËÃѺ¡ÒÃÊͺ¶ÒÁà¾×èÍ¡ÒÃÃÒ§ҹ ÊÓËÃѺ¢éÍÁÙÅà¾ÔèÁàµÔÁ ãËé´Ù·ÕèÊèǹ "Ṻ°Ò¹¢éÍÁÙÅ scalable ·ÕèãªéÃèÇÁ¡Ñ¹"

¡ÒûÃѺÃØè¹ rolling ¢Í§»ÃÐàÀ·¹Õé guarantees ÇèÒ ¤ÇÒÁÊÒÁÒö㹡ÒÃÃÒ§ҹ·Õèâ´ÂÃÇÁäÁèËÂØ´ ¡ÅÂØ·¸ì¹ÕéªèÇÂãËé¤Ø³ tolerate fairly-Ãѹà»ç¹àÇÅÒ¹Ò¹¸ØáÃÃÁº¹ÍÔ¹Êáµ¹«ì¢Í§à«ÔÃì¿àÇÍÃìºÒ§ÍÂèÒ§ÊÓËÃѺ¤ÃÙè ÍÂèÒ§äáçµÒÁ ¡Ó˹´¡ÃͺàÇÅÒ·Õè¨Ó¡Ñ´ÊÓËÃѺ¡ÒûÃѺ»Ãا°Ò¹¡ÒÃÃÒ§ҹ¢éÍÁÙÅ·Ñé§ËÁ´ ¶éÒẺÊͺ¶ÒÁ·ÕèÃѹà»ç¹àÇÅÒ¹Ò¹ÁÒ¡ delays ¡ÒÃÍѾà¡Ã´º¹ÍÔ¹Êáµ¹«ì¢Í§à«ÔÃì¿àÇÍÃìà»ç¹ ¤Ø³¨ÐµéͧËÂØ´¡ÒÃÊͺ¶ÒÁ¹Ñé¹ áººÊͺ¶ÒÁÊÒÁÒöÃÍà¾×èÍÃѹãËÁèÍÕ¡à»ç¹¤ÃÑ駺¹ÍÔ¹Êáµ¹«ì¢Í§à«ÔÃì¿àÇÍÃìà´ÕÂǡѹËÅѧ¨Ò¡·Õèä´éÃѺ¡Òÿ×鹿ٰҹ¢éÍÁÙŢͧÃÒ§ҹ ËÃ×ÍẺÊͺ¶ÒÁÊÒÁÒö¶Ù¡àÃÔèÁãËÁè sooner º¹à«ÔÃì¿àÇÍÃì¡ÒûÃѺ»Ãا

´ÒǹìâËÅ´ SQL Server 2005 ˹ѧÊ×ÍÍ͹äŹì áÇÐä»·Õè䫵ì¢Í§àÇçºÈÙ¹Âì¡ÅÒ§¡ÒôÒǹìâËÅ´ Microsoft µèÍ仹Õé:

SQL Server µéͧãªéÃкºà¾×èÍʹѺʹع ‘ ÁÕ¡ÒèѴÊè§ä»ÂѧÊ×èÍ·ÕèàʶÕÂà ’ µÒÁ outlined ÀÒÂãµéâ»Ãá¡ÃÁµÃǨ·Ò¹ Microsoft SQL Server Always-On à¡çºâ«Å٪ѹá¡éä¢ FoÊÓËÃѺ¢éÍÁÙÅà¾ÔèÁàµÔÁà¡ÕèÂǡѺ¤ÇÒÁµéͧ¡Òûé͹¢éÍÁÙÅ áÅмÅÅѾ¸ìÊÓËÃѺâ»Ãá¡ÃÁ¢Í§°Ò¹¢éÍÁÙÅ SQL Server ¤ÅÔ¡ËÁÒÂàÅ¢º·¤ÇÒÁµèÍ仹Õéà¾×èÍ´Ùº·¤ÇÒÁã¹°Ò¹¤ÇÒÁÃÙé¢Í§ Microsoft: