زبانه Options

Options Tab در SQL Server Installation Center، بر اساس نوع Processor موجود در Server، Processor Architecture قابل استفاده برای نصب SQL Server را نمایش می‌دهد. همچنین می‌توانید Path مربوط به Installation Media را مشخص کنید؛ قابلیتی که در صورت نگهداری Local Copy از Media روی Server مفید است.

نصب Stand-Alone Database Engine Instance

همان‌طور که در بخش قبل گفته شد، SQL Server Instance را می‌توان به روش‌های مختلف نصب کرد؛ از جمله Command Line، استفاده از Sysprep در Advanced Installation با Configuration File، یا Option مربوط به New SQL Server Stand-Alone Installation Or Add Features To An Existing Installation در Installation Tab.

در مثال این فصل از روش آخر برای نصب SQL Server استفاده می‌شود. در بخش‌های بعد یک Database Engine Instance همراه Featureهایی نصب می‌شود که در سراسر کتاب بررسی خواهند شد، از جمله FILESTREAM و Distributed Replay. همچنین انتخاب Collation صحیح و Service Account مناسب برای Instance به‌صورت عمیق بررسی می‌شود.

گام‌های آماده‌سازی

هنگام انتخاب نصب Instance جدید SQL Server، نخستین صفحه Wizard از شما Product Key را درخواست می‌کند؛ مطابق شکل 2-8.

اگر در این صفحه Product Key وارد نکنید، فقط می‌توانید Express Edition، Developer Edition یا Evaluation Edition را نصب کنید. Developer Edition همان سطح Functionality مربوط به Enterprise را دارد اما برای Production مجوز ندارد. Evaluation Edition نیز همان سطح Functionality مربوط به Enterprise را ارائه می‌کند، ولی پس از 180 روز Expire می‌شود.

صفحه بعد Wizard از شما می‌خواهد License Termهای SQL Server را بخوانید و بپذیرید. Link موجود در همان صفحه جزئیات بیشتری درباره Privacy Policy مایکروسافت ارائه می‌کند.

پس از پذیرش License Termها، SQL Server Setup یک Rule Check اجرا می‌کند تا مطمئن شود Installation می‌تواند ادامه پیدا کند. این همان Configuration Check است که می‌توان به‌صورت مستقل از Planning Tab در Installation Center نیز اجرا کرد.

اگر همه Checkها با موفقیت انجام شوند، صفحه بعد Wizard از شما می‌پرسد آیا Microsoft Update برای Patch و Hotfixهای SQL Server بررسی انجام دهد یا نه. انتخاب مناسب به Patching Policy سازمان بستگی دارد. بعضی سازمان‌ها فرایند سخت‌گیرانه‌ای برای Test و Accept کردن Patchها و سپس Patching Cycle دارند که اغلب با Softwareهایی مانند WSUS یا Windows Server Update Services پشتیبانی می‌شود. اگر چنین فرایندی در سازمان شما وجود دارد، نباید این Option را انتخاب کنید.

صفحه بعد Wizard تلاش می‌کند SQL Server Updateها را Scan کند تا جدیدترین CU یا Cumulative Update و SP یا Service Pack همراه Installation نصب شود. Microsoft Update Service روی Local Server بررسی و Updateهای موجود فهرست می‌شوند. این قابلیت توسعه‌ای از Slipstream Installation است که امکان نصب Updateها هم‌زمان با Base Binaryها را با مشخص‌کردن Location آن‌ها برای Setup فراهم می‌کرد؛ آن قابلیت اکنون Deprecated شده است. Product Updates Page را می‌توان برای جست‌وجوی Update در Local Folder یا Network Location نیز تنظیم کرد؛ این موضوع در فصل 3 بیشتر بررسی می‌شود.

هنگامی که Setup به صفحه بعد Wizard می‌رود، Extraction و Installation فایل‌های لازم برای SQL Server Setup آغاز می‌شود و Progress نمایش داده می‌شود. همین صفحه Progress مربوط به Download و Extraction هر Update Package یافت‌شده توسط Product Updates را نیز نشان می‌دهد.

