نسخهی بتای شیرپوینت 2010 که با نام رمز Fourteen تهیه شده، مدتی است که در دسترس عموم میباشد. همانطور که مطلع هستید، از نام این محصول کلمه آفیس حذف و تبدیل به Microsoft SharePoint Server شده است (البته در نگارش نهایی آن).
پس از دریافت این محصول که فقط به صورت 64 بیتی ارائه خواهد شد، بر روی ویندوز سرور 2003 نگارش 64 بیتی نصب نشد.
برای نصب آن نیاز به پیش نیازهای زیر است:
- ویندوز سرور 2008 نگارش 64 بیتی (معمولی یا R2)
- نسخههای 64 بیتی اس کیوال سرور 2008 یا 2005
- IIS7 و دات نت فریم ورک 3 و نیم
سایر موارد مورد نیاز را به صورت خودکار از اینترنت دریافت کرده و نصب میکند. کلا پروسه نصب مشابهی با شیرپوینت 2007 دارد.
و به صورت خلاصه اگر قصد استفاده از اکثر محصولات جدید مایکروسافت را دارید، باید سخت افزار و سیستم عامل 64 بیتی را تهیه نمائید.
EF Code First #4
- در EF 6 این جدول MigrationHistory دیگر سیستمی نیست.
- یوزر sa دسترسی مدیریتی دارد (حالت اول). احتمالا در حالت دوم که یکپارچه با ویندوز است، اکانت وارد شده به سیستم نیز admin است؛ وگرنه دسترسی لازم را نخواهد داشت که دیتابیس ایجاد کند.
بازگردانی پایگاه داده بدون فایل لاگ
دیتابیسی هست که به حالت InRecovery رفته. در SQL Server Management Studio در لیست دیتابیسها وجود داره ولی جلوی اسم اون عبارت InRecovery رو نوشته. در این حالت که هست نمیشه که ساختار این دیتابیس اعم از جدول ها، دادههای داخل اون جداول، stored procedureها و ... رو ببینیم. از اطلاعات اون هم پشتیبان گیری نشده و به دادههای داخل اون نیاز هست. شما میدونید مشکل چیه و چطور حل میشه ؟
با تشکر
در نرم افزارهای بزرگ و چند کاربره، اتصال به بانک اطلاعاتی کامپیوتر سرور، یکی از نیازهای اساسی برنامه نویسان محسوب میگردد. در این بخش با دو اصطلاح بسیار مهم سروکار داریم.
1. کلاینت (Client): منظور از کلاینت کامپیوتری است که میخواهد به سرور متصل گردد و از SQL کامپیوتر سرور خدماتی را دریافت نماید.
2. سرور (Server): کامپیوتری است که میخواهیم به آن متصل شویم و دادهها را بصورت متمرکز بر روی آن ذخیره و بازیابی نماییم.
به دو روش میتوان به سرور متصل شد:
1. Windows Authentication
در این روش جهت اتصال به بانک اطلاعاتی، کامپیوتر مبدا یا Client باید عضو شبکه ای باشد کهServer در آن وجود دارد. در واقع برای شبکه هایی استفاده میشوند که دارای Domain می باشند وClient به عنوان یک کاربر شناخته شده در سرور تعریف شده است.
2. SQL Authentication
در این روش کلاینت به عنوان یک کاربر یا Login در SQL تعریف شده است و دارای نام کاربری و رمز عبور میباشد.
جهت اتصال از راه دور به یک سرور دارای SQL، باید تنظیمات زیر را برای کامپیوتر سرور انجام دهیم:
1. به SQL Server کامپیوتر سرور متصل شوید.
2. در پنجره Object Explorer بر روی نام سرور (اولین آیتم موجود در لیست) کلیک راست کنید و گزینهProperties را انتخاب نمایید.
3. در پنجره ظاهر شده (Server Properties) و در قسمت Select a page (سمت چپ پنجره) بر رویSecurity کلیک کنید.
4. در سمت راست پنجره گزینه SQL Server and Windows Authentication mode را انتخاب کنید.
5. دکمه OK را انتخاب کنید. پنجره پیغامی مبنی بر Restart کردن سرور نمایش داده میشود. این پنجره را تایید کنید.
6. مجددا بر روی نام سرور کلیک راست کنید و گزینه Restart را انتخاب نموده و در پیغام ظاهر شده Yesرا انتخاب نمایید.
تا به اینجا سرور آماده پذیرش اتصال از راه دور بصورت SQL Authentication می باشد. حال نوبت به تعریف یک Login می باشد تا توسط این Login بتوانید به سرور از راه دور متصل شوید. مراحل زیر را برای تعریفLogin دنبال کنید:
1. در پنجره Object Explorer به مسیر Security > Logins بروید.
2. بر روی پوشه Logins کلیک راست نموده و گزینه New Login… را انتخاب نمایید.
3. در پنجره ظاهر شده در بخش Login name نامی را به کاربر اختصاص دهید. (به عنوان مثال user1)
4. گزینه SQL Server authentication را انتخاب نموده و در بخش Password و Confirm password رمز عبوری را به این کاربر اختصاص دهید. (به عنوان مثال abc123)
5. گزینه Enforce password policy را از حالت انتخاب خارج کنید تا رمز عبور را از قید سیاستهای رمزگذاری ویندوز خارج کنید.
6. در قسمت Select a page (سمت چپ پنجره) بر روی Server Roles کلیک کنید.
7. در سمت راست پنجره گزینه sysadmin یا هر نوع دسترسی دیگری را که مایل هستید انتخاب نمایید.
توجه: با انتخاب sysadmin کاربر ایجاد شده به کل سرور و بانکهای اطلاعاتی دسترسی کامل یاAdmin دارد. اگر نمیخواهید کاربر چنین دسترسی داشته باشد، در بخش فوق فقط گزینه public انتخاب شده باشد.
8. در قسمت Select a page (سمت چپ پنجره) بر روی User Mapping کلیک کنید. در این بخش نحوه دسترسی کاربر را به بانکهای اطلاعاتی موجود، مشخص میکنیم.
9. در سمت راست پنجره و در بخش Users mapped to this login یک یا چند بانک اطلاعاتی را که میخواهید توسط این Login قابل دسترسی باشند را انتخاب نمایید.
10. پس از انتخاب هر بانک اطلاعاتی، در قسمت پایین (Database role membership for:) نوع دسترسی کاربر به آن Database را انتخاب کنید. در اینجا من db_owner را انتخاب میکنم تا کاربر دسترسی کامل به بانک اطلاعاتی انتخاب شده را داشته باشد.
11. دکمه OK را انتخاب کنید تا Login مورد نظر ساخته شود.
حالا میتوانید از راه دور و حتی از روی خود سرور با کاربر ایجاد شده به سرور متصل شوید. برای این منظور SQL را Disconnect نمایید و یا یکبار SQL Server Management Studio (SSMS) را ببندید و دوباره اجرا نمایید. در پنجره Connect to Server اطلاعات زیر را وارد نمایید:
Server name :نام یا IP سرور (به عنوان مثال 192.168.0.1)
Authentication: انتخاب گزینه SQL Server Authentication
Login: طبق مثال user1
Password: طبق مثال abc123
پس از ورود با مشخصات فوق فقط میتوانید به بانک اطلاعاتی دسترسی باشید که در قسمت User Mapping انتخاب کرده بودید. اگر sysadmin را انتخاب کرده باشید به تمامی بانکهای اطلاعاتی موجود دسترسی دارید.
برخی مشکلات اتصال از راه دور
ممکن است در زمان اتصال از راه دور با مشکل عدم امکان اتصال به سرور مواجه شوید. برای این منظور و اطمینان از صحت تنظیمات سرور، موارد زیر را در سرور بررسی نمایید تا بدرستی تنظیم شده باشند:
1. به مسیر Start > All Programs > Microsoft SQL Server 2008/2005 > Configuration Tools > SQL Server Configuration Manager مراجعه کنید و موارد زیر را بررسی نمایید:
1.1. بر روی SQL Server Services کلیک کنید و در سمت راست پنجره بررسی کنید که ستون Stateمربوط به SQL Server Browser و SQL Server در وضعیت Running باشد.
1.2. بر روی آیتمهای زیر مجموعه SQL Server Network Configuration کلیک کنید و در سمت راست پنجره بررسی کنید که آیتم های Shared Memory، Named Pipes و TCP/IP در وضعیت Enabled باشند.
1.3. بر روی آیتم SQL Native Client Configuration > Client Protocols کلیک کنید و در سمت راست پنجره بررسی کنید که آیتم های Shared Memory، Named Pipes و TCP/IP در وضعیت Enabled باشند.
2. بررسی کنید که فایروال سیستم سرور غیر فعال باشد و یا SQL Server به برنامه های Trust فایروال اضافه شده باشد.
EF Code First #2
سؤال شما هم بحث کلاینت سروری است و نه بحث کلاینت تنها که EF روی آن مشغول به کار است.
- میشود در متد Seed ایی که در بالا توضیح دادم در SQL Server تریگر درست کرد. (که مثلا اگر کاربر دیگری به شرط اینکه این کاربر جزو کاربران تعریف شده در خود SQL Server باشد نه در برنامه شما، اتفاق خاصی رخ دهد. برنامه شما هم بدیهی است باید سرور را مدام چک کند تا از این مساله مطلع شود)- SQL Server مبحثی دارد به نام Service Broker : (^). توسط آن میتوان از طریق سرور به کلاینت اطلاع رسانی کرد. بازهم خارج است از بحث یک ORM. یا تمام ORMهای موجود. - EF مبحثی دارد به نام Concurrency check که اگر شخصی در شبکه بر روی رکوردی که همین الان شما مشغول به کار هستید، تغییری را ایجاد کرد، به شما اطلاع رسانی کند. (در قسمتهای بعدی بحث خواهد شد). البته این هم خودکار نیست. لازم است یک رفت و برگشت به سرور انجام شود.- entity framework auditing هم میسر است. خودکار نیست. در همان کلاس Context فوق که از DbContext مشتق میشود میتوان متد تحریف شده public override int SaveChanges را تعریف کرد. در اینجا میتوان به تمام تغییراتی که قرار است اعمال شوند دسترسی داشت. مثلا آنها را در یک جدول مجزا ثبت کرد. بدیهی است برنامه بعدا نیاز خواهد داشت از این جدول گزارشگیری کند.
مطلبی چندی قبل در مورد "ذخیره سازی فایلها در دیتابیس یا استفاده از فایل سیستم متداول؟" منتشر گردید، جهت برشمردن فواید ذخیره سازی فایلها در دیتابیس (+). اما معایب این نوع ذخیره سازی بررسی نشدند:
الف) اختصاص یافتن قسمتی از بافر SQL Server به این امر.
ب) با توجه به قرار گرفتن دادههای BLOB در دیتابیس ، transaction log قابل توجهی تولید خواهد شد. (+)
ج) بیش از 2GB را نمیتوان در فیلدهایی از نوع varbinary(max) ذخیره کرد.
د) به روز رسانی BLOB ها سبب ایجاد fragmentation میشود.
مایکروسافت برای رفع این مشکلات در SQL Server 2008 قابلیت جدیدی را ارائه داده است به نام FileStream که در طی مقالاتی به بررسی آن خواهیم پرداخت.
FILESTREAM موتور دیتابیس اس کیوال سرور را با سیستم فایل NTFS یکپارچه میکند؛ به این صورت که دادههای BLOB از نوع varbinary(max) را به صورت فایل بر روی سیستم ذخیره خواهد کرد. سپس با استفاده از دستورات T-SQL میتوان این فایلها را ثبت، حذف، به روز رسانی، جستجو و بک آپ گیری کرد. این قابلیت نیز از فیلدهای varbinary(max) استفاده میکند؛ اما اکنون ویژگی و برچسب FILESTREAM به این نوع فیلدها الصاق خواهد شد. FILESTREAM data باید در FILESTREAM filegroups ذخیره شوند. FILESTREAM filegroups در حقیقت همان پوشههای فایل سیستم میباشند. به آنها data containers نیز گفته میشوند که مرزی هستند بین ذخیره سازی دادهها در فایل سیستم و در دیتابیس.
مزایای سیستم FileStream چیست؟
الف) سیستم transaction مختص به خود را داشته، به همین جهت سبب رشد غیر منطقی حجم فایل transaction log دیتابیس اصلی نمیشوند.
ب) هنگام به روز رسانی فیلدهایی از این دست، صرفا ایجاد یا حذف یک فایل مد نظر است؛ بنابراین fragmentation ایجاد شده در این حالت بسیار کمتر از روش استفاده از فیلدهایی از نوع varbinary(max) میباشد.
ج) استفاده از NT system cache جهت کش کردن اطلاعات که سبب بالا بردن بازدهی بانک اطلاعاتی خواهد شد.
د) از buffer pool اس کیوال سرور در این حالت استفاده نشده (مطابق قسمت ج) و این حافظه جهت امور روزمرهی اس کیوال سرور کاملا مهیا خواهد بود.
ه) محدودیت 2GB فیلدهایی از نوع varbinary(max) با توجه به ذخیره سازی این نوع BLOBs در فایل سیستم، دیگر وجود نخواهد داشت.
چه زمانی بهتر است از FileStream استفاده شود؟
الف) فایلهایی که ذخیره میشوند به طور متوسط بیش از یک مگابایت حجم داشته باشند. (برای کمتر از این مقدار varbinary(max) BLOBs کارآیی بهتری را ارائه میدهند). هر چند این مرز یک مگابایت مطابق اطلاعات books online است اما تجربیات کاری نشان میدهند که این سقف را باید 256 کیلوبایت درنظر گرفت.
ب) قابلیت خواندن سریع اطلاعات فایلها مد نظر باشد (بررسی کارآیی مطابق تصویر زیر از MSDN). سیستم NTFS نسبت به SQL Server در خواندن فایلهای حجیم سریعتر عمل میکند.
ج) اگر از یک معماری middle tier در برنامههای خود در حال استفادهاید.
د) زمانیکه نیاز باشد تا اطلاعات relational و non-relational در یک تراکنش مورد استفاده قرار گیرند.
نکاتی را که باید هنگام ذخیره سازی اطلاعات در FileStream در نظر داشت
الف) هنگامی که یک جدول حاوی فیلدی از نوع FileStream میباشد، باید دارای فیلد ID منحصربفرد نیز باشد.
ب) data containers ایی که پیش از این در مورد آنها صحبت شد، نباید تو در تو باشند.
ج) FILESTREAM filegroups بر روی درایوهای فشرده شده نیز میتوانند قرار داشته باشند.
FileStream از دیدگاه امنیت
امنیت دادههای FileStream در اس کیوال سرور دقیقا همانند امنیت سایر اطلاعات ذخیره شده در دیتابیس است (دسترسی در حد جدول و یا فیلد). اگر کاربری دسترسی به فیلد FileStream در یک جدول داشته باشد، میتواند آن فایل را گشوده و استفاده کند. رمزنگاری بر روی این ستونها پشتیبانی نمیشود. تنها اکانتی که اس کیوال سرور تحت آن در حال اجرا است دسترسی به FILESTREAM container دارد. همچنین توصیه شده است که به هیچ اکانت دیگری این دسترسی داده نشود. زمانیکه یک دیتابیس آغاز و مشغول به کار میشود، اس کیوال سرور دسترسی به FILESTREAM data container را محدود خواهد کرد و دسترسی به این اطلاعات تنها از طریق دستورات T-SQL و یا OpenSqlFilestream API میسر خواهد بود. بدیهی است زمانیکه اس کیوال سرور متوقف شود، این اطلاعات بدون هیچگونه محدودیتی قابل دسترسی بوده و تنها محدودیتهای سیستمی به آنها اعمال خواهند شد (که این مورد باید مد نظر باشد).
نگهداری FileStream
FileStream به صورت فیلدهای varbinary(max) یکپارچه با دیتابیس ذخیره میشود؛ بنابراین نحوهی تهیه پشتیبان از آنها همانند روشهای متداول است بدون هیچگونه تغییری (و این اطلاعات در بک آپ دیتابیس لحاظ میشوند). اگر نیاز بود هنگام تهیه پشتیبان از این نوع دادهها بک آپ گرفته نشود، میتوان از partial backup با پارامترهای مربوطه استفاده کرد.
ادامه دارد ...