ฐานข้อมูลที่ใช้ร่วมกัน scalable ได้รับการสนับสนุน โดย SQL Server 2005

การแปลบทความ การแปลบทความ
หมายเลขบทความ (Article ID): 910378 - ผลิตภัณฑ์ที่เกี่ยวข้องในบทความนี้
ขยายทั้งหมด | ยุบทั้งหมด

เนื้อหาบนหน้านี้

บทนำ

ฐานข้อมูลที่ใช้ร่วมกัน 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 ต่อไปนี้:
http://www.microsoft.com/downloads/details.aspx?FamilyID=be6a2c5d-00df-4220-b133-29c1e0b6585f&DisplayLang=en
SQL Server ต้องใช้ระบบเพื่อสนับสนุน ‘ มีการจัดส่งไปยังสื่อที่เสถียร ’ ตาม outlined ภายใต้โปรแกรมตรวจทาน Microsoft SQL Server Always-On เก็บโซลูชันแก้ไข Foสำหรับข้อมูลเพิ่มเติมเกี่ยวกับความต้องการป้อนข้อมูล และผลลัพธ์สำหรับโปรแกรมของฐานข้อมูล SQL Server คลิกหมายเลขบทความต่อไปนี้เพื่อดูบทความในฐานความรู้ของ Microsoft:
967576ข้อกำหนดของโปรแกรมอินพุต/เอาท์พุตฐานข้อมูลของเซิร์ฟเวอร์ Microsoft SQL

คุณสมบัติ

หมายเลขบทความ (Article ID): 910378 - รีวิวครั้งสุดท้าย: 16 มกราคม 2554 - Revision: 2.0
ใช้กับ
  • Microsoft SQL 2005 Server Enterprise
  • Microsoft SQL Server 2005 Enterprise Edition for Itanium Based Systems
  • Microsoft SQL Server 2005 Enterprise X64 Edition
  • Microsoft SQL Server 2008 Developer
  • Microsoft SQL Server 2008 Enterprise
  • Microsoft SQL Server 2008 Express
  • Microsoft SQL Server 2008 Standard
Keywords: 
kbsql2005engine kbtshoot kbinfo kbmt KB910378 KbMtth
แปลโดยคอมพิวเตอร์
ข้อมูลสำคัญ: บทความนี้แปลโดยซอฟต์แวร์การแปลด้วยคอมพิวเตอร์ของ Microsoft แทนที่จะเป็นนักแปลที่เป็นบุคคล Microsoft มีบทความที่แปลโดยนักแปลและบทความที่แปลด้วยคอมพิวเตอร์ เพื่อให้คุณสามารถเข้าถึงบทความทั้งหมดในฐานความรู้ของเรา ในภาษาของคุณเอง อย่างไรก็ตาม บทความที่แปลด้วยคอมพิวเตอร์นั้นอาจมีข้อบกพร่อง โดยอาจมีข้อผิดพลาดในคำศัพท์ รูปแบบการใช้ภาษาและไวยากรณ์ เช่นเดียวกับกรณีที่ชาวต่างชาติพูดผิดเมื่อพูดภาษาของคุณ Microsoft ไม่มีส่วนรับผิดชอบต่อความคลาดเคลื่อน ความผิดพลาดหรือความเสียหายที่เกิดจากการแปลเนื้อหาผิดพลาด หรือการใช้บทแปลของลูกค้า และ Microsoft มีการปรับปรุงซอฟต์แวร์การแปลด้วยคอมพิวเตอร์อยู่เป็นประจำ
ต่อไปนี้เป็นฉบับภาษาอังกฤษของบทความนี้:910378

ให้ข้อเสนอแนะ

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com