در صفحه بعد، Wizard یک Installation Rule Check اجرا می‌کند و Error یا Warningهایی را که شاید پیش از شروع Installation نیاز به رسیدگی داشته باشند نمایش می‌دهد.

در شکل 2-13 به Warning مربوط به Windows Firewall توجه کنید. این Warning مانع ادامه Installation نمی‌شود، اما نشان می‌دهد Windows Firewall روی Server فعال است. به‌طور پیش‌فرض Windows Firewall برای اجازه Traffic مربوط به SQL Server پیکربندی نشده است؛ بنابراین باید Ruleهایی ایجاد شوند تا Client Applicationها بتوانند با Instance در حال نصب ارتباط برقرار کنند. Portهای SQL Server و Firewall Configuration در فصل 5 بررسی می‌شوند.

اگر Errorی که باید پیش از ادامه برطرف شود پیدا نشود، صفحه بعد Wizard امکان انتخاب Featureهای نصب را می‌دهد.

صفحه Feature Selection

Feature Selection Page اجازه می‌دهد Optionهای موردنظر برای Installation را انتخاب کنید. نمای کلی Optionهای موجود در فصل 1 توضیح داده شد. شکل 2-14 این صفحه را نمایش می‌دهد.

برای Demoها و Discussionهای سراسر کتاب Featureهای زیر انتخاب می‌شوند:

• Database Engine Services
• SQL Server Replication
• Client Tools Connectivity
• Distributed Replay Controller
• Distributed Replay Client

این صفحه همچنین از شما Folder Location مربوط به Instance Root Directory و Shared Features Directory را می‌خواهد. ممکن است بخواهید آن‌ها را به Drive دیگری منتقل کنید تا Drive مربوط به C:\ برای Operating System باقی بماند؛ چه به دلیل Space و چه برای جداسازی SQL Server Binaryها از Applicationهای دیگر. Instance Root Directory معمولاً برای هر Instance ایجادشده روی Server یک Folder دارد.

برای Database Engine، SSAS و SSRS Installationها Folderهای جداگانه ایجاد می‌شود. Folder مرتبط با Database Engine به شکل MSSQL15.[InstanceName] نام‌گذاری می‌شود؛ InstanceName یا نام Instance شما است یا برای Default Instance مقدار MSSQLSERVER. عدد 15 به Version داخلی SQL Server 2019 اشاره دارد.

این Folder زیرپوشه‌ای به نام MSSQL دارد و در آن Folderهای مربوط به Fileهای Instance قرار می‌گیرند؛ از جمله Binn برای Application Fileها، Application Extensionها و XML Configurationها؛ Backup برای Default Location مربوط به Database Backupها؛ و Data برای Default Location پایگاه‌های داده سیستمی. Default Folderهای TempDB، User Databaseها و Backupها در مراحل بعد Installation قابل تغییر هستند و در بسیاری از محیط‌ها جداکردن آن‌ها روی Volumeهای مستقل Best Practice است. Folder دیگری به نام LOGS نیز ایجاد می‌شود که Default Location فایل‌های Error Log و Default Extended Event Health Trace است.

در محیط 64-bit باید Folderهای جدا برای نسخه‌های 32-bit و 64-bit Shared Features Directory مشخص کنید، چون بعضی Componentهای SQL Server همواره به‌صورت Processهای 32-bit نصب می‌شوند و Componentهای 32 و 64 bit نمی‌توانند Directory مشترک داشته باشند. Shared Features Directory به Root Directory Featureهایی تبدیل می‌شود که بین همه Instanceها مشترک‌اند، مانند SDKها و Management Toolها.

در صفحه بعد Wizard یک Rule Check اضافی انجام می‌شود تا امکان نصب Featureهای انتخاب‌شده بررسی شود.

Ruleهایی که بررسی می‌شوند بسته به Featureهای انتخاب‌شده متفاوت‌اند.

صفحه Instance Configuration

پس از تکمیل موفق Rule Check، صفحه بعد اجازه می‌دهد Default Instance یا Named Instance بودن Installation را مشخص کنید. Box پایین صفحه نیز جزئیات سایر Instanceها یا Shared Featureهای نصب‌شده روی Server را نمایش می‌دهد.

تفاوت Default Instance و Named Instance این است که Default Instance نام Server میزبان را می‌گیرد، اما Named Instance دارای نام Extended است. بنابراین روی هر Server فقط یک Default Instance ممکن است، ولی چند Named Instance می‌توان داشت. در SQL Server 2019 حداکثر 50 Stand-alone Instance می‌توان روی یک Server میزبانی کرد و طبیعتاً همه آن‌ها منابع فیزیکی Server را به اشتراک می‌گذارند. برای Failover Cluster اگر Data روی SMB File Share باشد همین عدد باقی می‌ماند، اما اگر Shared Cluster Disk برای Storage استفاده شود به 25 کاهش می‌یابد.

لازم نیست پیش از Named Instance حتماً Default Instance نصب شده باشد. Configurationی که فقط Named Instance داشته باشد و هیچ Default Instance نداشته باشد کاملاً معتبر است. بسیاری از تیم‌های DBA فقط Named Instance را پشتیبانی می‌کنند تا Naming Convention معناداری در لایه SQL Server اعمال کنند و به Naming Convention تیم Infrastructure برای Server یا VM وابسته نباشند.

حداکثر طول Instance Name برابر 16 Character است. InstanceID به‌طور پیش‌فرض همان Instance Name است و برای Default Instance مقدار MSSQLSERVER دارد. اگرچه می‌توان InstanceID را تغییر داد، این کار Best Practice نیست؛ زیرا این ID برای شناسایی Registry Keyها و Installation Directoryها استفاده می‌شود.

انتخاب Service Accountها

صفحه بعد Wizard دو Tab دارد. Tab نخست Service Account مربوط به هر SQL Server Service را مشخص می‌کند و Tab دوم برای Collation Instance است.

SQL Server 2019 از Local Account، Domain Account، Built-in Account، Virtual Account، MSA یا Managed Service Account و gMSA یا Group Managed Service Account به‌عنوان Security Context اجرای Service پشتیبانی می‌کند. انتخاب Service Account Model برای Security و Manageability محیط بسیار مهم است.

سازمان‌ها نیازمندی‌های متفاوتی دارند و ممکن است Compliance Requirementها یا عوامل دیگر انتخاب را محدود کنند. در اصل، انتخاب بین Security و Operational Supportability یک Trade-off است. Best Practice مایکروسافت استفاده از Service Account جدا برای هر Service و مجموعه Account مجزا برای هر Server است تا Principle of Least Privilege به‌طور کامل اعمال شود. این اصل می‌گوید هر Security Context فقط حداقل Permission لازم برای فعالیت روزمره را دریافت کند.

در عمل این رویکرد Complexity قابل‌توجهی به SQL Server Estate اضافه می‌کند، هزینه Operational Support را بالا می‌برد و در Disaster Scenario می‌تواند Outage Window را افزایش دهد. در نقطه مقابل، Model بسیار Coarse که مثلاً یک مجموعه Service Account برای کل Region دارد نیز مشکل‌ساز است. اگر Estate بزرگ باشد و همه از یک Account استفاده کنند و Compliance شما Password Change هر 90 روز را الزام کند، هم‌زمان کل Estate دچار Outage می‌شود؛ که عملی نیست.

پاسخ واحد درست یا غلطی وجود ندارد و Solution به Requirement و Constraint سازمان بستگی دارد. برای سازمان‌هایی که Domain Account را به‌عنوان Service Account استفاده می‌کنند، نویسنده معمولاً یک مجموعه مجزا برای هر Data-tier Application پیشنهاد می‌کند. مثلاً اگر Application شامل Two-node Cluster و ETL Server در Primary Site و دو DR Server در Secondary Site باشد، همه این Instanceها مجموعه Account مشترک همان Application را استفاده می‌کنند، ولی Applicationهای دیگر حق استفاده از آن Accountها را ندارند.

این Model نیز Challengeهای خود را دارد؛ مثلاً اگر فرایند Consolidation آغاز شود باید Policy بازبینی و اصلاح شود. برای حل بخشی از مشکلات Service Account Management، مایکروسافت Virtual Account و MSA را معرفی کرد. Virtual Account یک Local Account بدون نیاز به Password Management است و با Computer Identity همان Server به Domain دسترسی پیدا می‌کند. MSA یک Domain-level Account است که Password Management را در AD به‌طور خودکار انجام می‌دهد و Kerberos SPN یا Service Principal Name را نیز خودکار نگه می‌دارد، مشروط بر اینکه Functional Level مربوط به Domain برابر Windows Server 2008 R2 یا بالاتر باشد.

هر دو نوع Account محدودیتی دارند: فقط روی یک Server قابل استفاده‌اند. همان‌طور که گفته شد این موضوع برای Highly Available Multi-server Application Complexity ایجاد می‌کند. gMSA این مشکل را برطرف می‌کند و اجازه می‌دهد یک MSA به چند Server در Domain مرتبط شود؛ برای استفاده از این قابلیت Forest باید Functional Level مربوط به Windows Server 2012 یا بالاتر داشته باشد.

در همین صفحه Wizard می‌توان User Rights Assignment با نام Perform Volume Maintenance Tasks را به SQL Server Service Account اعطا کرد. با انتخاب آن SQL Server می‌تواند Database File ایجاد یا Grow کند بدون آنکه Empty Space را با Zero پر کند و این موضوع Performance عملیات File Creation و Growth را به‌طور چشمگیری بهتر می‌کند.

Trade-off آن یک Security Hole بسیار کوچک است: اگر قبلاً Data در همان بخش Disk وجود داشته باشد، با Tool تخصصی شاید بتوان آن Data را بازیابی کرد چون Overwrite نشده است. احتمال Exploit شدن آن به‌قدری کم است که نویسنده در همه محیط‌ها به‌جز محیط‌های فوق‌امن اعطای این Privilege را توصیه می‌کند.

انتخاب Collation

Tab دوم Server Configuration Page اجازه می‌دهد Collation را Customize کنید.

Collationها نحوه Sort کردن Data در SQL Server و Matching Behavior مربوط به Accent، Kana، Width و Case را تعیین می‌کنند. همچنین می‌توان Sorting و Matching را بر اساس Binary Representation یا Binary Code Point انجام داد.

اگر Collation از نوع Accent Sensitive باشد، SQL Server در Comparison کاراکتر è را برابر e نمی‌داند؛ در Accent Insensitive این دو برابر تلقی می‌شوند. Kana Sensitivity تعیین می‌کند آیا Character Set ژاپنی Hiragana با Katakana برابر باشد. Width Sensitivity تعیین می‌کند Representation تک‌بایتی Character با معادل دوبایتی آن برابر باشد یا نه.

Case Sensitivity تعیین می‌کند در Comparison حرف بزرگ با معادل کوچک خود برابر باشد یا نه. Listing 2-1 یک Temporary Table می‌سازد و Populate می‌کند و سپس Query مشابه را با دو Collation متفاوت اجرا می‌کند.

Listing 2-1 — Effect of Case Sensitivity of Matching

--Create a local temporary table
CREATE TABLE #CaseExample
(
        Name        VARCHAR(20)
)
--Populate values
INSERT INTO #CaseExample
        VALUES('James'), ('james'), ('John'), ('john')
--Count the number of entries for James, with case sensitive collation
SELECT COUNT(*) AS 'Case Sensitive'
FROM #CaseExample
WHERE Name = 'John' COLLATE Latin1_General_CS_AI
--Count the number of entries for James, with case insensitive collation
SELECT COUNT(*) AS 'Case Insensitive'
FROM #CaseExample
WHERE Name = 'John' COLLATE Latin1_General_CI_AI
--DROP temporary table
DROP TABLE #CaseExample

نتایج شکل 2-20 نشان می‌دهند Query نخست فقط یک نمونه از John را پیدا کرده است چون Case-sensitive Collation دارد، اما Query دوم با Case-insensitive Collation دو Result را Match می‌کند.

اثر Sensitivityهای مختلف Collation ممکن است نسبتاً روشن باشد، اما اثر Collation روی Sort Order کمی پیچیده‌تر است. Data فقط یک ترتیب «درست» ندارد. بعضی Collationها Alphabetical Sort دارند، در حالی که Writing Systemهای غیرالفبایی مانند Chinese ممکن است از Radical and Stroke Sorting استفاده کنند؛ سیستمی که Component مشترک Characterها را شناسایی کرده و سپس بر اساس تعداد Stroke مرتب می‌کند. Listing 2-2 نمونه اثر Collation بر Sort Order را نشان می‌دهد.

Listing 2-2 — Effect of Collations on Sort Order

--Create a temporary table
CREATE TABLE #SortOrderExample
(
        Food        VARCHAR(20)
)
--Populate the table
INSERT INTO #SortOrderExample
VALUES ('Coke'), ('Chips'), ('Crisps'), ('Cake')
--Select food using Latin1_General collation
SELECT Food AS 'Latin1_General collation'
FROM #SortOrderExample
ORDER BY Food
COLLATE Latin1_General_CI_AI
--Select food using Traditional_Spanish collation
SELECT Food AS 'Traditional_Spanish colation'
FROM #SortOrderExample
ORDER BY Food
COLLATE Traditional_Spanish_CI_AI

نتایج شکل 2-21 نشان می‌دهند مقدار Chips در دو Collation به شکل متفاوتی Sort شده است، زیرا در Spanish سنتی ترکیب ch یک Character جداگانه تلقی می‌شود و بعد از cz مرتب می‌شود.

دو نوع Binary Collation برای انتخاب وجود دارد. Binary Collationهای قدیمی فقط برای Backward Compatibility نگه داشته شده‌اند و Suffix آن‌ها BIN است. در این نوع، Characterها بر اساس Bit Pattern خود Match و Sort می‌شوند. Binary Collationهای جدید با Suffix مربوط به BIN2 شناخته می‌شوند و Data بر اساس Unicode Code Point برای Unicode Data و Code Point مربوط به ANSI Code Page برای Non-Unicode Data مرتب و Match می‌شود. Listing 2-3 رفتار BIN2 را در مقایسه با Case-sensitive و Case-insensitive Collation نشان می‌دهد.

Listing 2-3 — Binary Collation Sort Order

CREATE TABLE #CaseExample
(
        Name        VARCHAR(20)
)
--Populate values
INSERT INTO #CaseExample
        VALUES('James'), ('james'), ('John'), ('john')
--Select all rows with a case sensitive collation
SELECT name as [Case Sensitive]
FROM #CaseExample
Order by Name COLLATE Latin1_General_CS_AI

--Select all rows, with a case insensitive collation
SELECT name as [Case Insensitive]
FROM #CaseExample
Order by Name COLLATE  Latin1_General_CI_AI
SELECT name as [binary]
FROM #CaseExample
Order by Name COLLATE  Latin1_General_BIN2
--DROP temporary table
DROP TABLE #CaseExample

نتایج شکل 2-22 نشان می‌دهند چون Data بر اساس Code Point و نه Alphabetical Order مرتب شده، Valueهایی که با حرف بزرگ آغاز می‌شوند پیش از Valueهای دارای حرف کوچک قرار گرفته‌اند؛ زیرا این ترتیب با Code Point Characterها منطبق است.