تبليغاتX
آموزش تخصصی کامپیوتر
آموزش تخصصی کامپیوتر
کاربر مهمان، خوش آمديد!
موضوعات
موضوعات

آرشيو مطالب

امکانات

آخرين ويروسها

آمار بازديد


پيام خوش آمدگويي

با سلام به تمام علاقمندان دنياي کامپيوتر hello to all people who are interested in computers

از بازديد شما متشکرم special thanks for your visit

از اين پس در اين وبلاگ جديدترين مطالب در زمينه برنامه نويسي دلفي - شبکه - اس کيو ال سرور و بهترين لينک ها را ببينيد .

از کليه بازديدکنندگان تقاضا داريم در جهت تکميل سايت و کاربردي شدن آن نقطه نظرات خود را با ما در ميان بگذاريد . سوالات خود را در اين زمينه از ما بخواهيد.

سيستم جامع آموزشگاه رانندگي : نرم افزاري است خاص آموزشگاه رانندگي که عمليات مربوط به حسابداري آموزشگاه را نيز انجام ميدهد.توضيحات کامل را مطالعه کنيد




مجموعه مقالات تخصصی نرم افزار9

ارسال شده در مورخه : دوشنبه هفدهم فروردین 1388 ساعت 7:38 توسط محمد جهانشاهی |

مجموعه مقالات تخصصی نرم افزار8

ارسال شده در مورخه : دوشنبه هفدهم فروردین 1388 ساعت 7:37 توسط محمد جهانشاهی |

مجموعه مقالات تخصصی نرم افزار7

ارسال شده در مورخه : دوشنبه هفدهم فروردین 1388 ساعت 7:36 توسط محمد جهانشاهی |

مجموعه مقالات تخصصی نرم افزار7

ارسال شده در مورخه : دوشنبه هفدهم فروردین 1388 ساعت 7:36 توسط محمد جهانشاهی |

مجموعه مقالات تخصصی نرم افزار6

ارسال شده در مورخه : دوشنبه هفدهم فروردین 1388 ساعت 7:35 توسط محمد جهانشاهی |

مجموعه مقالات تخصصی نرم افزار - 1000 مقاله


ارسال شده در مورخه : دوشنبه هفدهم فروردین 1388 ساعت 7:23 توسط محمد جهانشاهی |

اس کیو ال سرور 2008 sql server







اگر در یک نگاه بخواهیم پرمخاطب ترین نرم افزار مدیریت بانک های اطلاعاتی رابطه ای را مورد بررسی قرار دهیم بی شک همه نگاه ها به سمت Microsoft SQL Server خواهد بود.
سادگی استفاده از این نرم افزار و همچنین هماهنگی کامل با NET Platform. ماکروسافت باعث شده تا بیش از 50% از برنامه نویسان و توسعه دهندگان به این پایگاه داده گرایش پیدا کنند.
و هم اکنون جدیدترین نسخه از این نرم افزار قدرتمند منتشر شده است که قابلیت های جدید اضافه شده به این نرم افزار قدرتمند باعث شده است که Microsoft SQL Server 2008 حال بتواند رقیب بسیار خطرناکی برای رقیب دیرینه خود یعنی Oracle شود.






این نرم افزار مجهز به ابزارهای جدیدی برای نظارت و مدیریت بوده و همچنین مناسب استفاده برای بانک های اطلاعاتی بسیار بزرگ می باشد و علاوه بر آن در نسخه جدید سرعت کار و سهولت استفاده افزایش چشم گیری یافته است.


2008 Microsoft SQL Server دارای نسخه های مختلفی می باشد که هرکدام کارایی ، مخاطبین و قیمت های متفاوتی دارد :
SQL Server 2008 Enterprise -

این نسخه در حقیقت پیشرفته ترین ، کاملترین ، و گران ترین نسخه از این نرم افزار است .
توانایی کار با بانک های اطلاعاتی بسیار بزرگ ، توانایی انجام پردازش های بسیار زیاد و انجام تحلیل های پیچیده اطلاعات باعث شده تا شرکت های نرم افزاری برای بانک های اطلاعاتی که با حجم داده بسیار زیاد سرو کار دارند از این نسخه استفاده کنند .


SQL Server 2008 Standard -

شرکت های متوسط بیشتر از این نسخه استفاده می کنند یکی به این دلیل که بانک های اطلاعاتی برزگ را پشتیبانی می کند و دیگری قیمت پایین تر نسبت به نسخه Enterprise است .
عدم توانایی این نسخه در تحلیل های پیچیده دلیل قیمت پایین تر این نسخه نسبت به نسخه Enterprise است .

SQL Server 2008 Workgroup -

یکی از ارزان ترین نسخه ها می باشد و بیشتر برای شرکت های کوچک و سرویس دهنده های وب مورد استفاده قرار می گیرد .
این نسخه هم به راحتی می تواند به نسخه های Standard و Enterprise ارتقا پیدا کند .

SQL Server 2008 Web -

این نسخه برای اولین باری است که عرضه می شود و مخاطبین اصلی این نسخه را شرکت های خدمات میزبانی وب تشکیل می دهند . این نسخه مجهز به ابزارهای بسیار کاربردی برای پشتیبانی از برنامه های کاربردی گران قیمت و بسیار پیچیده تحت وب است که در سرویس های میزبانی وب به کار می روند .
SQL Server 2008 Developer -

از نام این نسخه می توان دریافت که این نسخه مخصوص برنامه نویسان و توسعه دهندگان می باشد و به همین دلیل دارای قیمت پایینی است . این نسخه هیچ تفاوتی با نسخه Enterprise ندارد و تمامی امکانات آن را دارا می باشد.
قیمت پایین این نسخه باعث شده تا بیشتر شرکت های نرم افزاری که با بانک های اطلاعاتی سرو کار دارند از این نسخه استفاده کنند .
با این کار دیگر لازم نیست که شرکت ها برای انجام عملیات تست و یا پیش نمایش ملزم به خرید نسخه Enterprise باشد.
در صورتی هم که شرکت تصمیم به عرضه تجاری محصول خود کرد به راحتی می تواند این نسخه را به نسخه Enterprise ارتقا دهد .

SQL Server 2008 Express -

این نسخه به صورت رایگان عرضه می شود.
و به اصطلاح یک نسخه کوچک شده از این نرم افزار می باشد و بطبع این نسخه دارای امکانات بسیار کمتری نسبت به نسخه های دیگر می باشد .
از این نسخه بیشتر برای آموزش و ساخت برنامه های کوچک تحت دسکتاپ و سرور مورد استفاده قرار می گیرد که این امر به برنامه نویسان این اجازه رو می دهد که اگر مشغول نوشتن یک پروژه با یک بانک اطلاعاتی کوچک هستند بتوانند از این نسخه استفاده کنند .
در ضمن این نسخه به صورت پیش فرض روی نسخه های Visual Studio 2005 , 2008 قرار داده شده است و برنامه نویسان این Platform می توانند به راحتی از این نسخه استفاده کنند.

قابلیت های جدید اضافه شده در Microsoft SQL Server 2008 عبارتند از :

- اضافه شدن Persian Collection ( خبری خوش برای جامعه پارسی )

- اضافه شدن نوع داده datetime2 و همچنین بهبود و افزایش دقت برای نگهداری نوع داده DateTime

- اضافه شدن نوع های داده geography و geometry برای شرکت های نرم افزاری که با نقشه های زمینی و هوایی سرو کار دارند

- بهبود کارایی و افزایش سرعت بازیابی اطلاعات نسبت به نسخه های قبل

- قابلیت Auto Complete کردن خودکار

- قابلیت Syntax Checking یا غلط یابی خودکار

- مقدار دهی متغیر های به صورت خطی

- ارتقا و بهبود چشم گیر Transact-SQL

- فابلیت trace کردن پرسش ها

- قابلیت ایجاد User Defined Types و Defined Aggregates User با ظرفیتی بالاتر از 8
KB

-- قابلیت ارسال داده های بزرگ به توابع و پروسجر ها به وسیله قابلیت جدید Table-Value Parameters

- توانایی انجام چندین پردازش توسط دستوری جدید به نام MERGE

- Model hierarchical data برای ایجاد نمودارهای درختی و چارت ها توسط یکی از نوع های داده جدید به نام HierarchyID

- سیستم یکپارچه و ارتقا یافته Full-Text Indexes که با سرعتی بالا متن ها را مورد جست و جو قرار می دهد

- اضافه شدن Linq برای توسعه دهندگانی که با Linq آشنایی دارند

- مدیریت بر روی فایل ها توسط قابلیت FILESTREAM Data Type

- و ...

ارسال شده در مورخه : سه شنبه بیست و هشتم آبان 1387 ساعت 9:31 توسط محمد جهانشاهی |

Stored Procedure Generator

این هم یک برنامه جالب برای تولید پراسیجرها در اس کیو ال سرور 2005 از جناب آقای delphiassistant

در SQL Server Enterprise Manager 2000 ابزاری وجود داشت که به کمک آن می شد به سختی Stored Procedure ها را بطور نیمه خودکار ایجاد کرد و از نوشتن آنها بصورت دستی خلاص شد. اون ابزار خیلی خوب نبود، اما بقول قدیمی ها کوزه شکسته ای بود که گاهی وقتا ازش آب می خوردیم.

فقدان اون ابزار در SQL Server Management Studio 2005 باعث شد دنبال یک ابزار آماده بگردم، و راه دست ترین چیزی که یافتم این بود: EZStoredProc

ابزار فوق هم تمام کارهایی که من میخواستم رو انجام نمی داد، و از نسخه آزمایشی اش استفاده میکردم، اونقدرها هم برام نمی ارزید که قیمت 45 دلاری اش رو پرداخت کنم و بخرمش.

این روزها کمی وقت آزاد بیشتری دارم و میتونم بیشتر برای بازی با کد وقت بگذارم، بنابراین تصمیم گرفتم خودم یکی مثل اون، البته با قابلیت های مد نظرم رو بنویسم. نتیجه اش هم چیزی شده که تصویرش رو در زیر می بینید:



اگر شما هم دوست دارید از یک ابزار آماده برای تولید Stored Procedure هاتون استفاده کنید می تونید از این برنامه استفاده کنید. چیز ساده ای است، اگر پیشنهادی برای بهتر شدنش دارید در خدمت هستم.

کار کردن با این ابزار خیلی ساده است، اسم سرور رو وارد میکنید، دکمه Connect رو کلیک می کنید، دیتابیس، و سپس جدول مورد نظر رو انتخاب میکنید و کلید Generate ... رو کلیک میکنید.
برای ایجاد Stored Procedure ها کافیه اسکریپت SQL ایجاد شده رو در SQL Management Studio در یک Query جدید Copy/Paste کنید و اجرایش کنید.

بعدا که این برنامه کاملتر بشه سورس اش رو هم جهت مقاصد آموزشی ارائه خواهم داد.

تولید کننده خودکار Stored Procedure برای SQL Server:
لینک پروژه در CodePlex.com | صفحه مربوط به توضیحات

ارسال شده در مورخه : دوشنبه یازدهم شهریور 1387 ساعت 7:48 توسط محمد جهانشاهی |

ویرایش نهایی SQL Server 2008 ماه آگوست عرضه خواهد شد.

بعد از شنیده شدن خبرهایی مبنی بر تاخیر سه ماهه دیگر در انتشار SQL Server 2008، مایکروسافت اعلام کرده است که نسل جدید پایگاه داده ها طبق وعده داده شده در سه ماهه سوم سال جاری میلادی منتشر خواهد شد.
مایکروسافت در کنفرانس Worldwide Partner هفته که در هیوستن برگزار شد اشاراتی بر قرار گرفتن SQL Server 2008 در لیست فروش در ماه آگوست خبر داد.
Fausto Ibarra مدیر جدید محصول SQL Server 2008 در مصاحبه خود اعلام کرد که SQL Server 2008 در انتهای سه ماهه سوم سال (پایان سپتامبر) به صورت نسخه RTM منتشر خواهد شد. او گفت:"ما در مراحل نهایی تست هستیم. کاندیدای انتشار نهایی توسط دهها هزار نفر دانلود شد و ما برای دیدن محصول نهایی در بازار بسیار هیجان زده هستیم."
مایکروسافت قصد دارد که انتشار SQL Server 2008 را با انتشار سرویس پک 1 ویژوال استودیو 2008 و دات نت فریم ورک 3.5 که هم اینک در سطح بتا قرار دارند، هم زمان کند. در این میان Entity Framework برای مایکروسافت از اهمیت زیادی برخوردار است.
قیمت SQL Server 2008 بر اساس اظهار مایکروسافت تغییر نخواهد کرد.

ارسال شده در مورخه : پنجشنبه دهم مرداد 1387 ساعت 8:0 توسط محمد جهانشاهی |

10 ویژگی اس کیو ال سرور 2008

10 ویژگی و امکانات جدید sql server 2008

the top 10 new developer features in Microsoft’s new SQL Server 2008 release.

1. Language Integrated Query (LINQ)—From a database developer’s perspective, undoubtedly
the most signifi cant new feature in SQL Server 2008 is support for LINQ. LINQ is an evolutionary step
forward for database developers. LINQ simplifi es the database development process by enabling
developers to write queries directly in either native VB or C#. This speeds up application development
by providing the developer with immediate feedback through IntelliSense as well as compile time error
checking that wasn’t possible using the older ADO.NET and T-SQL development paradigm.
2. IntelliSense in SQL Server Management Studio (SSMS)—Another very welcome
enhancement is the addition of IntelliSense to SSMS. The new IntelliSense support in SSMS provides
T-SQL statement completion. It can also automatically display the names of database objects and
provide parameter prompting for stored procedures and functions.
3. New FILESTREAM Data Type—Designed to solve the problem of unstructured large object
(LOB) storage, the new FILESTREAM combines the performance of the native NTFS fi le system with
the transactional integrity of the relational database. The FILESTRAM data type enables unstructured
data to be stored in the NTFS fi le system. The SQL Server relational engine manages the link between
the columns defi ned using the FILESTREAM type and the fi les in the fi le system. SQL Server is
responsible for all transactional integrity including backing up and restoring fi le system data.

44. New Date/Time Data Types—Although the old DATETIME data type offered basic date and
time data storage formatting the data was always a problem; plus, it introduced diffi culties in converting
data from other database systems that used discreet date and time column values. The new DATE
data type is a native SQL Server data type that’s ANSI compliant. It uses the format YYYY-MM-DD
and can contain values from 0001-01-01 to 9999-12 The TIME data type, complements the DATE data
type. TIME uses the format hh:mm:ss[.nnnnnnn] and can contain values from 00:00:00.0000000 to
23:59.59.9999999.
5. New DataTime2 and DateTimeOffset Data Types—DATETIME2 and DATETIMEOFFSET
are designed to address the need for more precise date/time storage and time-zone-aware date
values. DATETIME2 uses the format YYYY-MM-DD hh:mm:ss[.nnnnnnn]. It can store values ranging
from 0001-01-01 00:00:00.0000000 through 9999-12-31 23:59.59.9999999. DATETIMEOFFSET
enables the same date/time storage as DATETIME2 but it’s also time-zone aware.
6. New Spatial Data Types—The new GEOGRAPHY and GEOMETRY spatial data types
facilitate the development of mapping applications. GEOGRAPHY uses a geodetic (round earth)
model. It stores points, lines, polygons, and collections of latitude and longitude coordinates.
GEOMETRY uses a planar (fl at earth) model, unlike GEOGRAPHY, which is primarily designed for
navigation and mapping. GEOMETRY complies with Open Geospatial Consortium standards for the
representation of geographic features.
7. T-SQL Merge—The MERGE statement also allows you to merge the rows from multiple tables.
You can choose to update matched rows, insert unmatched rows, or delete unmatched rows from the
primary table. When the MERGE statement runs it can check whether a row exists and then execute
the required INSERT, UPDATE, or DELETE statement. The schema of the merged tables does not
have to be identical and the MERGE statement can specify columns to match and update.
8. Table-valued Parameters—Another cool new developer feature in SQL Server 2008 is support
for passing tables as parameters to stored procedures. Table variables have been supported since
SQL Server 2000. However, you were never able to use them as parameters. Using table variables
as parameters can help simplify your code and eliminate the system overhead otherwise required to
create and manage temporary tables.
9. Support for Sync Services—SQL Server 2008’s support for Sync Services in the .NET
Framework 3.5 enables mobile applications to provide mobile users with the same application
experience whether they are connected or disconnected. Mobile applications use SQL Server Compact
edition as a local data store. Sync Services then periodically connects the mobile application to SQL
Server 2008, providing bi-directional updates with from the mobile application. Sync Services handles
the connection and synchronization between SQL Server and the mobile data store.
10. PowerShell Integration—PowerShell is Microsoft’s newest object oriented scripting language.
SQL Server 2008 provides a new SQL Server Relational Engine provider that enables PowerShell
scripts to access SQL Server database objects. In addition, a new SQL Server Policy Management
provider enables you to use PowerShell to manipulate SQL Server’s new policy-based
management framework.

ارسال شده در مورخه : پنجشنبه سیزدهم تیر 1387 ساعت 7:56 توسط محمد جهانشاهی |

مقايسه فني مهم‌ترين بانك‌هاي اطلاعاتي جهان؛ Oracle و SQL Server


شركت مايكروسافت مدعي است كه ابزارهاي جديدي براي مديران بانك‌هاي اطلاعاتي يا همان DBAها در نسخه جديد SQL Server 2005 قرار داده است كه بسيار خوب توانسته است مشكلات نسخه قبلي آن را مرتفع نمايد، اما جالب اينجا است كه همه امكاناتي كه SQL Server 2005 به تازگي براي DBAها فراهم كرده است، از نسخه Oracle 8i در نرم‌افزار اوراكل موجود بوده است.
درباره نصب اين دو نرم‌افزار بايد گفت كه نصب اوراكل از SQL Server هنوز بسيار مشكل‌تر است و كار كردن با آن سخت‌تر؛ و شايد اين دلايل باعث مي‌گردد برخي از برنامه‌نويسان به سمت SQL Server بروند. DBA شدن در بانك‌اطلاعاتي SQL Server كار سختي نيست. كافي است مدتي با آن نرم‌افزار كار كرده باشيد، و چند ماهي تجربه داشته باشيد. ولي DBA شدن حرفه‌اي در اوراكل كار بسيار دشواري است.

با نگاهي به اين دو بانك اطلاعاتي مي‌توان به اين نكته رسيد كه درست است كه SQL Server 2005 بسيار كارآمد است و پيشرفت‌هاي زيادي نسبت به نسخه قبلي خود داشته است، اما در برنامه‌هاي پيچيده يا سيستم‌هاي ناهمگون، و اگر از پلتفرم‌هاي متفاوت استفاده شود،‌ نمي‌تواند جوابگوي نيازها باشد و در نتيجه اوراكل گزينه مناسب‌تري خواهد بود، ولي در صورتي كه با برنامه‌هاي كوچك و متوسط سروكار داريد، SQL Server مي‌تواند راه‌حل خوبي باشد.

از لحاظ قيمت (البته نه در ايران كه اكثراً قانون كپي‌رايت را رعايت نمي‌كنند) قيمت SQL Server كمتر از اوراكل است و سرويس‌هاي ارائه شده توسط SQL Server را مي‌توان در صورت لزوم خريداري نمود، ولي اوراكل تقريباً شما را از تمام چيزهايي كه در بانك‌هاي اطلاعاتي مي‌خواهيد، بي‌نيازمي‌نمايد؛ البته بهاي آن گران است.


مقدمه

بدون‌شك مي‌توان گفت كه بانك‌هاي اطلاعاتي اوراكل و SQL Server، از مهم‌ترين بانك‌هاي اطلاعاتي امروز به شمار ميآيند. اين سؤال كه كدام يك از اين دو از ديگري بهتر است، ممكن است فكر بسياري از برنامه‌نويسان و شركت‌هاي توليد كننده نرم‌افزار را مشغول كرده باشد.

از طرفي مايكروسافت، به عنوان غول نرم‌افزاري ادعا مي‌كند كه SQL Server از اوراكل‌ ساده‌تر و بهتر است. اوراكل هم از سوي ديگر مي‌گويد محصول او از خيلي جهات بر SQL Server برتري دارد.

اين مقاله سعي دارد به سؤالات شما در مورد تفاوت‌هاي فني اين دو بانك اطلاعاتي تا حدي جواب دهد. در ابتداي اين مقاله معماري اين دو بانك اطلاعاتي با هم مقايسه مي‌گردد، سپس كامپوننت‌هاي شبكه هر دو بانك اطلاعاتي با يكديگر مقايسه مي‌شوند.

در اين مقاله امكانات مرتبط با كارايي پايگاه‌هاي اطلاعاتي‌ (Performance)، ابزار (Utility) و Replication در بانك‌هاي اطلاعاتي بسيار بزرگ يا همان VLDB يا Very Large Data Bases و OLTP يا Online Transaction Processing مورد بررسي قرار خواهند گرفت و ابزارهاي جديد SQL Server 2005 كه در حقيقت سعي دارد با اوراكل رقابت كند، مورد بررسي قرار خواهند گرفت‌.‌

معماري بانك اطلاعاتي

در اوراكل هر ديتابيس شامل تمامي امكانات پايگاه رابطه Relational Database ،Instance (پروسه‌هاي پايگاه داده‌هاي اوراكل و بافرها، فايل‌هاي تنظيمي مانند config.ora و init.ora، لوگ‌هاي بازگشت به حالت قبلي يا Redo Logs؛ SYSTEM Teblespace و ديگر انتخاب‌هاي دلخواه است.

در نسخه جديد SQLServer، ديتابيس در واقع به گروهي از اسكيما (Schema)هاي پايگاه داده گفته مي‌شود كه به صورت فيزيكي در فايل‌ها ذخيره مي‌شوند. ديتابيس‌ها به دو صورت تعريف شده از طرف كاربر (user defined) و تعريف شده از طرف سيستم (system defined) تقسيم مي‌شوند.

در SQL Server يك نمونه يا Instance مي‌تواند چندين ديتابيس را پشتيباني نمايد و در هر كامپيوتر چندين Instance مي‌تواند با هم كار كند.

وقتي SQL Server را راه‌اندازي مي‌كنيد، ديتابيس‌هايي همچون MD يا Msdb database، Model Database (براي پشتيباني كردن Agentها) و Tempdb Database (پايگاه اطلاعات موقت مانند پايگاه موقت اوراكل OracleTemp Tablespace؛ البته با اين تفاوت كه در SQL Server خود كاربران مي‌توانند اين پايگاه‌ها را درست كنند، ولي در اوراكل اين امكان وجود ندارد)، به صورت پيش‌فرض ساخته مي‌شوند.

در SQL Server براي اين‌كه بتوانيم اطلاعات خود را به صورت فيزيكي غيرمتمركز (Distribute) نگه‌داريم، هر ديتابيس مي‌تواند از چندين Filegroup پشتيباني نمايد. با اين كار مي‌توان به راحتي از اطلاعات كپي پشتيبان گرفت. همان‌طور كه در شكل 1 مشاهده مي‌كنيد، در SQL Server، ديتابيس‌ها در واقع همان كار tabalespaceها در اوراكل را دارند.

 
شکل 1
اگر به شكل 1 نگاه كنيد، مي‌بينيد كه در هر دو بانك‌ اطلاعاتي، كاتالوگ سيستم وجود دارد. هر پايگاه اطلاعاتي يا ديتابيس در اوراكل يك سيستم كاتالوگ مركزي يا ديكشنري داده ‌‌(Data Dictionary) را در قسمت SYSTEM Tablespace اجرا مي‌كند، ولي در SQL Server 2005 هر ديتابيس سيستم كاتالوگ خود را درست مي‌كند.

اين سيستم كاتالوگ اطلاعاتي همچون اشياي پايگاه داده (مانندTable ،View و Procedure)، اطلاعات كاربران و دسترسي‌هاي آن‌ها، Constraintsها، User-Defined data type و Snapshot definition را شامل مي‌شود.

البته اطلاعاتي همچون اسامي ديتابيس‌ها، اطلاعات سرور، مديريت پيغام‌ها و Stored Proceduresهاي سيستم درMaster Database وجود دارند.

نكته اينجاست كه SQL Server 2005 ،objectهاي سيستم در اين Master Database قرار نمي‌گيرند. اين آبجكت‌ها در ديتابيس‌هاي مخفي سيستم به نام resource database يا پايگاه اطلاعات منابع سيستم ذخيره مي‌گردند.

در واقع‌ سيستم كاتالوگ‌ها در SQL Server 2005 منابعي هستند براي استخراج اطلاعات ديتابيس‌ها و اين كاتالوگ‌ها را كاربران نيز مي‌توانند مشاهده كنند.

براي حصول اطمينان از كارايي و سلامت سرور در DMV، SQL Server 2005 يا Dynamic Management Views استفاده مي‌شوند؛ درست شبيه اوراكل كه از viewهاي $ V براي كنترل كارايي استفاده مي كند.

اجزاي تنظيم كننده شبكه

 
شکل 2
شكل 2 ساختار اجزاي تنظيم كننده شبكه در اين بانك‌هاي اطلاعاتي را نشان مي‌دهد. در اوراكل كامپوننتي به نام Oracle Net Service وجود دارد كه عامل ارتباطي سرور اوراكل با كلاينت‌هاي آن است.

اوراكل اين كار را با استفاده از پروتوكل TNS يا Transparent Network Substare انجام مي‌دهد، اما در SQL Server اين كار توسط پروتكل‌هاي شبكه موجود در كلاينت و سرور انجام مي‌گيرد.

البته در SQL Server 2005 فناوري جديدي به نام SNAC يا SQL Server Native Client، معرفي گرديده كه در واقع تركيبي است از ODBC و OLEDB در يك تابع كتابخانه‌اي. SNAC توانايي پشتيباني TDS يا Tabular Data Stream و Net Lib را براي پروتكل‌هاي گوناگون در SQL Server دارد.

ساختار فيزيكي و منظقي ذخيره اطلاعات

شكل 3 نگاهي مقايسه‌اي دارد به دو بانك اطلاعاتي اوراكل و SQL Server از لحاظ ساختار اطلاعاتي. همان طور كه در اين شكل مي‌بينيد، در SQL Server اندازه صفحات (8kb، (page size است كه واحد پايه ورودي/ خروجي به شمار مي‌رود.

هر صفحه فقط متعلق به يك آبجكت، مانند data ،index ،GAM و.. است. SQL Server براي افزايش كارايي اين صفحات آن‌ها را در دسته‌هاي هشت‌تايي قرار مي‌دهد كه به آن Extent مي‌گوييم. اين Extentها مي‌توانند به چند آبجكت متفاوت تعلق داشته باشند.

 
شکل 3
هر Extent كه تمام صفحاتش آبجكت‌هاي مانند هم داشته باشد Uniform ناميده مي‌شود و به Extentهايي كه آبجكت‌هاي يكساني ندارند، Mixed مي‌گويند.

SQL Server در ديتابيس‌هاي خود از Filegroupها استفاده مي‌كند تا كنترل فضاهاي فيزيكي جداول و ايندكس‌ها را در اختيار كامل داشته باشد. اين Filegroupها از يك يا چند فايل تشكيل شده‌اند و اطلاعات موجود در آن مي‌تواند در تمام فايل‌هاي آن Filegroup ذخيره شود.

با استفاده از Filegroup مي‌توان جداول بزرگ را در چند فايل ذخيره نمود و از اين طريق كارايي ورودي/ خروجي را بالا برد، مي‌توان عمليات كپي پشتيبان و بازآوري جداول را انجام داد و داده‌هايي مانند تصويرو فايل‌هاي متني بزرگ را در فايل‌هاي جدا ذخيره نمود.

برخلاف SQL Server، بانك اطلاعات اوراكل از Tablespaceهايي تشكيل شده است كه خود از Data File تشكيل شده‌اند. اين Data Fileها در واحدهايي به نام Block طبقه‌بندي مي‌شوند كه مدير بانك اطلاعاتي (DBA) مي‌تواند اندازه آن را وقتي كه در حال ساخت ديتابيس است تعيين كند. برخلاف SQL Server، در اوراكل وقتي يك شيء در Tablespace توليد مي‌شود، كاربر مي‌تواند فضاي آن را مشخص كند.

مقايسه SQL Server 2005 و Oracle 10g

اگر چه SQL Server 2000 يكي از قوي‌ترين بانك‌هاي اطلاعاتي است و خيلي از شركت‌ها و سازمان‌هاي بزرگ امروزه از آن به عنوان پايگاه داده‌هاي خود استفاده مي‌كنند، چند محدوديت هم دارد. يكي از محدوديت‌هاي SQL Server 2000 در طريقه قفل كردن يا Locking Strategy است.

در MS SQL 2000 مانند اوراكل مي‌توان دسترسي همزمان به پايگاه را محدود كرد و آن را به اصطلاح قفل نمود. ولي در MS SQL 2000 امكان Deadlock خيلي زياد است؛ مخصوصاً در CTF يا Correct Transactional Flows.

از طرف ديگر، اعمال تغيير در بانك‌هاي اطلاعاتي به صورت آنلاين يكي ديگر از محدوديت‌هاي آن است. البته با استفاده از DBCC INDEXDEFRAG در SQL Server 2000 مي‌توان قسمتي از ايندكس‌ها را به صورت آنلاين تغيير داد، ولي نه به صورت كامل.

(البته اين مشكل در SQL Server 2005 تا حدي حل شده است). در اوراكل از نسخه 1/8 تا به حال، امكان تغيير و جابه‌جايي جداول و ايندكس‌ها وجود دارد؛ بدون اين‌كه به exclusive lock نياز داشته باشيم. البته ناگفته نماند كه نسخه‌هاي 2/9 اوراكل در اين قسمت داراي اشكالات و باگ‌هايي نيز بوده‌اند، ولي اين اشكالات در نسخه آخر اواركل برطرف شده است.

در ادامه، ساختار و امكانات هر دو بانك‌اطلاعاتي Oracle 10g و SQL Server 2005 با يكديگر مقايسه مي‌گردند.

مديريت بانك اطلاعاتي

SQL Server 2005 مانند ديگر محصولات مايكروسافت قسمت مديريت ساده و شكيلي دارد كه مي‌توان با آن به راحتي كار كرد و با استفاده از خط دستور در SQLCMD، ابزار مديريتي DAC يا‌ Dedicated Administrator Connection را اجرا نمود. همچنين مي‌توان از قابليت Policyها براي كاربران و صاحبان بانك‌هاي اطلاعاتي استفاده نمود.

گذشته از پيچيدگي‌هاي موجود در اوراكل، قابليت‌هاي مديريتي آن بسيار بيشتر از MS SQL است. اوراكل سيستم رمزدهي بسيار قدرتمندي دارد كه از نسخه 7 به بعد همراه آن بوده است. در اوراكل مي‌توان امكان ارتباط با User و سپس با Schema خاص را به راحتي امكانپذير نمود.

مثلاً فرض كنيد كه با كاربر Sys2 به اوراكل متصل هستيد و مي‌خواهيد روي DB2 Schema كار كنيد. كافي است دستور زير را وارد كنيد:
;ALTER SESSION SET CURRENT_SCHEMA=DB2

سيستم LOCKING

يكي از قابليت‌هايي كه در نسخه جديد SQL Server به آن اضافه شده است، قابليت SI يا Snapshot Isolation است كه در حقيقت قابليت نسخه‌برداري از رديف (row)هاي جداول است. با اين كار در موقع بروزآوري جداول، امكان انتخاب همزمان اطلاعات آن جدول نيز وجود دارد.

در اوراكل چيزي شبيه اين مكانيزم وجود دارد كه به آن Oracle Flashback Query مي‌گويند. البته بين اين دو مكانيزم تفاوت‌هايي نيز وجود دارد: اوراكل از Undo Segment براي برگشت به ركورد قبلي استفاده مي‌كند. در صورتي كه SQL Server 2005 از TempDB استفاده مي‌كند.

MetaData در اوراكل مانند جداول مديريت مي‌گردد. در نتيجه در زمان اجراي درخواست‌ها چند DDL يا Data Definition language مي‌توانند به صورت همزمان به فعاليت مشغول باشند، ولي در SQL Server 2005، فعاليت DLLها مستقيماً روي جداول انجام مي‌پذيرد.

در اوراكل عمليات Locking در DB Block انجام مي‌پذيرد، ولي در SQL Server اين كار در هر رديف جدول انجام مي‌شود. البته مايكروسافت ادعا مي‌كند كه اين كار باعث افزايش سرعت و كارايي جداول مي‌گردد، ولي وقتي سرعت و كارايي آن را با اواركل مقايسه مي‌كنيم، مي‌بينيم كه هر دو از كارايي يكساني برخوردارند.

تغيير ساختاري آنلاين

همان‌طور كه قبلاً بحث شد، قبل از نسخه جديد SQL Server 2005 تنها از طريق DBCC Indexdefrag مي‌توانستيم مثلاً ايندكس را عوض كنيم (البته بايد ازExclusive lock استفاده مي‌كرديم)، ولي اكنون اين مشكل حل شده است و مي‌توان همزمان با بازسازي چند ‌DDL را نيز اجرا نمود.

در اوراكل مي‌توان حتي تمام ساختار جداول و ايندكس‌ها را بدون Exclusive lock تغييرداد. البته براي اتمام عمليات بايد از Momentary lock استفاده شود.

Partitioning و Clustering

نسخه جديد SQL Server به تازگي قابليت جداسازي فيزيكي جداول و ايندكس‌ها را پيدا كرده است. در اوراكل قابليت Partitioning به چند صورت امكانپذير است و DBA مي‌تواند بر اساس range ،list و hash اين كار را انجام دهد.

حتي مي‌توان اين كار را در دو رده انجام داد. مثلاً مي‌توانيم جدولي را به دو قسمت براساس list جداسازي كنيم و هر كدام از قسمت‌ها را بر اساس hash دوباره جداسازي نماييم. اين قابليت اوراكل را مي‌توان در جداولي كه ركوردهاي زيادي دارند، به كار برد. البته اين قابليت در SQL Server 2005 وجود ندارد، ولي مي‌توان آن را شبيه‌سازي نمود.

SQL Server 2005 در Partitioning از قابليتي مانند اوراكل برخوردار نيست. با اين حال راه‌حل ساده‌تري را ارائه مي‌كند. در SQL Server 2005 مي‌توان با استفاده از UDF يا User Defined function اين كار را انجام داد.

در مورد Clustering ،SQL Server 2005 پشتيباني خوبي دارد، ولي طراحي و مديريت اين كار سخت است و كارايي زيادي نيز ندارد. از طرف ديگر اواركل RAC/GRID را در نسخه 10g ارائه كرده است كه مي‌توان از آن به عنوان امتيازي مسلم در مقابل SQL Server 2005 نام برد. اوراكل همچنين از سيستمي جديد به نام ASM يا Automatic Storage Management استفاده مي‌كند كه در Clustering مورد استفاده قرار مي‌گيرد.

ايندكس و Tuning

ساختار مرتب‌سازي و ايندكس در SQL Server 2005 هنوز بر اساس BTree است و در مقابل indexing قدرتمند در اوراكل ساختاري نسبتاً دارد. اوراكل هم از BTree استفاده مي‌كند، ولي از سيستم indexing به نام Bitmap نيز هم استفاده مي‌كند كه در جست‌وجوي ستون‌هايي با انتخاب كم بسيار خوب عمل مي‌كند.

اضافه بر اين اوراكل از Oracle key based cluster نيز در ايندكس استفاده مي‌كند كه كارايي بانك‌اطلاعاتي در انتخاب ركوردهايي انتخابي از چند جدول مرتبط با هم با ستون‌هاي مشابه را بالا مي‌برد.

در اواكل و SQL Server هر دو مي‌توان براي Functionهايي كه روي ستون‌هاي جدول است، ايندكس درست كرد و در هر دوي آن‌ها مي‌توان MV يا Materialized view تهيه نمود. MVها در حقيقت viewهاي آماده هستند كه مي‌توان از آن به جاي متصل كردن چند جدول استفاده كرد.

SQL Server 2005 در مقايسه با اوراكل 10g، در aggregation و functionها محدوديت‌هايي دارد. مثلاً در index view نمي‌توانيم از Distinct ،NOT و ... استفاده كنيم و امكان مثلاً Sum كردن نيست.

كپي پشتيبان و بازيابي اطلاعات

همان‌طور كه قبلاً نيز اشاره شد در نسخه‌هاي قبلي SQL Server نمي‌توانستيم به صورت آنلا‌ين از اطلاعاتمان كپي بگيريم، ولي در نسخه جديد SQL Server 2005 مديران بانك‌هاي اطلاعاتي مي‌توانند به راحتي عمليات كپي و بازيابي اطلاعات را به صورت آنلاين انجام دهند.

در حالي كه سرور در حال كار كردن است. اوراكل نيز ساختاري شبيه اين را با استفاده از Tablespaceها انجام مي‌دهد. البته در Tablespaceهاي اوراكل نمي‌توان اطلاعات قبلي را در Tablespace بازيابي نمود و از آن‌جايي كه در هر Tablespace يك Metadata وجود دارد، اين Tablespaceها نمي‌توانند كامل باشند.

البته اوراكل داراي ابزار بازيابي اطلاعات كاملي است و مي‌تواند با كمك گرفتن از Redo logها اين كار را آسان كند.
اوراكل با استفاده از logical dump‌هايي كه مي‌سازد، مي‌تواند مشكلي كه باعث نياز به بازيابي مي‌شود را شناسايي كند. البته SQL Server هم ابزارهايي مانند DBCC PAGE و DBCC LOG دارد كه مانند ابزارهاي اوراكل عمل مي‌كند.

انتقال و‌ ورود اطلاعات (Export and Import)

يكي از امكانات جديد Oracle 10 g براي انتقال يا صادر كردن اطلاعات به data pump معروف است. data pump ساختاري binary دارد. اوراكل اين كار را توسط دو گزينه كه براي صادر و دو گزينه براي وارد كردن اطلاعات دارد، انجام مي دهد. اين دو گزينه exp/data و imp/data هستند.

اضافه بر اين، در اوراكل ابزار sqlldr نيز وجود دارد كه اختصاصاً براي import كردن اطلاعات متني به كار مي‌رود. از طرف ديگر SQL Server2005 داراي دو گزينه براي export و import است؛ به نام‌هاي bcp و Bcp .DTS مي‌تواند اطلاعات را (به صورت متني) import يا export كند و حتي مي‌تواند اطلاعات را به فرمتي ذخيره كند كه بانك‌هاي اطلاعاتي ديگر نيز بتوانند از آن استفاده كنند.

DTS نيز يكي از پر سرعت‌ترين ابزارهاي انتقال اطلاعات در SQL Server است كه در مقايسه با اوراكل بسيار سريع‌تر و كار با آن آسان‌تر مي‌باشد. اوراكل نيز در نسخه جديد خود از ابزار ‌WisdomForce FastReader استفاده مي‌كند كه مي‌تواند با سرعت زياد كار export و import را انجام دهد و اطلاعات را با فرمت متني آماده سازد. از اين ابزار مي‌توان براي انتقال اطلاعات بين اوراكل و بانك‌هاي اطلاعاتي ديگر مانند MS SQL ،2DB ،Sybase استفاده نمود.

امكانات موجود براي برنامه‌نويس‌ها
يكي از امكاناتي كه اوراكل در اختيار برنامه‌نويسان قرار مي‌دهد، امكان استفاده از Exception Handling است كه توسط PL/SQL قابل دسترسي است. در SQL Server 2005 نيز اين امكان توسط Transcat-SQL مهيا شده است.

در مبحث Queuing ،SQL Server 2005 ابزاري به نام Server Broker دارد كه مي‌تواند امكان استفاده از Queing را براي برنامه‌نويسان فراهم سازد، اما در اوراكل ابزاري قوي به نام Oracle Advanced Queuing وجود دارد كه كار Queing را به صورت كامل انجام مي‌دهد.

SQL Server 2005 مي‌تواند كمك بيشتري به برنامه‌نويسان بكند؛ زيرا از NET. استفاده مي‌كند، ولي بر خلاف آن، هسته اوراكل از جاوا درست شده است و مستقيماً فقط مي‌تواند توسط PL/SQL اجرا شود. در نتيجه در SQL Server 2005 مي‌توانيم به صورت مستقل از دستورات NET. استفاده كنيم.

از طرف ديگر از آنجا كه جاوا هسته اوراكل را تشكيل مي‌دهد، نگهداري آبجكت‌هاي جاواي درون اوراكل درست مانند نگهداري يك سرور جاوا مي‌باشد، ولي SQL Server 2005 تنها در برخي قسمت‌ها مانند اشكال‌يابي از NET trigger. استفاده مي‌كند و حجم سنگيني ندارد.

امكانات ويژه SQL Server 2005

- ‌SQL Server 2005 :Replication ابزار Replication بسيار قدرتمندي دارد كه مي‌تواند از اوراكل به SQL Server يا بلعكس Replication انجام دهد.

- Notification: در SQL Server 2005 سرويس Notification يكي از سرويس‌هايي است كه مي‌توان با آن در ‌Alertهايي مانند Stock Market استفاده نمود.

- Reporting Services: يكي از امتيازات SQL Server 2005 در مقايسه با اوراكل، داشتن سرويس گزارش‌هاي داخلي است كه با استفاده از آن مي‌توان انواع گزارش‌ها را استخراج نمود. البته اوراكل هم داراي Oracle IAS است كه كار گزارش‌گيري را حتي قوي‌تر از SQL Server انجام مي‌دهد، ولي مانند SQL Server 2005 در داخل بانك اطلاعاتي نيست و به صورت خارجي عمل مي‌كند. همچنين خريد آن نيز هزينه زيادي خواهد داشت.

- Identity: در اوراكل نمي‌توان به صورت خودكار كليد اصلي يا Primary key را تعريف كرد. در صورتي در SQL Server2005 اين امكان وجود دارد. البته اوراكل داراي Sequence است، ولي نگهداري اين Sequenceها توسط مدير سيستم كار آساني نيست.

امكانات ويژه ‌Oracle 10g

- Auditing: در اوراكل اين كار با استفاده از پارامتر جديد audit_trail=db_extended, init.ora انجام مي‌پذيرد كه مي‌توان از تمامي جست‌وجوها به همراه مقادير ورودي هر يك از آن‌ها اطلاعات ذخيره كرد. اين كار در SQL Server2005 تنها با استفاده از Trace امكانپذير است. آن هم نمي‌تواند مقادير Bind شده اطلاعات را نشان دهد و استفاده از آن نيز مي‌تواند كارايي سرور را تا حد زيادي پايين بياورد.

- Logminer: در‌ اوراكل ابزاري به نام Logminer وجود دارد كه مي‌تواند تاريخچه تمامي DML يا DDLهاي كل پايگاه اطلاعاتي را به ما بدهد. SQL Server2005 اين ابزار را ندارد، ولي مي‌توان از Lumigent Log Explorer براي مشاهده برخي از اين تاريخچه استفاده كرد.

- Flashback Query: اين امكان در نسخه جديد Oracle 10g عرضه گرديد و با كمك آن مي‌توان اطلاعات از دست رفته را بازيابي كرد.

- Rollback Statistics: در اوراكل اگر عملياتي سنگين در وسط كار انجام نپذيرد، مي‌توان آن را Rollback كرد. Rollback statistics مي تواند به شما بگويد چه زماني طول خواهد كشيد كه Rollback انجام شود و عمليات پايان پذيرد. كافي است جست‌وجوي زير را به كار ببريد:
V$FAST_START_TRANSACTIONS
اين قابليت در SQL Server2005 وجود ندارد.

- AWR يا Automatic Workload Repository تصور كنيد كه بانك اطلاعاتي شما بسيار حجيم است، ترافيك زيادي دارد و جوابگويي آن به كلا‌ينت‌ها كُند شده است. با استفاده از AWR در Oracle 10g مي‌توانيم مشكل را بررسي كنيم و تشخيص دهيم چه مشكلي در سيستم وجود دارد. اوراكل اين كار را با استفاده از درست كردن Viewهاي زير انجام مي‌دهد.
v$sysmetric_history for v$sysmetric
v$active_session_history for v$active_session
v$waitclassmetric_history for v$waitclassmetric
v$session_wait_history for v$session_wait
v$servicemetric_history for v$servicemetric

- پشتيباني از OO يا Oracle :Object Oriented قابليت‌هاي شيءگرا (object oriented) دارد. براي همين، اين بانك اطلاعاتي را مي‌توان بانك اطلاعاتي رابطه‌اي شيءگرا نيز ناميد. با استفاده از اين قابليت، برنامه‌نويسان مي‌توانند Class و Objectهاي برنامه شيء‌‌گراي خود را مستقيماً به جداول بانك اطلاعاتي Map كنند.

ارسال شده در مورخه : چهارشنبه بیست و دوم خرداد 1387 ساعت 8:22 توسط محمد جهانشاهی |

روشهاي بالا بردن Performance در Query ها

1-تا جائيكه امكان دارد سعي كنيد از عبارتWHERE در دستورات SELECT خود استفاده كنيد.

2- از Inner Join استفاده نكنيد.

3-تا حد امكان از بکارگيري Cursor اجتناب كنيد.

4-در مورد اينكه آيا SELECT شما واقعا به DISTINCT نياز دارد يا نه توجه كنيد . در جايي كه نياز نيست از آن به هيچ عنوان استفاده نكنيد.

5-در عبارت SELECT خود ، فقط اسامي فيلدهايي را ذكر كنيد كه استفاده مي كنيد. لذا از عبارت SELECT * تا حد امكان خودداري كنيد.

6-دستور SET ROWCOUNT همان كاري را انجام مي دهد كه گزينه TOP در دستور SELECT .اما گزينه TOP به مراتب كاراتر است.

7-تا حد امكان از EXISTS و IN به جاي EXISTS NOT و NOT IN استفاده كنيد زيرا Performance سيستم را افزايش مي دهند.

8-از Constraint ها استفاده كنيد.مانند گزينه هاي Constraint و يا Default ها.

9-از چند Constraint براي انجام يك كنترل استفاده نكنيد. مثلا اگر از محدوديتهاي Primary Key و Foreign Key براي كنترل جامعيت ارجاعيRefrentional Integrity)) استفاده مي كنيد، كنترل اين مطلب در Trigger نيز تنها يك بار اضافي به سيستم تحميل مي كند.

10-زماني كه براي انجام يك درخواست هم مي توان از Join استفاده كرد هم از SubQuery ، استفاده از Join توصيه مي شود چون سريعتر است.

11-اگر در عبارت خود هم مي توانيد از IN استفاده كنيد هم از EXISTS ، ترجيحا از EXISTS استفاده كنيد ؤ چون كارا تر و سريتر عمل مي كند.

12-وقتي هم امكان اينرا داريد كه از IN استفاده كنيد ، هم از BETWEEN ، از BETWEEN استفاده كنيد.

13-تا جائيكه امكان دارد ، سعي كنيد از SUBSTRING( ) در عبارت WHERE خود استفاده نكنيد.زيرا باعث مي شود كه جدول Scan شود به جاي اينكه از Index استفاده كند.

14-تا جائيكه امكان دارد از توابع تبديلي در شرط WHERE استفاده نكنيد.

15-با اينكه استفاده از View ها آسان است ، اما كارايي سيستم را كم مي كنند.به جاي استفاده از View از Stored Procedureها استفاده كنيد.

16-از View هاي تودر تو استفاده نكنيد.(در صورتيكه به توصيه 16 عمل نمي كنيد !!! )

17-تا زماني كه واقعا نيازي نداريد از DISTINCT يا ORDER BY استفاده نكنيد.

18-اگر در برنامه تان از جستجوي متني wildCardي روي CHAR يا VarCHARزياد استفاده مي شود (Like % ) ، از امكانات Full Text Search استفاده كنيد.

19-شما مي توانيد از GROUP BY با / بدون توابع Aggregation استفاده كنيد.اما اگر مي خواهيد بالاترين كارايي را داشته باشيد ، از GROUP BY بدون توابع Aggregation استفاده نكنيد.

20- تا آنجا كه امكان دارد از Derived Table ها به جاي Temporary Table ها استفاده كنيد.

21-اگر در شرط WHERE از توابعي روي فيلد ها ، استفاده شود كه Non-Sargable باشند ،باعث پايين آمدن كارايي مي شود.اگر بتوانيد به شكلي شرط WHERE را طوري بازنگري كنيد كه فيلد و تابع جدا گانه باشند،در اين صورت Query مي تواند از Index موجود استفاده كرده و كارايي را افزايش دهيد.

I)


کد:

SELECT ID,First_name,LastNameFrom MembersWHERE DATEDIFF(yy,DateOfBirth,GetDate())>21


II)



کد:
SELECT ID,First_Name,Last-NameFrom MembersWHERE DateofBirth


22-ايندكس بايد روي تمام فيلدهايي كه مرتب در WHERE ، ORDER BY ، GROUP BY ، TOP و DISTINCT استفاده مي شوند ، زده شود.

23-طبق قانون Thumb ،تمام جداول حداقل يك Clustered Index داشته باشند.عموما ، نه هميشه ، Clustered Index بايد روي فيلدهايي زده شوند كه مقاديرش به صورت يكنواخت افزايش پيدا مي كنند ، مانند فيلدهاي Identity و يا فيلدهايي كه مقاديرشان افزايش مي يابند و Unique هستند.در بسياري از شرايط Primary Key بهترين انتخاب براي Clustered Index است.

24-روي جداول OLTP ، ايندكس نزنيد.چون هر ايندكس زمان اجراي دستورات DML را افزايش مي دهد.

25-دقت كنيد كه به طور تصادفي ، ايندكس مشابه روي جداول نزنيد . اين اتفاق ممكن است به سادگي اتفاق بيافتد.براي مثال ، شما يك Unique يا Primary Key روي يك فيلد تعريف مي كنيد، در اينصورت اتوماتيك ايندكس هايي روي اين فيلد زده مي شود .اما اگر شما به اين مسئله توجه نكنيد و جداگانه روي اين فيلد اينكدس بزنيد، دچار مشكل ايندكس هاي تكراري مي شويد.

26-عموما در موارد زير ايندكس زده نمي شود:
• اگر Query Optimizer از ايندكس استفاده نكند.مثلا اگر جدول كوچك باشد، اكثرا از ايندكس استفاده نمي شود.
• فيلد يا فيلدهايي كه قرار است در ايندكس باشند ،عريض باشند.
• اگر فيلدها از نوع Text يا Ntext يا Image باشند.
• اگر از جدول به ندرت استفاده شود.

27-گاهي اوقات ايده خوبي است كه يك ايندكس مركب را به چندين ايندكس تك فيلدي تجزيه كنيد.چون عملا فيلد اول توسط Query Optimizer استفاده مي شود.البته اين بدين معنا نيست كه هميشه Single Index از Composite Index ها بهتر عمل مي كنند.فقط با تست كردن مي توانيد بفهميد كه كداميك براي جدول شما كارايي بيشتري دارد.

28-اگر دو يا چند جدول داريد كه مرتبا آنها را به يكديگر Join مي كنيد ، بهتر است روي فيلدهايي كه در Join شركت دارند ايندكس بزنيد.

29-تا جائيكه امكان دارد ايندكس Unique ايجاد كنيد. زيرا SQL Server روي ايندكسهاي Unique سريعتر از ايندسهاي غير Unique مي تواند جستجو كند.

30-از فيلدهاي Float و Real براي Primary Key استفاده نكنيد.زيرا يك OverHead غير ضروري به سيستم تحميل مي كند كه كارايي سيستم را مي كاهد.

31-هيچگاه روي فيلدهايي كه روي آنها Non-Clustered Index زده شده است ، Clustered Index نزنيد.

32-از Clustered Index زدن روي فيلدهايي كه مرتب Update مي شود خودداري كنيد.زيرا هروقت فيلدي كه در يك Clustered Index استفاده شده تغيير مي كند، تمام Non-Clustered Index ها هم بايد Update شوند.

33- فيلد يا فيلدهايي را براي Clustered Index انتخاب مي كنيد كه شامل اطلاعاتي هست كه در Query ها بيشتر Search مي شوند.

Primary Key -34 ي كه شما روي جداولتان استفاده مي كنيد ، حتما نبايد هميشه Clustered Index باشند. زماني Primary Key را Clustered Index كنيد كه مرتبا ٌ Range Query روي Primary Key انجام مي دهيد يا مي خواهيد خروجيتان بر اساس Primary Key مرتب شود.

35-تا جاييكه امكان دارد از ايندكس زدن روي فيلد GUID خودداري كنيد.

36-دراول تمام Stored Procedure هاي خود از دستور SET NOCOUNT ON استفاده كنيد.

37-اگر Stored Procedure شما به صورت ديناميك باشد و يا شرايط WHERE آن در هر بار اجرا تغيير مي كند، از With Recompile در Stored Procedure خود استفاده كنيد.

38-اگر مي خواهيد اطلاعات را به صورت رشته اي در جدول ذخيره كنيد ، و طول آن كمتر از 8000 است ، از نوع Char يا VarChar به جاي Text استفاده كنيد.

39-اگر در برنامه تان از Temporary Table زياد استفاده مي كنيد، به جاي آن سعي كنيد از متغيرهايي از جنس Table استفاده كنيد.

DateTime -40 را هيچگاه به عنوان Primary Key در نظر نگيريد.

41-اگر اين انتخاب را داريد كه براي ملزم كردن Rules و Default ها از Trigger يا CHECK Constarin استفاده كنيد.ترجيحا از CHECK Constarin استفاده كنيد.

42- براي كاهش Overhead ، كمترين كد ممكن را در Trigger بنويسيد.

43- تا جاييكه ممكن است از Roll Back كردن تا حد امكان در Trigger خودداري كنيد.سعي كنيد قبل از اينكه ‏Trigger اجرا شود ، مشكل را برطرف كنيد.

44- براي ايجـاد جـداول موقت ( در صورتيكه چاره اي جز استفـاده از آنها نداريد ) ، از SELECT INTO استفاده نكنيد.

ارسال شده در مورخه : چهارشنبه بیست و دوم خرداد 1387 ساعت 8:20 توسط محمد جهانشاهی |

انتقال اطلاعات با Replication در SQL Server

عرفي Replication راه حلي براي انتقال اطلاعات از يك بانك اطلاعاتي SQL sever به يك بانك اطلاعاتي ديگر از همان نوع و البته مستقر در يك محل و كامپيو تر ديگر است . اين فرآيند توسط ايجاد يك كپي از اطلاعات موجود در مبدا و انتقال به مقصد صورت مي گيرد . در اين ارتباط اطلاعاتي اصطلاحا به كامپيو تر وبانك اطلاعاتي مبدا ، ناشر (publisher) و به كامپيو تر وبانك اطلاعاتي مقصد ، مشترك يا متعهد (subscriber) مي گويند البته اين نوع رابطه ، با وجود تنها يك ناشر اما يك يا چند مشترك امكان پذير است . بدين معني كه اطلاعات يك بانك اطلاعاتي در مبدا قابل انتقال به چند مقصد مختلف است . از نسخه 7 به بعد SQL severامكان تغيير اطلاعات در مقصد و انتقال آن به مبدا نيز وجود دارد . با اين وصف ، اين رابطه داده اي بين ناشر و مشترك ممكن است گاهي اوقات بر عكس شود و جاي مبدا و مقصد در يك مقطع زماني عوض شود . بدين ترتيب يك كامپيوتر مشترك يا مقصد مي تواند گاهي اوقات نقش ناشر يا مبدا در همان رابطه بازي كند . اين قابليت جديدMulti site update مي گويند . در SQL sever، سه نوع انتقال اطلاعات از طريق Replication وجود دارد. هر كدام از اين سه راه ، سناريو ي خاصي براي انتقال اطلاعات از مبدا به مقصد و يا برعكس را مديريت مي كنند كه در ادامه به بررسي آن ها مي پردازيم . 1- انتقال اطلاعات به روش ادغام (Merge) اينوع انتقال اطلاعات كه از قابليت Multi site هم پشتيباني مي كند ، زماني مورد استفاده قرار مي گيرد كه استقلال داخلي هر بانك اطلاعاتي طرف يك رابطه ، به رسميت شناخته مي شود . بدين معني كه در يك رابطه انتقال اطلاعات ، هر كامپيو تر ضمن حف ظ ساختار بانك اطلاعاتي خود ، هم مي تواند نقش ناشر را داشته باشد و نقش مشترك را ايفا نمايد . در اين حالت هر تغييري در جداول مشترك هر طرف ديگر اعمال مي شود . نكته مهمي كه در اينجا مطرح است اين است كه چطور طرفين اين ارتباط متقابل بايد با هم هماهنگ باشند و اولويت يكديگر را به رسميت بشناسند . به عنوان مثال فرض كنيد در يك زمان واحد ، هر دو طرف بخواهند اطلاعاتي را در مورد يك جدول بانك اطلاعاتي به يكديگر ارسال كنند . (يعني بروز حالت تداخل ) اين مشكل با استفاده از روش خاصي كه هر نوع Replication مخصوص خودش دارد قابل حل است . به طور كلي در حالت ادغام ، يك پايگاه داده حايل ميان ناشر و مشترك به عنوان توزيع گر ( Distributor) ساخته مي شود . اين پايگاه داده به نام Distributor در ليست پايگاه هاي داده اي ناشر قرار مي گيرد و وظيفه ايجاد همزماني (synchronization ) بين ناشر و مشتركين را ايفا مي كند . پايگاه داده توزيع گر هم مي تواند در سمت ناشر و هم در يك كامپيوتر مياني ديگر (غير از كامپيو تر هاي سمت مشترك ) قرار داشته باشد . اين پايگاه داده ضمن ايجاد همزماني در ردو بدل اطلاعات بين ناشر و مشترك ، اين امكان را نيز فراهم مي سازد تا مدير سيستم بتواند اولويت و در واقع ارجحيت جهت انتقال اطلاعات در زمينه بروز تداخل را مشخص كند . اين اولويت priority در زمان تعريف طرف هاي ناشر و مشترك يك Replication از نوع ادغام توسط مدير سيستم تنظيم مي شود . 2- تصوير برداري از اطلاعات (Snapshot) در اين روش ابتدا يك تصوير كامل از آنچه كه بايد از سمت ناشر به سمت مشترك برود تهيه مي شود . اين تصوير هم شامل خود ساختار آنچه كه منتقل مي شود ( مثلا ساختار يك جدول ) و هم شامل اطلاعات داخل آن است . در ابتداي كار، تصويرمذكور عينا به مشترك فرستاده مي شود . روند و توالي ارسال اين تغييرات هم همانند حالت قبل (ادغام ) طي يك فاصله زماني مشخص مثلا ساعتي يك بار كه توسط مدير سيستم قابل تنظيم است ، انجام مي گيرد . يكي از مزاياي اين روش نسبت به حالت ادغام ، اين است كه زمان كمتري از وقت مدير سيستم را جهت پيكر بندي و تنظيم عمل انتشار صرف مي كند و به دليل اينكه در ابتداي عمل انتشار، خود ساختار نيز عينا به مشترك منتقل مي شود ، از قابليت اطمينان بيشتري برخوردار است . به طور كلي كاربرد اين نوع انتقال اطلاعات ، زماني است كه مدير سيستم قصد ايجاد يك ارتباط ساده و يكطرفه ولي مطمئن دارد 3- انتقال بر اساس فرآيند (Transactional) اين روش يكي از بهترين و قابل كنترل ترين روش هاي انتقال است. در اين روش هر تغييري كه در جداول ناشر صورت مي گيرد ، به صورت يك دستور SQL درآمده كه تحت يك فرآيند واحد هم در سمت كليه مشتركين اجرا مي شود . در اين صورت اگر به طور مثال يكي از مشتركين به دليلي با اشكال مواجه شده و تغيير مورد نظر در آن انجام نشود ، اين تغيير نه در خود ناشر و نه در هيچ كدام از مشتركين ديگر نيز انجام نخواهد شد ، بدين معني كه يا يك تغيير در اطلاعات براي تمام كامپيوتر ها اعم از ناشر و كليه مشتركين انجام مي شود و يا اين كه براي هيچ كدام انجام نخواهد شد در اين حالت هم يك پايگاه داده به واسطه به نام Distribution نقش دريافت وارسال فرآيند را به طرف مشترك ايفا مي كند . در واقع روش فرآيند ، در مقايسه با دو روش قبل از حالت به هنگام (online) بودن بيشتري برخورداراست . يعني اين كه هر فرآيند و هر دستور در همان لحظه كه مي خواهد در ناشر اجرا شود ، به واسط فرستاده شده و سپس در يك زمان واحد در كليه مشتركين نيز انجام مي شود و در واقع زمان تغيير اطلاعات در ناشر و در مشتركين تقريبا يكسان است . همچنين در اين روش تداخلي هم پيش نمي آيد . چون هر تغييري ابتدا بايد به واسط فرستاده شود و از آن جا به جاهاي ديگر ارسال شود و واسط هم آن ها را در يك صف اولويت (priority queue ) قرار داده و به ترتيب انجام مي دهد . نتيجه اين نوع انتقال اطلاعات ، داشتن چند پايگاه داده كاملا يكسان و به هنگام در مكان هاي مختلف است كه همگي از يك ناشر ، اطلاعات مورد نظر را دريافت مي كنند . تعريف ناشر و مشتركين براي تعيين يك SQLserverوان ناشر ، كافي است يك رابطه Replication براي آن تعريف كرده و پس از انجام تنظيمات مربوطه و طي يك مراحل خاص هر يك از سه نوع انتقال اطلاعات ، آن كامپيوتر را به عنوان مبدا يا ناشر يك فرآيند انتقال معرفي كنيم . در همين حين و براي ايجاد پايگاه داده واسط يا همان توزيع گر (Distributor) هم مي توان وارد عمل شده و خود ناشر را به عنوان توزيع گر آن فرآيند انتقال معرفي كنيم . پس از اين كار نوبت به تعريف مشتركين مي رسد . براي تعريف يك مشترك از دو راه مي توان اقدام كرد ، كه هر يك كاربرد مخصوص به خودرادارند . در روش اول كه فرستادن اطلاعات به طرف يك مشترك است و در اصطلاح push ناميده مي شود . بدين معني كه مدير سيستم مي تواند بلا فاصله پس از تعريف يك ارتباط و ناشر آن از همان لحظه و در همان محل استقرارناشر ، مشتركين را يك به يك به اين نوع ارتباط دعوت و اضافه كند و اطلاعات را به سمت آنها بفرستد . اين ارتباط به دليل اين كه كامكلا از طرف ناشر، كنترل مي شود، از حالت به هنگام بيشتري (online) برخوردار است و اطلاعات بلا فاصله به سمت مشترك فرستاده مي شود . در روش دوم كه pull نام دارد ، تعريف مشترك از سمت خودش انجام مي شود و در واقع اين مشترك است كه اطلاعات را از ناشر طلب مي كند . اين حالت بيشتر در مواقعي است كه اطلاعات را از ناشر طلب مي كند . اين حالت بيشتر در مواقعي كاربرد دارد كه اولا تعداد مشتركين از قبل براي ناشر مشخص نيست و ثانيا بروز بودن اطلاعات در آن واحد از اهميت حياتي براي سيستم برخوردار نيست و انتقال اطلاعات درآن واحد از اهميت حياتي براي سيستم برخوردار نيست و انتقال اطلاعات مي تواند با تاخير و با درنگ زماني و در زمان دلخواه مشترك انجام شود . طرح يك مسئله فرض كنيد مي خواهيم با استفاده از مكانيسم Replication ، اطلاعات موجود در بانك اطلاعاتي Northwind را از يك پايگاه داده SQL server به نام server به يك بانك اطلاعاتي به همان نام و بر روي يك پايگاه داده ديگر مستقر در يك سرور راه دور به نام Home server منتقل كنيم . براي اين كار مي توانيم از هر كدام از سه روش انتقال اطلاعات ، استفاده نماييم . مراحل ايجاد ناشر براي اين كار ، در پنجره Enterprise Manager بر روي گزينه Publication از آيتم Replication كليك سمت راست نموده فرمان New را انتخاب مي نماييم . با آغاز ويزارد مخصوص ، كليد Next را كليك كرده و در صفحه بعد در پاسخ به اين سوال كه آيا مي خواهيد پايگاه داده توزيع گر (Distriburtor) درهمين كامپيوتر ساخته شود يا خير ، گزينه اول يعني خود كامپيوتر server را انتخاب مي كنيم و به مرحله بعد مي رويم . در پنجره بعدي از كاربر خواسته مي شود تا فولدري را جهت قرار دادن فايل هاي مربوط به عمليات انتقال مشخص كند . وجود اين فولدر براي انجام عمل Distriboutضروري است و بايد طوري انتخاب شود كه در شبكه اي كه قرار است مشتركين به آن بپيوندند قابل دسترسي باشد . پس از انتخاب اين فولدر و كليك بر روي كليد Next، در مرحله بعد نام بانك اطلاعاتي مورد نظر يعني Northwind را از داخل ليست انتخاب كرده و به مرحله اصلي يعني انتخاب نوع Replication مي رسيم كه در اين جا همان گزينه اول يعني snapshot را انتخاب مي كنيم . سپس در مرحله بعد بايد هر موجوديتي اعم از جداول و روال هايي، را كه مي خواهيم در اين عمليات انتقال وجود داشته باشند ، معرفي كنيم براي مثال جدول مشتريان (customers) را از داخل ليست جداول علامت زده و به مرحله بعد مي رويم . در مرحله بعد يك نام براي عمليات انتقال انتخاب كرده و كليد Next را مي زنيم و در نهايت با كليك بر روي عبارت Finish عمليات را پايان مي دهيم . مراحل ايجاد مشتركين 1- روش Pull ( از طريق مشترك ) براي ايجاد يك مشترك با روش pull ، به كامپيوتر مشترك مراجعه كرده و بر روي گزينه subscription كليك سمت راست كرده و فرمان New pull را انتخاب مي كنيم . سپس از داخل پنجره بعدي گزينه دوم يعني Look in the Active Directory را انتخاب مي نماييم . در مرحله بعد نام ناشر و سپس بانك اطلاعاتي مورد نظر ، نام عمل نشر كه در ناشر تعريف كرديم و سپس رمز عبور مربوط به يك كاربر معتبر در ناشر مثلا كاربر sa را وارد نماييم . در قسمت بهد هم نام بانك اطلاعاتي مقصد را كه همان Northwind است انتخاب مي ناميم . پس از طي چند مرحله ديگر كه نياز به تغييري در آن ها نيست و صرفا با كليك بر روي كليد Next ، مقادير پيش فرض را تاييد مي كنيم به مرحله انتخاب توالي زماني به روز شدن مشترك مي رسيم . در اين جا هم بايد بين سه روش مختلف يعني حالت هاي بلا درنگ ، زمان دار ، بر اساس در خواست ، يكي را انتخاب كنيم كه در اين جا همان نوع اول يعني بلادرنگ را انتخاب مي نماييم . با اين كار مراحل تعريف يك مشترك از طريق Pull پايان مي پذيرد . اما نكته مهمي كه در اين جا بايد به آن اشاره كنيم اين است كه براي فراهم ساختن امكان تعريف مشتركين از طريق Pull حتما بايد اين اجازه را قبلا و از طريق ناشر به كاربران مشترك داده باشيم . براي اين كار ، قبل از تعريف مشترك ، بايد در كامپيوترناشر ، بر روي نام عمليات انتقال ايجاد شده كليك سمت راست كرده و گزينه خصوصيات (properties)را انتخاب نماييم . سپس زبانه subscription را باز كرده و مطمئن شويم كه گزينه هاي Allow anonymous و همچنين Allow Pull در حالت تاييد شده باشند . 2- روش push (از طريق ناشر ) براي تعريف يك مشترك با استفاده از روش Push ، به كامپيو تر ناشر مراجعه كرده و بر روي نام عمليات نشر كه قبلا ايجاد كرده ايم كليك سمت راست مي كنيم . با شروع مراحل ويزارد ، نام كامپيوتر مشترك را از ليست انتخاب مي كنيم . در مراحل بعدي با معرفي بانك اطلاعاتي Northwind به عنوان مقصد به پنجره ويژه تعريف زمان به روز شدن مشترك مي رسيم كه از بين دو نوع بلادرنگ و زماندار قابل انتخاب است . كه باز هم نوع اول را انتخاب مي كنيم . در مرحله بعد هم مطمئن مي شويم كه گزينه start snapshot agent درحالت تاييد قراردارد و سپس با چند كليك بر روي كليد Nextعمليات را پايان مي دهيم . نكته بسيار مهمي كه براي تعريف مشترك از طريق روش push بايد در نظر داشته باشيم اين است كه براي ظاهر شدن نام هر مشترك درليست انتخاب كه در شكل 8 ملاحظه كرديد ، بايد قبلا اين مشترك با استفاده از عمليات Registration در كامپيوتر ناشر تعريف شده باشد . در غير اين صورت نام آن در داخل ليست مشتركين ظاهر نمي شود . عمل مذكور هم در يك محيط شبكه اي بسيار آسان است . كافي است بر روي SQL server Group در كامپيوتر ناشر كليك راست كرده و با انتخاب New Registration و وارد كردن نام مشترك اين كار را انجام دهيم .

ارسال شده در مورخه : سه شنبه سوم اردیبهشت 1387 ساعت 14:19 توسط محمد جهانشاهی |

مجموعه ای بی نظیر از آموزشهای تصویری اس کیو ال 2005 - sql server 2005

مجموعه ای از آموزشهای sql server 2005 همراه با لینک دانلود حتما در ادامه مطلب ببینید.

ارسال شده در مورخه : پنجشنبه هشتم فروردین 1387 ساعت 9:4 توسط محمد جهانشاهی | | ادامه مطلب

آموزش sql server 2005

برای دوستانی که مایل به یادگیری مجموعه آموزشهای اس کیو ال 2005 بصورت فارسی هستند مجموعه زیر را پیشنهاد می کنم :

سرفصل مطالب را در ادامه بخوانید :



ارسال شده در مورخه : پنجشنبه هشتم فروردین 1387 ساعت 8:54 توسط محمد جهانشاهی | | ادامه مطلب

فایلها و گروههای فایل filegroups

فايلهاي ايجاد شده براي بانك اطلاعاتي (Datafile و Logfile)

هر بانك اطلاعاتي در SQL Server 2005  حداقل از دو فايل ايجاد شده است : فايل داده (Data) و فايل log. فايل داده شامل داده ها و اشيايي مانند جداول ، stored procedures,Indexes و views ها است. Log شامل اطلاعاتي است كه براي بازيابي تمام عمليات صورت گرفته روي بانك مورد نياز است . فايل داده را مي توان براي اهداف مديريتي و تعيين فضاي ذخيره اطلاعات در چند filegroup گروه بندي كرد.

 

 

Database Files

بانك هاي اطلاعاتي SQL Server 2005  داراي سه نوع فايل است كه در جدول زير آمده است :

فايل

شرح

Primary

اين فايل شامل اطلاعات Startup بانك اطلاعاتي و بقيه فايلهاي بانك اطلاعاتي مي باشد.  اطلاعات اصلي و اشياء بانك اطلاعاتي مي تواند در اين فايل و فايل Secondary ذخيره گردد.هر بانك اطلاعاتي يك فايل Primary دارد. پسوند پيش فرض نام فايل براي اين فايلها mdf است

Secondary

اين فايلهاي داده اختياري هستند.با قرار دادن اين فايلها روي درايوهاي مختلف مي توان فايلهاي يك بانك را روي چندين ديسك پخش كرد. در ضمن اگر حجم بانك اطلاعاتي ما از ماكزيمم حجمي كه يك فايل در ويندوز مي تواند داشته باشد بزرگتر شود مي توان از اين فايلها استفاده كرد. پسوند پيش فرض نام فايل براي اين فايلها ndf است .

Transaction Log

اين فايلها شامل اطلاعات Log است كه براي بازيابي بانك اطلاعاتي مورد استفاده قرار مي گيرد.هر بانك اطلاعاتي حداقل يك فايل Log دارد. پسوند پيش فرض نام فايل براي اين فايلها ldf است .

 

براي مثال يك بانك ساده با نام Sales مي توانيم ايجاد كنيم كه شامل يك فايل Primary باشد كه همه اشياء و اطلاعات بانك اطلاعاتي در آن ذخيره شوند.و داراي يك فايل Log باشد كه شامل عمليات انجام شده روي بانك اطلاعاتي باشد.

به همين ترتيب يك بانك اطلاعاتي با نام Orders مي توانيم داشته باشيم كه شامل يك فايل Primary و پنج فايل Secondary باشد. و داراي چهار فايل Log باشد. در اين حالت داده ها و اشياء بانك اطلاعاتي بين شش فايل پخش مي گردد و تمام عمليات انجام شده در بانك در چهار فايل Log ذخيره مي شود.

به طور پيش فرض فايلهاي داده و Log در يك درايو و يك مسير قرار داده مي شوند. دليل اين كار اين است كه SQL Server را بتوان روي سيستمهاي با يك درايو اجرا كرد. اگر چه اين كار بهينه نيست . ما (مايكروسافت) توصيه مي كنيم كه فايلهاي داده و Log را روي ديسك هاي جداگانه قرار دهيد.

 

Filegroup ها

هر بانك اطلاعاتي داراي يك filegroup اوليه مي باشد.اين filegroup شامل فايل داده primary و هر فايل secondary ي مي باشد كه در filegroup  ديگري قرار نگرفته باشد. Filegroup هاي ديگري را مي توانيم ايجاد كنيم تا توسط آنها فايلها را دسته بندي كنيم. اين دسته بندي اعمال مديريت فايلها را آسانتر مي كند.

براي مثال سه فايل Data1.ndf, Data2.ndf و Data3.ndf را مي توانيم روي سه درايو مختلف ايجاد كنيم و آنها را در يك filegroup به نام fgroup1 قرار دهيم. آنگاه يك جدول خاص را مي توانيم در fgroup1 ايجاد كنيم. خواندن و نوشتن اطلاعات در اين جدول روي سه درايو پخش مي شود كه اين كار سرعت را افزايش مي دهد. همين افزايش سرعت را مي توانيم با استفاده از يك فايل و تكنولوژي RAID بدست آوريم. اگر چه فايلها و filegroup ها به شما اجازه مي دهند كه فايلهاي جديد را به راحتي به ديسك جديد اضافه كنيد.

تمام فايلهاي بانك اطلاعاتي در filegroup هاي جدول زير ذخيره مي شوند.

Filegroup

توضيحات

Primary

اين filegroup شامل فايل داده Primary مي باشد. تمام جداول سيستمي در اين filegroup قرار مي گيرند.

User-Defined

هر filegroup ي كه توسط كاربر ايجاد مي گردد. چه در هنگام ايجاد بانك اطلاعاتي و چه بعدا هنگام ويرايش بانك اطلاعاتي.

 

Filegroup پيش فرض

تمام اشيائي كه در بانك اطلاعاتي مي سازم اگر به طور خاص filegroup آنها را مشخص نكنيم آنها در filegroup پيش فرض ايجاد مي شوند. در هر لحظه فقط يك filegroup را مي توانيم به عنوان filegroup

پيش فرض معرفي كنيم . فايلهاي درون filegroup پيش فرض بايد به اندازه كافي بزرگ باشند تا تمام اشياء جديدي كه ايجاد مي شوند را در خود جاي دهند. نام filegroup  پيش فرض PRIMARY filegroup است.

Filegroup پيش فرض مي تواند توسط دستور ALTER DATABASE اصلاح گردد. اشياء و جداول سيستمي بر روي PRIMARY filegroup باقي خواهند ماند حتي اگر شما filegroup ديگري را به عنوان filegroup پيش فرض معرفي كنيد.

ارسال شده در مورخه : پنجشنبه هشتم فروردین 1387 ساعت 7:27 توسط محمد جهانشاهی |

SQL Server 2005 سرویسهای

 SQL Server 2005سرویسهای

 

Database Engine

Database Engine سرويس اصلي براي ذخيره سازي ، پردازش و امنيت اطلاعات مي باشد. این سرویس كنترل و اجراي اكثردستورات و تقاضاهاي شما را بر عهده دارد. اين سرويس همچنين وظيفه high availability را بر عهده دارد.

(high availability به معني اين است كه سرور شما هميشه در دسترس خواهد بود.)

Analysis Services

 

اين سرويس وظيفه پردازش تحليلي اطلاعات (OLAP) و استخراج اطلاعات (data mining) را از داده هاي موجود دارد. اين سرويس به شما اجازه مي دهد كه ساختارهاي چند بعدي شامل داده هاي جمع آوري شده از بقيه اطلاعات موجود را طراحي ، ايجاد و مديريت كنيد. Analysis Services برنامه هاي data mining را قادر مي سازد كه مدلهاي استخراج اطلاعات بصري را طراحي و ايجاد نمايند. اين مدلهاي استخراج اطلاعات مي تواند توسط گروه وسيعي از الگوريتمهاي استخراج اطلاعات مورد استفاده قرار بگيرند.

يك مثال ساده از كاربرد data mining :

فرض كنيم كه پليس 110 يك نرم افزار در اختيار دارد كه توسط آن آمار جرائم را نگهداري مي كند. در اين آمار، پليس اطلاعات مربوط به مكان و زمان وقوع جرم و نوع جرم مثلا دزدي را نگهداري مي كند. پس از مدتي پليس مي تواند اطلاعات مربوط به دزدي در يك مكان خاص را بررسي كند. مثلا پليس در بررسي و تحليل اطلاعات خود پي مي برد كه در فلان محله خاص بين ساعت 8 الي 10 صبح هيچ مورد دزدي گزارش نشده است بنابراين مي تواند نيروهاي خود را در آن زمان خاص در آن محله خاص كاهش داده و در جاي ديگري كه امكان وقوع دزدي بيشتر است استفاده كند.

 

Integration Services

اين سرويسها يك پلت فرم (مجموعه تكنولوژي) است كه راه حل هايي براي ايجاد يكپارچگي اطلاعات با سرعت بالا ارائه مي كند و شامل بسته هاي نرم افزاري پردازش extract, transform, and load (ETL) براي data warehousing است.

 

Replication

Replication مجموعه تكنولوژيهايي براي كپي اطلاعات و پخش اطلاعات و اشياء بانك اطلاعاتي از يك بانك اطلاعاتي به ديگري و سپس اعمال تغييرات همزمان بين دو بانك مي باشد. با استفاده از replication مي توانيد اطلاعات خود را بين مكانهاي مختلف و كاربران مختلف در هر جايي توسط شبكه هاي WAN و ارتباطات dial-up  و شبكه هاي بيسيم و اينترنت پخش كنيد.

 

Reporting Services

اين سرويس امكاناتي را براي ايجاد گزارش از بانك هاي اطلاعاتي مختلف در اختيارتان قرار مي دهد. گزارشهاي ايجاد شده توسط اين سرويس Web-enabled هستند و قابليت پخش روي انواع دستگاهها را دارند . شما مي توانيد اين گزارشات را با فرمتهاي مختلف (Excel و Word و PDF و Html و ...) ايجاد كنيد .

Notification Services

اين سرويس محيطي براي ايجاد برنامه هايي است كه پيامهايي را ايجاد و ارسال مي كنند. از اين سرويس مي توانيد براي ايجاد و ارسال پيامهاي شخصي و زمانبندي شده به هزاران يا ميليونها شخص يا دستگاههاي گوناگون استفاده نماييد.

Service Broker

اين سرويس به برنامه سازان كمك مي كند تا بتوانند برنامه هايي با مقياسهاي گوناگون و امنيت بالا توليد كنند. اين تكنولوژي جديد موتور بانكهاي اطلاعاتي ، يك پلت فرم ارتباطي بر اساس فرستادن پيام (message-based communication platform) را ارائه مي كند كه امكان اجراي كارها را به صورت كاملا مستقل از كامپوننت هاي برنامه ها فراهم مي سازد. اين سرويس شامل زيربنايي (ساختاري) براي نوشتن برنامه هاي غير همزمان (asynchronous ) روي يك بانك اطلاعاتي ، يك instance و همچنين برنامه هاي پخش شده (distributed) مي باشد.

 

Full-Text Search


 هنگامی که بخواهید یک کلمه یا متنی را در یک فیلد متنی جستجو کنید . و در query خود از like  استفاده کرده باشید این سرویس به شما کمک می کند تا query  شما سریع تر اجرا شود.

ارسال شده در مورخه : پنجشنبه هشتم فروردین 1387 ساعت 7:26 توسط محمد جهانشاهی |

نسخه هاي SQL Server 2005

نسخه هاي SQL Server 2005

 

1 - SQL Server 2005 Enterprise Edition (32-bit and 64-bit)

اين نسخه براي نيازهاي زير طراحي شده است :

1 – سيستم هاي OLTP خيلي بزرگ (منظور سيستمهايي كه همزمان حدودا 100000 كاربربه آن وصل هستند)

(OLTP = Online Transaction Processing)

2 – سيستم هايي كه بايد داده هاي خيلي پيچيده را آناليز و پرداژش كنند.

3 – سيستم هاي Data Warehouse

4 – سيستم هاي وب (Web Sites)

 

2 - SQL Server 2005 Standard Edition (32-bit and 64-bit)

اين نسخه براي سازمانهاي كوچك و متوسط طراحي شده است. داراي امكانات پايه براي تجارت الكترونيك و Data Warehouse نيز هست .

3 - SQL Server 2005 Workgroup Edition (32-bit only)

اين نسخه براي سازمانهايي است كه يك نسخه SQL Server  مي خواهند كه محدوديتي در تعداد كاربر و بانك اطلاعاتي نداشته باشد .

 

4 - SQL Server 2005 Developer Edition (32-bit and 64-bit)

اين نسخه داراي تمام امكانات نسخه Enterprise Edition مي باشد ولي فقط براي شركتهاي برنامه نويسي مورد استفاده قرار مي گيرد كه بتوانند سيستم هاي نوشته شده خود را تحت SQL Server تست كنند.

 

5 - SQL Server 2005 Express Edition (32-bit only)

اين نسخه مجاني است و با Visual Studio 2005 به صورت مجاني ارائه مي شود.

ارسال شده در مورخه : پنجشنبه هشتم فروردین 1387 ساعت 7:22 توسط محمد جهانشاهی |

آموزش triggerدر Sql Server 2000

قسمت دوم:

ایجاد و مدیریت تریگرها:

تریگرها معمولاً با استفاده از Query Analyzer یا گزینه های موجود در Enterprise Manager ایجاد و مدیریت می شوند. یک تریگر با استفاده از عبارت Create Trigger ایجاد می شود. در فرآیند ایجاد تریگر، تریگر بر روی یک جدول یا دید اعمال می شود، بعد از اینکه تریگر ایجاد شد، با استفاده از عبارت Alter Trigger می توان آن را تغییر داد. با استفاده از رویه های ذخیره شده سیستمی یا Enterprise Manager می توان تریگرها را تغییرنام داده و مشاهده کرد. از عبارت Drop Trigger برای حذف یک تریگر استفاده
می شود و از عبارت
Alter Table برای فعال یا غیرفعال کردن تریگرها استفاده می شود.

ایجاد تریگر:

عبارت های اصلی عبارت Create Trigger را می توان به صورت زیر خلاصه کرد:

Create Trigger trigger_name

ON table_name or view_name

FOR {INSERT,UPDATE,DELETE}

[WITH ENCRYPTION]

AS transact_sql statements

عبارت Create Trigger:

برای ایجاد تریگر با استفاده از عبارت Create Trigger نام تریگر، بعد از این عبارت قرار می گیرد. در تریگر نمی توان نام پایگاه داده را به عنوان یک پیشوند به نام شیء اضافه کرد بنابراین با استفاده از عبارت USE database_name و کلمه کلیدی GO قبل از ایجاد تریگر پایگاه داده را انتخاب نمائید. GO باید بیان شود چون Create Trigger باید اولین عبارت یک دسته پرس و جو باشد.

مجوز پیش فرض برای ایجاد تریگرها به طور پیش فرض در دست صاحب جدول می باشد.

برای مثال برای ایجاد یک تریگر به نام Alerter در پایگاه داده BookShopDB می توان از کد زیر استفاده نمود.

USE BookShopDB

GO

Create trigger alerter

عبارت ON:

تریگرها را باید به یک جدول یا یک دید تخصیص داد. از عبارت ON استفاده کنید تا به تریگر بگویید بر کدام جدول یا دید اعمال شود.

مثال:

Create Trigger alerter

ON employees

یک تریگر فقط بر یک جدول یا دید اعمال می شود. اگر باید همان تریگر را بر جدول دیگری اعمال کنید، یک تریگر با نام دیگری ایجاد کنید که حاوی همان منطق باشد. سپس تریگر جدید را بر جدول دیگر اعمال کنید. After (گروه پیش فرض تریگر) را می توان فقط بر یک جدول اعمال کرد. گروه تریگر جدید یعنی Instead of را می توان هم بر جدول و هم بر دید اعمال کرد.

عبارت های For, After, Instead of:

وقتی تریگر ایجاد می شود، نوع رویداد تریگر باید مشخص شود. رویدادهی معتبر شامل Insert, Update, Delete می باشند. یک تریگر می تواند به د لیل رخداد یک، دو یا هر سه رویداد برانگیخته شود. اگر می خواهید یک تریگر در صورت رخداد همه رویدادها برانگیخته شود Insert, Update, Delete را بعد از عبارتهای For, After یا Instead of بیاورید. رویدادها می توانند به هر تریبی لیست شوند. برای مثال برای اینکه یک تریگر به نام Alerter در صورت بروز همه رویدادها برانگیخته شود، می توان از کد زیر استفاده کرد:

Create Trigger alerter

ON employees

FOR insert,update,delete

عبارت For با عبارت After مترادف است. بنابراین کد قبلی یک تریگر از نوع After ایجاد می کند.

عبارت With Encryption: 

این گزینه برای پنهان کردن محتویات یک تریگر استفاده می شود. این گزینه کاربر را از به کارگیری sp_helptext به منظور مشاهده محتویات تریگر منع می کند. تحت این شرایط، کاربران قادر به انتخاب ستون های نوع Text از جدول Syscomments نخواهند بود. (برای مثال دستور SELECT text FROM syscomments WHERE name=tablename را نمی توان به کار گرفت)، زیرا متون رمزگذاری شده اند.

عبارت AS:

پس از این عبارت مجوعه ای از دستورات SQL ذکر می شوند.

?نکته:

برخی از فرمانها را نمی توان از طریق تریگرها به اجرا درآورد. این دستورات عبارتند از:

Create, Drop, Grant, Revoke. در مقابل دستورات Select into, Truncate table, Alter table, Alter database, Update Statistics, Reconfigure, Load Database, Load Transaction و کلیه دستورات مربوط به DISK دستورات معتبری هستند.

مثال:

این مثال نحوه ایجاد یک تریگر را نشان می دهد وقتی یک Insert, Update یا Delete بر جدول Employees رخ می دهد، تریگر یک Email را به کاربری به نام BarryT می فرستد.

USE BookShopDB

GO

CREATE TRIGGER alerter

ON employees

AFTER INSERT, UPDATE, DELETE

AS

EXEC master..xp_sendmail ‘BarryT’,

‘A record was just inserted, update or deleted in the employees table.’

GO

مدیریت تریگر:

تریگرها اشیاء پایگاه داده ای قدرتمند هستند که وقتی یک جدول یا یک دید تغییر می کند به طور خودکار اجرا می شوند. از چندین دستور و ابزار پایگاه داده ای برای مدیریت تریگرها استفاده می شود.

تریگرها را می توان:

ü با استفاده از Alter Trigger تغییر داد.

ü با استفاده از رویه ذخیره شده سیستمی sp_rename تغییر نام داد.

ü با پرس و جوی جداول سیستمی با استفاده از رویه های ذخیره شده سیستمی sp_help trigger و یا sp_helptext مشاهده کرد.

ü با استفاده از عبارت Drop Trigger آن ها را حذف کرد.

ü با استفاده از عبارتهای Disable Trigger و Enable Trigger (موجود در عبارت Alter Table) فعال یا غیرفعال کرد.

تغییر و تغییرنام تریگرها:

برای تغییر یک تریگر، می توان آن را حذف کرده و دوباره ایجاد کرد. راه دیگر، استفاده از عبارت Alter Trigger می باشد. ساختار عبارت Alter trigger شبیه به ساختار
Create Trigger می باشد. اما Alter Trigger، تریگر را از جداول سیستمی Syscomments و Sysobjects حذف نمی کند. مثال زیر نشان می دهد که چگونه می توان Alter را تغییر داد تا فقط به روز رسانی های جدول Employees را گزارش دهد:

Alter Trigger alerter

ON employees

AFTER UPDATE

AS

EXEC master..xp_sendmail ‘BarryT’,

‘A record was just hupdated in the employees table.;

GO

توجه داشته باشید که Update تنها رویدادی است که بعد از عبارت AFTER آمده است و این که متن موجود در پیغام Email نیز تغییر کرده است.

تغییر نام یک تریگر:

برای تغییر نام یک تریگر از رویه سیستمی ذخیره شده sp_rename استفاده می شود.

مثال زیر نحوه تغییر نام تریگر Alerter به EmpAlerter را نشان می دهد.

Sp_rename @objname=alerter, @newname=empaleter

مشاهده، حذف و غیر فعال کردن تریگرها:

وقتی یک رویه ذخیره شده ایجاد می شود، نام آن و سایر اطلاعات شناسایی آن درجدول سیستمی Sysobjects پایگاه داده جاری ذخیره می شوند.متن موجود در تریگر در جدول سیستمی Syscomments ذخیره می شود. عبارت Select زیر تمامی تریگرهایی را نشان می دهد که بر جداول پایگاه داد BookShopDB اعمال شده است.

Select * from BookShopDB.sysobjects where type=’tr’

ستون Type همیشه تریگرهایی را لیست می کند که دارای مقدار tr باشند.

نمایش خصوصیات یک تریگر:

برای نمایش خصوصیات یک تریگر از رویه سیستمی sp_help استفاده می شود.

برای مثال برای نمایش خصوصیات تمامی تریگرهای تعریف شده برای جدول Employees، کد زیر را تایپ کنید:

Sp_helpTrigger @tbname=employees

نمایش متن موجود در یک تریگر:

برای اینکه اطلاعات با سازماندهی بیشتری نمایش داده شوند، از رویه ذخیره شده سیستمی sp_helptext استفاده کنید. برای مثال برای نمایش متن موجود در تریگر با نام Alerter عبارت زیر را تایپ کنید:

Sp_helptext @objname=alerter

حذف تریگر:

حذف یک تریگر آن را از جدول سیستمی Syscomments و Sysobjects حذف می کند. از عبارت Drop Trigger می توان برای حذف یک یا چند تریگر استفاده نمود. اگر یک جدول یا یک دیدِ دارای تریگر را حذف کنید، تمام تریگرهای تخصیص داده شده به جدول یا دید نیز حذف خواهند شد.

برای حذف Alerter از پایگاه داده BookShopDB کد زیر را تایپ کنید.

USER BookShopDB

DROP Trigger alerter

غیرفعال کردن تریگرها:

ممکن است بخواهید یک تریگر یا تریگرهای مربوط به یک جدول را غیرفعال سازید. بری مثال وقتی که می خواهید مشکل یک پایگاه داده را عیب یابی کنید یا تغییرات یک پایگاه داده را بررسی کنید یا رویه ای را ایجاد کنید که در آن صورت تریگر موجود بر یک جدول باید غیر فعال شود. برای غیرفعال کردن یک تریگر از عبارت Alter Table استفاده کنید. کد زیر تریگر Alter را در جدول Employees غیر فعال می کند.

Alter Table employees Disable Trigger alerter

برای غیرفعال کردن همه تریگرهای موجود در یک جدول، بعد از عبارت Disable Trigger از کلمه کلیدی All استفاده کنید. برای فعال کردن یک یا همه تریگرها در عبارت Alter table، Disable را به Enable تغییر دهید.

ارسال شده در مورخه : چهارشنبه هفتم فروردین 1387 ساعت 11:43 توسط محمد جهانشاهی |

آموزش تریگر در Sql Server 2000

قسمت اول:

تریگرها: 

از آنجا که تریگرها دسته هایی از فرامین SQL مرتبط به هم را مورد استفاده قرار می دهند، شبیه به رویه های ذخیره شده هستند. با این وجود، تریگرها تنها هنگام درج، بهنگام سازی، و حذف داده ها اجرا می شوند.

پیش از این تریگرها برای تأمین جامعیت ارجاعی در بانک اطلاعاتی استفاده می شدند. اما اکنون SQL Server دارای محدودیتهای کلید اصلی و خارجی است که تقریباً نیاز به استفاده از تریگرها را برای تأمین جامعیت ارجاعی مرتفع می کند. با این وجود، هنوز در برخی از مواقع می توان به خوبی از مزایای تریگرها بهره گرفت.

تریگرها مجموعه ای از دستورات SQL هستند که به هنگام رویدادUpdate, Insert, Delete اجرا می شوند. هر جدول از بانک اطلاعاتی می تواند حداکثر سه تریگر داشته باشد. (داشتن تریگر برای جدول الزامی نیست).

به عنوان مثال جدول Author می تواند شامل سه تریگر زیر باشد:

Authors_ti: تریگر درج، که هنگام عمل درج در جدول Authors اجرا می شود.

Authors_tu: تریگر بهنگام سازی، که در اثر بهنگام سازی جدول Authors اجرا می شود.

Authors_td: تریگر حذف، که هنگام حذف داده ای از جدول Authors اجرا می شود.

گسترش جامعیت داده ها با استفاده از تریگرها:

کیفیت یک پایگاه داده بر حسب سازگاری و صحت و درستی داده های موجود در آن پایگاه داده سنجیده می شود.

تریگرها به شما امکان می دهند تا رویه ای بنویسید تا به هنگام تغییر داده های جدول بر اثر اعمال دستورات Insert, Update, Delete برانگیخته شوند. یک تریگر را می توان بر یک جدول یا یک View اعمال کرد. از تریگرها برای اعمال قوانین تجاری بر یک پایگاه داده استفاده می شود. برای مثال، یک قانون تجاری تعریف شده برای پایگاه داده BookShopDB به صورت زیر است: وقتی یک کتاب به سفارش اضافه می شود، در فهرست انبار به عنوان کالای فروخته شده علامت گذاری می شود.

یک تریگر که بر جدول BookOrders اعمال شده است می تواند به هنگام درج یک سفارش کتاب برانگیخته شود. منطق تجاری موجود در تریگر، کتاب را در جدول Books قرار داده و کتاب را به عنوان فروخته شده علامت گذاری می کند.

از تریگردر موارد زیر استفاده می شود:

ü تغییرات باید در جدول مرتبط به هم در پایگاه داده به صورت آبشاری اعمال شود، برای مثال برای جدول orders یک تریگر ایجاد کرده و اعمال می نمایید تا وقتی سفارش وارد می شود تعداد موجود در جدول Inventory تغییر پیدا کند. برای جدول inventory یک تریگر دیگر ایجاد کرده و اعمال می نمایید تا وقتی تعداد تغییر می کند، یک درخواست خرید به جدول Purchasing اضافه شود.

ü اگر پایگاه داده نرمالیزه نشده است (یعنی داده ها بیش از حد تکرار شده اند) می باید راه خودکار برای به روز در آوردن این داده های تکراری (که در چندین جدول وجود دارند) ارائه دهید.

ü اگر یک مقدار در یک جدول باید با یک مقدار غیر مشابه در یک جدول دیگر مقایسه شود.

اگر می خواهید پیغام هایی به دلخواه خود ایجاد کنید و یا می خواهید مدیریت خطای پیچیده داشته باشید.

محدودیت های تریگر:

تریگرها را نمی توان در یک جدول موقت یا سیستمی ایجاد کرد.

برای جداولی که جامعیت ارجاعی آبشاری Update On یا On Delete برای آنها تعریف شده است نمی توان تریگرهای Instead of delete یا Instead of update تعریف کرد.

رویدادهای تریگر:

سه رویداد به طور خودکار یک تریگر را بر می انگیزد: رویدادهای Update, Insert, Delete که بر روی یک جدول یا View رخ می دهند. تریگرها را نمی توان به طور دستی برانگیخت. نوع تریگرها با رویداد مطابقت دارد برای مثال می توان یک تریگر به روز رسانی ایجاد کرد تا وقتی که یک Update بر روی یک جدول رخ می دهد این تریگر برانگیخته شود. در یک تریگر می توان به چندین رویداد پرداخت. به این معنی که می توانید یک رویه ایجاد کنید که هم تریگر به روز رسانی (Update) و هم درج (Insert) باشد در تعریف یک تریگر رویدادها را می توان با هر ترتیبی لیست کرد.

نمونه های خاصی وجود دارد که وقتی یک رویداد به منظور تغییر یا حذف داده ها رخ
می دهد تریگر معادل را بر نمی انگیزد.

برای مثال عبارت Truncate Table، تریگرهای تعریف شده برای رویدادهای Delete را بر نمی انگیزد. یک ویژگی مهم تریگرها این است که تراکنش های غیر موفق به طور خودکار Rollback می کنند. از آنجاکه Truncate Table یک رویداد ثبت شده نیست نمی تواند Rollback کند در نتیجه نمی تواند تریگر مربوطه به Delete را برانگیزد. همچنین عبارت Writetext باعث برانگیخته شدن تریگرهای Insert یا Update نمی شود.

اجرای تریگر:

وقتی در یک جدول مقداری درج می شود یا به روز در می آید یک تریگر برانگیخته می شود این تریگر داده جدید یا تغییر داده شده را در یک جدول به نام Inserted ذخیره می کند. وقتی یک جدول حذف می شود باز هم یک تریگر برانگیخته می شود این تریگر، داده های حذف شده را در جدولی به نام Deleted ذخیره می کند. جدول در حافظه وجود دارد و از طریق دستورات Transact SQL از درون تریگر پرس وجو می شود. این توانایی، در عملکرد اثر تریگرها بسیار مهم و اساسی است چرا که وظیفه ای که درون تریگر قرار دارد پیش از اعمال تغییرات، داده های موجود در جداول Inserted یا Deleted را با داده های موجود در جداول تغییر داده شده مقایسه می کند.

دو نوع گروه تریگر در SQL Server 2000 وجود دارد:

Instead of و After.

تریگرهای Instead of کار برانگیخته شدن را کوتاه کرده و در مکان خود اجرا می شوند. برای مثال، یک به روز رسانی در جدولی که حاوی یک تریگر از نوع Instead of است باعث می شود به جای عبارت به روز رسانی، کد Transact SQL مربوط به تریگر اجرا شود.

چند تفاوت اساسی بین گروه های تریگر وجود دارد که در جدول زیر نشان داده شده اند:

ویژگی

Instead of

After

محل اعمال

به روی یک جدول یا یک دید تعریف می شوند

تعریف یک تریگر بر روی یک دید، انواع به روز رسانی هایی که یک دید می تواند پشتیبانی کند را افزایش می دهد.

بر روی یک جدول تعریف می شوند

درصورتی تغییرات دیدها باعث برانگیخته شدن تریگرهای After می شود که داده های جدول در پاسخ به تغییرات دید، تغییر داده شوند.

تعداد ممکن

بر روی جدول یا دید می توان فقط یک تریگر تعریف کرد

می توانید بر روی دیدها دیدهای دیگری تعریف کنید طوری که هر دید، تریگر Instead of خودش را داشته باشد

بیش از یک تریگر مجاز است

ترتیب اجرا

چون فقط یک تریگر بر روی یک جدول یا دید امکان دارد پس ترتیب معنا ندارد

می توان تعیین کرد کدام تریگر اول و کدام آخر برانگیخته شود. از رویه ذخیره شده سیستمی Sp_Settriggerorder برای تعریف اولین و آخرین تریگر استفاده نمایید. بقیه تریگرهای اعمال شده بر روی یک جدول به ترتیب تصادفی اجرا می شوند.

می توان هردو تریگر را به یک جدول اعمال کرد. اگر برای جدول هر دو گروه تریگر و یک سری محدودیت را تعریف کنید، ابتدا تریگر نوع Instead of برانگیخته می شود سپس محدودیتها پردازش می شود و بعد تریگرهای نوع After برانگیخته می شوند. اگر محدودیتها نقض شوند، کارهایی که تریگر نوع Instead of انجام داده است، Rollback 
می کنند. اگر محدودیت ها نقض شوند یا اگر رویدادهای دیگری رخ دهد که تغییرات جدول با موفقیت انجام نشود، تریگرهای نوع
After اجرا نمی شوند.

تریگرها می توانند تا 32 سطح عمق داشته باشند و می توانند به طور خودبازگشتی برانگیخته شوند.

ارسال شده در مورخه : چهارشنبه هفتم فروردین 1387 ساعت 11:42 توسط محمد جهانشاهی |

كسب‌و‌كار هوشمند در SQL Server 2005

اگر بخواهيم به تاريخچه بانك‌هاي اطلا‌عاتي و نقش هميشگي آن‌ها در ذخيره و بازيابي اطلا‌عات بنگريم، سال‌هايي را در حيات اين پديده مبتني بر فناوري اطلا‌عات مي‌يابيم كه در طي آن‌ها، بانك‌هاي اطلا‌عاتي از يك ابزار با كاربرد صرفِ ذخيره‌سازي اطلا‌عات، به يك برنامه كامل جهت نيل به بسياري از اهداف تجاري تبديل شده است. در اين مقاله نگاهي خواهيم داشت به سرويس جديدي موسوم به Analysis Service كه در نسخه 2005 بانك اطلا‌عاتي SQL Server براي اين منظور در نظر گرفته شده است.

     
SQL Server 2005

اگر بخواهيم به تاريخچه بانك‌هاي اطلا‌عاتي و نقش هميشگي آن‌ها در ذخيره و بازيابي اطلا‌عات بنگريم، سال‌هايي را در حيات اين پديده مبتني بر فناوري اطلا‌عات مي‌يابيم كه در طي آن‌ها، بانك‌هاي اطلا‌عاتي از يك ابزار با كاربرد صرفِ ذخيره‌سازي اطلا‌عات، به يك برنامه كامل جهت نيل به بسياري از اهداف تجاري تبديل شده است. امروزه هوشمندي كسب و كار (BI) يا به عبارتي تجزيه و تحليل داده‌هاي ذخيره شده براي برنامه‌ريزي درازمدت در آينده، موضوعي است كه به شدت مورد توجه سازندگان بانك‌هاي اطلا‌عاتي، از جمله مايكروسافت، قرار گرفته است. در اين مقاله نگاهي خواهيم داشت به سرويس جديدي موسوم به Analysis Service كه در نسخه 2005 بانك اطلا‌عاتي SQL Server براي اين منظور در نظر گرفته شده است.

ساختار

در Analysis Service 2005 موجوديت مكعب (cube) به عنوان مهم‌ترين ابزار تحليل داده‌ها، مورد توجه خاصي قرار گرفته است. cube يك شي چند بعدي است كه مي‌تواند اطلا‌عاتي را براساس اطلا‌عاتي ديگر به ما نشان داده يا با هم مقايسه كند. ابعاد اين مكعب در واقع فاكتورهايي هستند كه ما مي‌خواهيم داده‌هايمان را بر اساس آن‌ها مقايسه كنيم.

مثلا‌ً در يك سيستم انبار، نوع كالا‌ مي‌تواند يكي از ابعاد مناسب براي بررسي ورود و خروج كالا‌ باشد. يكي از مهم‌ترين فاكتورها يا ابعادي كه يك مكعب مي‌تواند داشته باشد، بعد زمان است. تقريباً مي‌توان گفت كه در هيچ سيستمي، زمان مسئله كم‌اهميتي نيست. مثلا‌ً ورود و خروج كالا‌ها در بازه‌هاي زماني روزانه، ماهانه، سالا‌نه و ... يا ميزان درآمد و هزينه‌ها طي بازه‌هاي زماني خاص از جمله فاكتورهايي محسوب مي‌شوند كه عموماً مورد توجه شركت‌ها قرار دارند.

در Analysis Service ابعاد يك مكعب را در قسمت Dimensions تعريف مي‌كنند. اما مقادير كه به ازاي در كنار هم قرار گرفتن اين ابعاد،‌ بايد توسط سيستم محاسبه و نمايش داده شود، مقاديري هستند كه نهايتاً هدف يك cube را از نتيجه تجزيه و تحليل داده‌ها بيان مي‌كنند و به آن‌ها، مقياس (Measure) گفته مي‌شود.

معمولا‌ً فاكتورهايي چون ماكزيمم و مينيمم، جمع و ... . يك ارزش عددي در بازه‌اي از مقادير يك بُعد (Dimension) مي‌تواند به عنوان يك مقياس در نظر گرفته شود.


يكي از مثال‌هاي سايت مايكروسافت كه يك مكعب تحليلي از تعداد پكيج‌هاي مسافرتي و تاريخ آن‌را بر اساس ابعاد، زمان، مكان و نوع سفر ارائه مي‌دهد.

معمولا‌ً فاكتورهايي چون ماكزيمم و مينيمم، جمع و ... . يك ارزش عددي در بازه‌اي از مقادير يك بُعد (Dimension) مي‌تواند به عنوان يك مقياس در نظر گرفته شود.

مثلا‌ً جمع ورود و خروج يك نوع كالا‌ در بازه‌اي از زمان يك Measure مناسب براي دو بُعد نوع كالا‌ و زمان به حساب مي‌آيد يا مثلا‌ً ميزان درآمد ماهانه شركت مي‌تواند يك مقياس براي دو بُعد واحد پول و زمان، در نظر گرفته شود.


راه‌حل‌هاي تجاري

●بسياري از سازمان‌هاي بزرگ تجاري داراي چندين سيستم اطلا‌عاتي مثل سيستم‌هاي ERP يا SCM هستند.

اين سيستم‌ها ممكن است حتي تحت چند پلتفرم يا موتور پايگاه داده‌اي مختلف در سطح آن سازمان پراكنده شده باشند. بنابراين جمع‌آوري اطلا‌عات و مقايسه و نتيجه‌گيري از چند منبع اطلا‌عاتي مختلف بدين شكل، كار بسيار مشكلي است.

حتي در صورتي كه بخواهيم در چنين سازمان‌هايي، فقط يك منبع اطلا‌عاتي را مورد تجزيه و تحليل قرار دهيم، داده‌هاي موجود در آن را بايد به محيطي منتقل كنيم تا امكان تجزيه و تحليل و ساير اعمال محاسباتي پيچيده بر آن فراهم شود.

در ابزار جديد Analysis Service مفهومي به نام Unified Dimensional Model) UDM) در نظر گرفته شده كه به معناي ايجاد يك مدل تجاري مجتمع و يكتا با خاصيت چندبُعدي روي يك يا چند منبع اطلا‌عاتي است.

بر اين اساس، شي يا موجوديتي به نام Data Source View ساخته مي‌شود كه شامل كليه جداول يا ديدهاي يك يا چند بانك اطلا‌عاتي همگون يا ناهمگون است. پس از تعريف اين شي و برقراري روابط ميان فيلدهاي اطلا‌عاتي جداول يا ديدهاي موجود در آن، مي‌توان اقدام به ساخت شِماهاي چندبُعدي يا همان مكعب كرد.

به عنوان مثال، مي‌توان ميزان فروش يك سري اقلا‌م خاص را در طي يك توالي زماني مشخص به صورت يك نمودار سه بعدي نمايش داد. استفاده از اين تكنيك علا‌وه بر رساندن ما به هدف مورد نظر كه همان گردآوري اطلا‌عات گوناگون و تهيه نمودارهاي چند بعدي آماري براساس آنان است، دو مزيت ديگر هم دارد: اول اين‌كه، از انواع منابع اطلا‌عاتي مثل انواع بانك‌هاي اطلا‌عاتي رابطه‌اي، بانك‌هاي ويژه انجام فرايندهاي پردازشي (OLTP)، ‌فايل‌هاي تخت (Flat) يا حتي سرويس‌هاي وب، مي‌تواند استفاده نمايد.

دوم اين‌كه، به دليل ماهيت فيزيكي cube كه خودش نوعي فضاي ذخيره‌سازي موقت براي داده‌ها است، تداخل خاصي با پردازش‌ها و فرايندهاي در حال اجرا روي اطلا‌عات اصلي موجود در منابع اطلا‌عاتي نداشته و روي كارايي و سرعت آن‌ها اثر منفي محسوسي ندارد.

●يكي از روش‌هاي مرسوم ذخيره‌سازي اطلا‌عات در سيستم‌هاي بزرگ، تقسيم‌بندي انباره اطلا‌عات (Data Warehouse) به واحدهاي كوچك‌تر با كاربردهاي مختلف مي‌باشد كه به آن Data Mart گفته مي‌شود. بر اين ‌اساس، مثلا‌ً محل ذخيره‌سازي داده‌هاي مربوط به اسناد مالي از محل ذخيره داده‌هاي مربوط به وضعيت عرضه و تقاضاي بازار مصرف جدا شده و هر كدام در محل خاصي قرار مي‌گيرند. در اين حالت دو مشكل مي‌تواند به وجود آيد: اول اين‌كه تعدد Data martها در سازمان به دليل مشكل بودن ايجاد رابطه ميان اطلا‌عات آن‌ها، به كُندشدن هر نوع تجزيه و تحليل آماري مي‌انجامد. دوم اين‌كه، حتي براي گزارش‌هاي ساده‌تر كه فقط روي يك Data Mart بايد انجام شود، به دليل احتمال هم‌سنخ‌نبودن مخازن اطلا‌عاتي با يكديگر، بايد برنامه‌هاي مختلفي را براي گزارش‌گيري يا تجزيه و تحليل اطلا‌عات، مورد استفاده قرار داد.

با اين حال به لطف وجود Analysis Service، هر دو مشكل مذكور به نحو مطلوبي رفع شده‌اند: اول اين‌كه، ساختار مدل‌سازي واحد (UDM) محيطي متمركز براي نگهداري يك كپي كامل از تمام Data Martها است. ضمن اين‌كه قادر است به هر كاربر و هر دپارتماني از آن سازمان صرفاً اطلا‌عات و تجزيه و تحليل‌هاي مورد نياز خودش را نشان دهد. به اين دسته‌بندي منطقي داده‌ها بر اساس كاربرد، اصطلا‌حا ًPresPective گفته مي‌شود.

با وجود پرسپكتيوهاي مختلف از يك UDM، هم مسئله تقسيم‌بندي داده‌هاي مورد نياز دپارتمان‌ها حل مي‌شود و هم مشكل لينك شدن اطلا‌عات موجود در Data Martهاي مختلف با يكديگر، برطرف مي‌گردد. اما اين مسئله از نقطه نظر ديگري نيز قابل بررسي است. در گذشته، جدايي و تفاوت بين سيستم‌هاي فرايندي (OLTP) و سيستم‌هاي تحليلي (OLAP) بسيار آشكار بود.

سازمان‌ها داده‌هاي خود را در OLTP ذخيره و پردازش مي‌كردند. سپس داده‌هاي پردازش‌شده را به OLAP منتقل مي‌نمودند تا بتوانند بدون تأثير منفي در كارايي و سرعت پردازش‌داده‌ها درOLTP، آناليز اطلا‌عات را به راحتي انجام دهند. اما اكنون و به لطف وجود UDM داده‌هايي كه توسط OLTP پردازش مي‌شوند، بي‌درنگ به OLAP منتقل مي‌گردند. در اين روش محل ذخيره اطلا‌عات مورد نياز OLTP و OLAP واحد است و داده‌ها بر اساس يك مكانيسم بي‌درنگ (Real Time) در هنگام هر نوع انتقال يا پردازش به فضاي مورد نياز گزارش‌هاي تحليلي OLAP آورده شده وcubeهاي آناليزي موجود در آن را بروز (update) مي‌كند.

در اين صورت به دليل يكتا بودن محل ذخيره‌سازي اطلا‌عات نيز،‌نيازي به استفاده از برنامه‌هاي مختلف براي دسترسي به مخازن اطلا‌عاتي مختلف نمي‌باشد. بنابراين مسئله گفته شده در اين بند نيز با اين ويژگي جديد حل مي‌شود.

●يكي از ويژگي‌هاي هميشگي برنامه‌ها و ابزارهاي گزارش‌گيري، امكان كنكاش و تحليل اطلا‌عات در لا‌يه‌هاي مختلف است. به عنوان مثال، يك برنامه گزارش‌گيري مي‌تواند در يك لا‌يه، رابطه ميان فروش محصولا‌ت خود و مشتريان خريدار آن محصولا‌ت را به صورت يك جدول دو بعدي نشان دهد. در لا‌يه ديگري، همين برنامه مي‌تواند رابطه ميان فروش محصولا‌ت و كارخانه‌هاي سازنده آن‌ها را بيان نمايد و بالا‌خره در لا‌يه سوم و در صورت لزوم مي‌تواند بين سه فاكتور مذكور يك نمودار سه‌بعدي ايجاد كند كه اين حالت از پيشرفته‌ترين ويژگي‌هاي يك ابزار گزارش‌گيري محسوب مي‌شود.

با اين همه، نيازهاي كارشناسان تجاري يك شركت محدود به اين نوع گزارش‌ها نمي‌باشد. در برخي موارد يك تحليلگر نياز به در كنار هم قراردادن و مقايسه چندين فاكتور مختلف از چند موجوديت مجزا را دارد. به عنوان نمونه، در همان مثال قبل فرض كنيد مي‌خواهيم روابطي را براساس فاكتورهاي تاريخي قابل محاسبه مثل تاريخ سفارش، تاريخ تحويل، تاريخ ساخت كالا‌ و تاريخ فروش به مشتري را براي چند نوع كالا‌ي مختلف به دست آوريم.

بنابراين اينگونه گزارش‌هاي چندبعدي با مدل گزارش‌گيري سنتي (سلسله مراتبي) يا نمودارهاي ساده موجود در آن‌ها قابل ايجاد نمي‌باشد. اما Analysis Service راه‌حلي را براي نيل به اين هدف در نظر گرفته كه جزء ويژگي‌هاي مدل چند بُعدي (UDM) آن است و به نام ابعاد مبتني بر خصوصيت (Attribute Based Dimension) شناخته مي‌شود. براساس اين ويژگي، تحليلگران قادر خواهند بود تجزيه و تحليل اطلا‌عات خود را نه به شكل سلسله مراتبي (كه در روش سنتي ميسر بود)، بلكه به صورت همزمان و چندبعدي انجام دهند. مثلا‌ً مي‌توان با اين روش آمار هر نوع خصوصيت كالا‌ي فروخته شده مثل رنگ، اندازه، وزن، واحد و... را به صورت يكجا و در قالب ابعاد مختلف ويژگي‌هاي كالا‌ها، به دست آورد.

همچنين با استفاده از قابليت ديگري كه به آن <ايفاي نقش> يا Role Playing مي‌گويند، مي‌توان يك ويژگي را به عنوان مبناي يك تجزيه و تحليل قرار داد و آن‌گاه ويژگي‌هاي ديگر هم سنخ آن را به عنوان ابعاد ديگر آن تحليل بررسي نمود. مثلا‌ً مي‌توان فاكتور زمان (روز، ماه، سال و ...) را به عنوان يك ويژگي عام در نظر گرفت و آنگاه تعداد كالا‌ي خريداري، فروخته شده و تحويل شده را براساس آن فاكتور زمان به عنوان ابعاد ديگر اين تحليل معرفي نمود و با يكديگر مقايسه كرد.

● يكي از روش‌هايي كه OLAPهاي سنتي براي جلوگيري از كاهش راندمان سرور اصلي بانك‌اطلا‌عاتي به كار مي‌بردند اين بود كه از سرور ديگري براي گرفتن گزارش‌هاي تحليلي استفاده مي‌نمودند. سرور دوم شامل همان ساختار بانك اطلا‌عاتي سرور اول بود و داده‌ها نيز در يك تناوب زماني مثلا‌ً در نيمه‌هاي شب و هنگام كاهش ترافيك شبكه، به سرور دوم كپي مي‌شد. اين شيوه براي كاربردهايي چون تحليل درآمدهاي ساليانه يا ساير تحليل‌هاي درازمدت با كاربرد مشابه، كار معقولي به نظر مي‌رسيد.

اما براي كاربردهايي كه نياز به بررسي آني آخرين وضعيت براي برنامه‌ريزي كوتاه‌مدت داشت، روش مناسبي نبود؛ چرا كه امكان داشت هنوز آخرين اطلا‌عات به سرور OLAP (سرور دوم) كپي نشده باشد. سيستم‌هاي برنامه‌ريزي توليد از جمله سيستم‌هايي بود كه نياز به داشتن چنين گزارش‌هاي كوتاه مدتي داشت. در Analysis Service اين مسئله با كپي‌شدن آني و بي‌درنگ داده‌ها به سرور OLAP در حين انتقال به سرور اصلي حل شده است. با اين كار داده‌ها بلا‌فاصله در سرور دوم و در محل cubeهاي ساخته‌شده قرار مي‌گيرند و حتي تجزيه و تحليل‌هاي موجود نيز به صورت بي‌درنگ بروز مي‌شوند. اين خاصيت، مهم‌ترين ويژگي يك سيستم BI پيشرفته امروزي به شمار مي‌رود


منبع : sqliran

ارسال شده در مورخه : سه شنبه نهم بهمن 1386 ساعت 10:2 توسط محمد جهانشاهی |

با SQL Server 2005 بيشتر آشنا شويد


با نسخه جديد SQL Server ،برنامه نويسان بانك هاي اطلاعاتي قادرند از امكانات و قابليت هاي موجود در پلتفرم دات نت و كليه توابع و كلاس هاي ساخته شده در آن بهره مند شوند. يكي از ابتدايي ترين و در عين حال اساسي ترين اين قابليت ها،امكان استفاده از دو زبان مهم و كاربر پسند دات نت يعني ويژوال بيسيك و سي شارپ در پياده سازي اجزاي مختلف يك بانك اطلاعاتي است.

     
Snapshot lsolation level

يكي از روش هايي كه به انواع متدهاي قفل كردن رديف هاي يك جدول بانك اطلاعاتي در نسخه جديد اضافه شده است شيوه تصوير برداري از ركورد است. در روش هاي قبلي،اگر يك يا چند ركورد بانك اطلاعاتي توسط دستور Begitn Trans كه شروع يك فرآيند را مشخص مي كند در شرف تغيير يا حذف قرار مي گرفتند،تا مادامي كه فرآيند مذكور توسط دستور Commit Trans تاييد يا توسط ROLLBack منتفي نشود،از هيچ جا و برنامه اي نمي توان ركوردهاي مذكور را حتي با دستور ساده SELECT خواند. اما در روش جديد قفل گذاري در صورت بروز چنين رويدادي ساير كاربران مي توانند همواره آخرين ارزش ركوردهاي مذكور را با اين فرض كه هنوز هيچ تغييري در آن ها ايجاد نشده است بخوانند و مورد استفاده قرار دهند.

باز هم دات نت

با نسخه جديد SQL Server ،برنامه نويسان بانك هاي اطلاعاتي قادرند از امكانات و قابليت هاي موجود در پلتفرم دات نت و كليه توابع و كلاس هاي ساخته شده در آن بهره مند شوند. يكي از ابتدايي ترين و در عين حال اساسي ترين اين قابليت ها،امكان استفاده از دو زبان مهم و كاربر پسند دات نت يعني ويژوال بيسيك و سي شارپ در پياده سازي اجزاي مختلف يك بانك اطلاعاتي است. اين عامل نه تنها باعث مي شود كه برنامه نويسان براي نوشتن ماژول هايي مثل تريگرها،روال ها(Stored procedures ) در توابع به جاي استفاده از زبان استاندارد و در عين حال پيچيده T-SQL ،بتوانند از زبان هاي محيط دات نت با تمام ساختارها،دستورات،كلاس ها،آرايه ها،و خلاصه تمام ويژگي هاي يك زبان شي گرا استفاده كنند،بلكه اين همكاري نزديك بين موتور برنامه نويسي دات نت يعني CLR (مسئول تبديل كدهاي نوشته شده دات نت به زبان سيستم عامل است) و موتور بانك اطلاعاتي SQL Server باعث شده تا به غير از تنوع زبان هاي برنامه نويسي قابل استفاده در SQL Server ،تغيير قابل توجهي نيز در كارآيي ماژول هاي مذكور پيش آيد. در واقع موضوع از اين قرار است كه اصولا” كدهاي نوشته شده به زبان هاي دات نت، ابتدا توسط كامپايلر به زبان (IL ) ترجمه مي شوند. سپس CLR اين كد مياني را به كد قابل فهم سيستم عامل تبديل و آماده اجرا مي نمايد. اين كار سبب مي شود تا كدهاي نهايي به دليل اين بسيار به سيستم عامل نزديك مي باشد سريع تر از كدهاي TSQL (كه فقط توسط موتور بانك اطلاعاتي قابل اجرا هستند )اجرا شوند و در زمان اجرا از كارايي بيشتري برخوردار باشند. البته اين مساله بدين معني نيست كه استفاده از زبان هاي دات نت هميشه بر زبان هاي SQL ارجحيت دارد،بلكه منظور آن است كه در برخي موارد ممكن است آن قدر منطق و الگوريتم يك ماژول پيچيده باشد كه برنامه نويس استفاده از زبان هاي دات نت را به دليل آسان تر بودن ساختار و دستورات آن به زبان SQL ترجيح دهد. بنابراين زماني كه بيشتر عمليات يك ماژول مربوط به خواندن و نوشتن اطلاعات باشد بهتر است از همان دستورات استاندارد SQL يعني DELETE,UPDATE,SELECR و INSERT استفاده كرده و بي جهت منابع سيستم را صرف تعريف متغيرها و كلاس هاي دات نت ننمايد. اما در ماژول هايي كه بيشتر عملياتشان شامل پردازش اطلاعات مثل انجام عمليات هاي رياضي يا مقا يسه اطلاعات با يكديگر است بهتر است تا هم از امكانات برنامه نويسي و هم از سرعت و كارايي بالاي دات نت در اين زمينه بهره برد و ماژول هاي مذكور را با زبان هاي دات نت پياده سازي كرد.

ADO.NET وارد مي شود

طبق يك سنت نه چندان قديمي برنامه نويسي در محيط ويندوز،برنامه نويسان SQL Server بانك اطلاعاتي مورد نظرشان را بروي سرور و برنامه كاربردي نوشته شده با زباني مثل ويژوال بيسيك را بر روي كلاينت ها قرار مي دهند. سپس از طريق اين برنامه كاربردي و با استفاده ا زاشياي از جنس ADO داده هاي مورد نياز خود را از سمت سرور دريافت كرده و يا به آن ارسال مي كنند. اكنون اين ارتباط به لطف نسخه جديد SQL Server و همچنين محيط دات نت با امكانات جديد ADO.NET بسيار كامل تر از قبل شده است. اين ارتباط جديد با استفاده از مكانيسمي به نام اعلان (Notification ) به يك ارتباط دو طرفه فعال تبديل شده به طوري كه ADD.NET قادر است پيغام هايي را از سمت پايگاه داده به سمت كلاينت ارسال كند. به عنوان مثال فرض كنيد كه شما با استفاده از ADO تعدادي از ركوردهاي يك جدول بانك اطلاعاتي را انتخاب كرده و مشغول كار بر روي آن ها هستيد. در همين هنگام كاربر ديگري از طريق كلاينت و ADO خود،ركوردي در محدوده ركوردهاي مورد انتخاب شما را تغيير مي دهد يا حذف مي كند. در اين وقت موتور پايگاه داده با ارسال پيغامي به ADO شما،اين مساله را با استفاده از فراخواني يك رخداد (Event ) شي ADO به اطلاعاتي مي رساند. علاوه بر اين قابليت جديد،فناوري جديد ديگري هم با استفاده از ADO.NET به نسخه جديد SQL.Server اضافه شده و آن امكان چند پرس و جوي همزمان توسط يك شي ADO است. در اين شيوه اگر يك شي ADO با استفاده از دستور SELECT مشغول خواندن تعدادي از ركوردهاي يك جدول بانك اطلاعاتي باشد،مي تواند بدون اين كه منتظر به پايان رسيدن اين عمليات شود،تعداد ديگري از ركوردهاي يك جدول ديگر بانك اطلاعاتي را بخواند. اين قابليت جديد با نام (MARS ) Multiple Active Result Set كه قبلا” در كرسرهاي سمت سرور (Server side ) و آن هم نه با كارايي بالا وجود داشت اكنون در كرسرهاي سمت راست كلاينت هم وجود دارد و تفاوت عمده آن با شكل قديمي هم علاوه بر مورد مذكور امكان ايجاد چند كرسر در يك شي ADO به صورت همزمان است SQL.Server . نسخه 2005 به خوبي از تمام اين ويژگي ها،پشتيباني مي كند.

تكنولوژي XML

اكنون كه XML به يك استاندارد ارتباطي بين سكوهاي مختلف تبديل شده است،نسخه جديد SQL Server هم از توجه كافي به آن و ايجاد يك انقلاب در ساده تر استفاده كردن از آن طفره نرفته است. در نسخه 2000 كاربران قادر بودند تا با استفاده از دستور FOR XML نتيجه يك پرس و جوي SELECT از يك بانك اطلاعاتي را به درون يك فايل XML را باز كرده و شروع به خواندن دستورات آن نمايند. از آن جا كه در نسخه جديد SQL Server توجه خاصي بهاين استاندارد و زبان ارتباطي شده است.يك نوع داده جديد (Date type ) به انواع داده هاي قبلي و استاندارد SQL مثل Char,int و امثال آن اضافه شده است. اين نوع داده جديد كه XML نام دارد و داراي خصوصيات يك نوع داده موجود در يك محيط شي گرا است،داراي متدهاي پيشرفته اي چون () guery ،() exist ،() value ،()nodes ،() modify بوده و قادر است انواع پردازش هاي قابل انجام بر روي اسناد XML را به راحتي انجام دهد. عمليات جستجو ،تغيير، حذف و درج مقادير مورد نظر در داخل يك فايل XML را مي توان با استفاده از متدهاي مذكور و صرفا” با چند خط برنامه نويسي انجام داد. همچنين در اين نسخه برخلاف نسخه 2000 ،با استفاده از دستور FOR XML مي توان يك شي از جنس XML را بدون ارسال آن به كلاينت،بر روي سرور ساخته و از آن نگهداري كرد. با اين كار مي توان جداولي را كه مرتبا” مورد رجوع كاربران قرار مي گيرند هر از گاهي در قالب XML به داخل حافظه آورد و كاربران مذكور به جاي رجوع به جداول اصلي در هارد ديسك،با استفاده از دستورات ويژه جستجو در XML ،متغير مذكور را در حافظه سرور مورد جستجو قرار دهند و بدين وسيله يك نوع عمل Cache كردن را جهت افزايش سرعت دسترسي به اطلاعات تكراري شبيه سازي كنند. در اين حالت،كاربران به جاي استفاده از دستور SELECT استاندارد مي توانند از OPEN XML كه در نسخه 2005 قادر است متغيرهاي جديد از نوع XML را بخواند استفاده كرده و به سرعت به اطلاعات مورد نياز خود دسترسي پيدا كنند. اين قابليت جديد آن قدر در سريع تر كردن جستجو در برنامه هاي تحت وب مهم و موثر است كه جاي هيچ مشكلي را در استفاده از آن باقي نمي گذارد.

سرويس اعلان (Notification )

همان طور كه گفتيم سيستم اعلان در SQL Server قادر است پيغام هايي را طي زمان هاي مشخص به سمت كاربران بفرستد. مثلا” تصور كنيد كه تعدادي كاربر در حال اتصال به يك بانك حاوي اطلاعات مربوط به ارزش سهام در بورس هستند. از آن جايي كه ممكن است قيمت سهام هر شركت يا موسسه براي تعدادي از كاربران از اهميت زيادي برخوردار باشد،مي توان اين سيستم را طوري تنظيم كرد تا هر گاه ارزش سهام خاصي ك مورد نظر هر كاربر است تغيير كرد،به صورت اتوماتيك به وي اعلام شود. كاربر هم مي تواند اين تغييرات را بر روي برنامه كاربردي خود،تلفن همراه(ئر قالب SMS )،Windows Messenger و يا ايميل به صورت مرتب دريافت و مشاهده كند.

سرويس گزارش گيري

سرويس جديد توليد گزارش هاي متنوع در نسخه 2005 به يكي از جالب ترين و پركاربرد ترين قابليت هاي اين نسخه تبديل شده است،وجود يك موتور گزارشگر قوي در سمت سرور و يك ابزار مناسب ساخت گزارش با واسط كاربر عالي،باعث شده تا برنامه نويسان بتوانند گزارش هاي مورد نظر خود را با كارايي و سرعت مناسب در سمت سرور بسازند به طوري كه اين گزارش هاي سمت سرور توسط هر برنامه كاربردي سمت كلانيت در هر پلتفرمي با همان امكانات اتصال به SQL Server قابل مشاهده است.

بهبودهاي ايجاد شده در زبان

در SQL Server 2005 تغييرات بسيار مثبتي در زبان SQL T ايجاد شده است. اين تغييرات در زمينه هاي مختلف مثل مديريت خطاها،جستجوهاي بازگشتي (Recursive Query ) و حتي در بدنه موتور پايگاه داده ها انجام شده و كارايي كلي ذخيره و يا خواندن اطلاعات را به نحو مطلوبي افزايش داده است. به عنوان مثال در دستورات TSQL ،دو اپراتور جديد ديده مي شود كه PIVOT و UNPIVOT نام دارند. اين دو اپراتور كه در قسمت FROM يك پرس وجو مورد استفاده قرار مي گيرند مي توانند نتيجه يك جستجوي انجام شده توسط دستور SELECT را به جاي برگرداندن در قالب رديف ها يا ركوردهاي پشت سر هم،به صورت ستون هاي مختلف يك يا چند ركورد برگردانند. در اين روش يكي از ستون هاي فيلدهاي يك جستجو به عنوان محور معرفي شده و بقيه ستون ها بر اساس آن به صورت افقي طبقه بندي مي شوند. به يك مثال توجه كنيد:


SELECT CUSTOMER ID, Order NO FROM Orders PIVOT Customer ID
Order NO Order NO Order NO Order NO Customer ID
4400 1120 25 1
350 2
1780 443 3
8989 2222 1980 555 4


نتيجه جستجوي فوق چيزي شبيه جدول بالا خواهد بود.
همان طور كه مشاهده مي كنيد با استفاده از اپراتور مذكور،نتيجه پرس و جوي انجام شده به اين صورت كه هررديف به يك شماره مشتري و جندين شماره سفارش مربوطه به آن مشتري در قالب ستون هاي مختلف است. در مي آيد. اين همان چيزي است كه سالها SQLServer آن را با نام Cross Tab به كاربران خود ارايه مي دادند. در همين رابطه اپراتور UNPIVOT هم عمل عكس اپراتور مذكور را انجام مي دهد. اپراتور ديگري كه مي تواند نقش مهمي را در دستورات SQL بازي كند APPLY نام دارد كه در قسمت FROM يك دستور SQL به كار مي رود. با استفاده از اين دستور مي توان خروجي يك تابع را با يك يا چند جدول ديگر تركيب كرد همان طور كه مي دانيد در SQL Server توابع مي توانند يك يا چند رديف جدول اطلاعاتي را برگردانند كه اين خروجي مي توانند با يك جدول ديگر با استفاده از اپراتور مذكور تركيب شود.
مديريت خطا

در نسخه هاي قديمي SQL Server براي كشف و مديريت خطا از سيستم Error Handing استفاده مي شد. اين شيوه كشف خطا كه در زباني مثل ويژوال بيسيك 6 مورد هم استفاده قرار مي گرفت با استفاده از دستور GOTO مي توانست كنترل و خط اجراي روال را از يك محل به محل ديگر و در واقع از محل بروز خطا به محل مديريت و آشكار كردن آن ببرد و بدين وسيله پيغام خطايي را به كار نشان دهد. نسخه جديد SQL Server با تاثير از پلتفرم دات نت،از دستورات ويژه كشف و مديريت خطا با عنوان Exception Handling استفاده مي كند،اين روش با استفاده از دستورات جديد TRY\CATCH شيوه بهتري از مديريت خطا را به اجرا مي گذارد. در اين روش برخلاف روش قبل،تمام خطاهاي اتفاق افتادني مثل خطاهاي مربوط به تبديل داده ها به يكديگر Data Conversion به خوبي مديريت شده و از بروز خطاهايي كه منجر به اتمام ناقص عمليات يك روال يا تريگر مي شود جلوكيري به عمل مي آيد.


منبع : sqliran

ارسال شده در مورخه : سه شنبه نهم بهمن 1386 ساعت 10:0 توسط محمد جهانشاهی |

قابليت هاي جديد T-SQL در SQL Server 2005 (قسمت دوم از سه )

در بخش قبلي اين مقاله دستورات PIVOT ، OUTPUT و TOP N را که در SQL Server 2005 آمکانات جديدي را در اختيار برنامه نويسان قرار می دهند معرفی کرديم و در اين قسمت به معرفی دستورات جديدی می پردازيم.

     

در بخش قبلی اين مقاله دستورات PIVOT ، OUTPUT و TOP N را که در SQL Server 2005 آمکانات جديدی را در اختيار برنامه نويسان قرار می دهند معرفی کرديم و در اين قسمت به معرفی دستورات جديدی می پردازيم.
اين دستورات عبارتند از :

1. Apply :
اين دستور ، کار با Table-Valued User Defined Function ها را ساده تر می کند.
2. Ranking :
اين دستور امکان اختصاص رتبه (Rank) به نتايج Query ها را فراهم می کند .
3. Try – Catch :
که امکان Error Handling در کد های SQL را فراهم می سازد.
1- Apply
اکثر برنامه نويسان پايگاه داده ، از توابع با مقدار برگشتی جدولی يا به عبارتی Table-Valued User Defined Functions که به اختصار Table Valued UDF خوانده می شوند ،استفاده می کنند. اين توابع معمولا نتيجه يک Query را به صورت يک جدول به عنوان خروجی برمی گردانند. اين توابع در جاهايی کاربرد دارند که يک Query در چند Query ديگر مورد استفاده قرار گيرد. برای چنين مواردی Function ها گزينه های مناسبی هستند و کد های نوشته شده در توابع ، بارها فراخوانی می شوند . درست مانند توابعی که در نرم افزارها به منظور Reusable بودن کد نوشته می شوند.
برای نمونه اگر در بانک اطلاعات AdventureWorks ، در SQL Server 2005 بخواهيم N سفارش اول يکی از کارکنان را برگردانيم يک UDF به صورت زير می نويسيم :
USE [AdventureWorks]
GO
/****** Object: UserDefinedFunction [dbo].[GetTopPurchaseOrders
Script Date: 03/28/2007 07:18:30 ******/
IF EXISTS (SELECT * FROM sys.objects WHERE object_id =
OBJECT_ID(N'[dbo].[GetTopPurchaseOrders]') AND type in (N'FN', N'IF',
N'TF', N'FS', N'FT'))
DROP FUNCTION [dbo].[GetTopPurchaseOrders]
set ANSI_NULLS ON
set QUOTED_IDENTIFIER ON
go

CREATE FUNCTION [dbo].[GetTopPurchaseOrders]
(@EmployeeID INT, @TopN INT)
RETURNS TABLE
AS
RETURN
SELECT TOP(@TopN) PurchaseOrderID, EmployeeID, VendorID, OrderDate
TotalDue
FROM Purchasing.PurchaseOrderHeader WHERE EmployeeID =
@EmployeeID
ORDER BY TotalDue DESC

برای اجرای اين تابع ، به فرض آنکه بخواهيم 10 سفارش اول کارمندی با شماره 164 را داشته باشيم ، به صورت زير عمل می کنيم :


SELECT * FROM [dbo].[GetTopPurchaseOrders] (164,10)

تا اينجا تمام کارها در SQL Server 2000 قابل انجام بود ( البته بجز امکان TOP N با مقدار N متغير که در قسمت قبلی همين مقاله معرفی شد) امکان جديدی که در SQL Server 2005 اضافه شده است ، دستور APPLY است که امکان کار با Table-Valued UDF ها را ساده تر می کند. به مثال زير توجه کنيد :


SELECT Emp.EmployeeID, Emp.LoginID, TopOrders.PurchaseOrderID,
TopOrders.VendorID, TopOrders.OrderDate, TopOrders.TotalDue
FROM HumanResources.Employee Emp
CROSS APPLY [dbo].[GetTopPurchaseOrders] (Emp.EmployeeID,5)
AS TopOrders
ORDER BY Emp.EmployeeID, TotalDue DESC

کاری که کد بالا انجام می دهد آنست که ID Employee ها را به عنوان ورودی به تابع تعريف شده می دهد و به ازای هر Employee ، 5 سفارش خريد را به عنوان خروجی می گيرد. عبارت CROSS APPLY در Query به ازای هر EmployeeID ، تابع مورد نظر را اجرا می کند :


CROSS APPLY [dbo].[GetTopPurchaseOrders] (Emp.EmployeeID,5)
AS TopOrders

 

2- Ranking
گاهی اوقات برنامه نويسان نياز پيدا می کنند برای هر Row از نتيجه يک Query ، رتبه يا شماره Ranking داشته باشند. تا قبل از SQL Server 2005 ، برنامه نويس مجبور بود برای اين منظور کد بنويسد و يا جدولی بايک فيلد Identity درست کند و نتيجه Query را در آن بريزد تا توسط فيلد Identity هر Row يک رتبه بگيرد. کارهايی از اين دست ممکن بود در برخی موارد پاسخگوی نياز برنامه باشد اما اگر Query کمی پيچيده می شد ، مثلا اگر می خواستيم سطر های داده را به ازای يک فيلد Group شوند و در هر Group ، عدد Ranking دوباره از 1 شروع شود ديگر اين گونه ترفند ها جواب نمی داد.
خوشبختانه SQL Server 2005 تابع جديدی به نام ()ROW_NUMBER ارائه می دهد که کار را بسيار ساده می کند.
برای درک بيشتر اين دستور ، کد مثال قبل را با استفاده از ()Row_Number بازنويسی می کنيم . اين کد باعث می شود 5 سطر داده مربوط به سفارش خريد به ازای هر کارمند يک عدد به عنوان Rank دريافت کند. و Rank هر سفارش بر اساس مبلغ آن بصورت نزولی باشد. يعنی سفارش اول با بيشترين مبلغ دارای Rank شماره 1 باشد و الی آخر.

DECLARE @nTop INT
SET @nTop = 5
SELECT Emp.EmployeeID, Emp.LoginID,
TopOrders.PurchaseOrderID, TopOrders.VendorID,
TopOrders.OrderDate, TopOrders.TotalDue,
ROW_NUMBER() OVER ( ORDER BY TotalDue DESC) AS RankNum
FROM HumanResources.Employee Emp
CROSS APPLY [dbo].[GetTopPurchaseOrders]
(Emp.EmployeeID,@nTop) AS TopOrders
ORDER BY RankNum

کار مورد نظر ما را در کد بالا ، اين قسمت از کد انجام می دهد :

ROW_NUMBER() OVER ( ORDER BY TotalDue DESC) AS RankNum

اين کد بر اساس فيلد TotalDue نتيجه Query را مرتب کرده و به هر سطر آن به ترتيب عدد Rank می دهد.
حال اگر بخواهيم عدد Ranking به جای آنکه کلی باشد ، به ازای هر کارمند Reset شود (يعنی دوباره از يک شروع شود ) ، از عبارت Partition در اين دستور ، مانند مثال زير استفاده می کنيم :


ROW_NUMBER() OVER ( PARTITION BY Emp.EmployeeID ORDER BY
TotalDue DESC) AS RankNum
.. ORDER BY Emp.EmployeeID, RankNum

که در مثال بالا ،منطقا می خواهيم ، سفارش ها به ازای هر Employee مرتب شوند .
همچنين ممکن است در برخی از مواقع بخواهيم عدد رتبه بر اساس شرايطی در داده ها مشخص شود. مثلا فرض کنيد بخواهيم برخی از سطر های داده بر اساس يک فيلد (مثلا Column 1 ) و برخی ديگر بر اساس فيلد ديگری ( مانند Column 2 ) مرتب شوند . برای اين منظور می توانيم از دستور Case همانند مثال زير استفاده کنيم :


ROW_NUMBER() OVER (ORDER BY
CASE @SortCol
WHEN 'Column1' THEN Column1
WHEN 'Column2' THEN Column2
ELSE Column1 END)
AS RankNum

 

3- Try - Catch
در SQL Server 2005 ، می توانيم با استفاده از عبارت Try-Catch ، در کد های T-SQL ، خطاهای زمان اجرا را کنترل کنيم. اين قابليتی بود که در زبان های برنامه نويسی مانند C# و VB وجود داشت و مدتها ، برنامه نويسان T-SQL در انتظار آن بودند.
با استفاده از Try-Catch، برنامه نويس می تواند خطاهای زمان اجرا را کنترل کند و آنچه را که لازم می داند به لايه Application بفرستد.
به عنوان مثال فرض کنيد می خواهيم از جدولی به نام PurchaseOrderHeader رديفی را بر اساس PurchaseOrderID آن حذف کنيم :
DELETE FROM Purchasing.PurchaseOrderHeader WHERE PurchaseOrderID =
44

اين کد ممکن است منجر به خطای Constraint Violation بين جدول PurchaseOrderHeader و جدول PurchaseOrderDetail شود. اگر ما اين کد را به عنوان يک Stored Procedure می نوشتيم و آن را در کد Net. از لايه Application فراخوانی و اجرا می کرديم عمليات در لايه Data دچار خطا می شد و بدون آنکه Error معنی داری به لايه Application برگرداند متوقف می شد.
چيزی که ما می خواهيم به دام انداختن خطا در Stored Procedure است تا خطای معنی داری را به جای آن به لايه Application برگردانيم. به کد زير توجه کنيد :


USE AdventureWorks
BEGIN
BEGIN TRANSACTION
BEGIN TRY
DELETE FROM Purchasing.PurchaseOrderHeader WHERE
PurchaseOrderID = 44
END TRY

BEGIN CATCH
DECLARE @ErrorSeverity INT, @ErrorNumber INT, @ErrorMessage
NVARCHAR(4000), @ErrorState INT
SET @ErrorSeverity = ERROR_SEVERITY()
SET @ErrorNumber = ERROR_NUMBER()
SET @ErrorMessage = ERROR_MESSAGE()
SET @ErrorState = ERROR_STATE()

IF @ErrorState = 0
SET @ErrorState = 1

RAISERROR ('ERROR OCCURED:%d', @ErrorSeverity, @ErrorState,
@ErrorNumber)
IF XACT_STATE() < 0
ROLLBACK TRANSACTION
END CATCH
COMMIT TRANSACTION
END
GO

در قسمت اول کد بالا ، ابتدا دستور DELETE را در داخل يک بلوک Try-Catch قرار داده ايم.

BEGIN TRY
DELETE FROM Purchasing.PurchaseOrderHeader WHERE
PurchaseOrderID = 44
END TRY
BEGIN CATCH
-- ereror handling routine
END CATCH

اين کار باعث می شود در صورت بروز خطا در کد موجود در بلوک Try ، کد های موجود در بلوک Catch اجرا شوند.
در داخل بلوک Catch ، پيغام خطا ، کد خطا و ساير مشخصات خطا را تعريف می کنيم :


DECLARE @ErrorSeverity INT, @ErrorNumber INT, @ErrorMessage
NVARCHAR(4000), @ErrorState INT
SET @ErrorSeverity = ERROR_SEVERITY()
SET @ErrorNumber = ERROR_NUMBER()
SET @ErrorMessage = ERROR_MESSAGE()
SET @ErrorState = ERROR_STATE()

سپس خطا را به لايه Application می فرستيم :

RAISERROR ('ERROR OCCURED:%d', @ErrorSeverity, @ErrorState,
@ErrorNumber)

دستور RAISERROR نياز به يک ErrorState دارد که برای فرستادن خطا به لايه Application مقدار آن بايد 1 باشد.

IF @ErrorState = 0
SET @ErrorState = 1
RAISERROR ('ERROR OCCURED:%d', @ErrorSeverity, @ErrorState,
@ErrorNumber)

در نهايت می خواهيم در صورتی که دستورات در داخل Transaction اجرا می شود ، Transaction مورد نظر Rollback شود . برای اين کار از دستور XACT_STATE() به منظور پيدا کردن Transaction فعال در کد استفاده می کنيم :


IF XACT_STATE() < 0
ROLLBACK TRANSACTION

در پايان به دو نکته ديگر درباره عبارت Try-Catch در SQL Server 2005 اشاره می کنيم. يکی اين که دستور Try-Catch در SQL بر خـلاف زبان های برنامه نويـسی دارای قسـمت Finally نمی باشـد و ديـگر اينـکه در کـد هـای T-SQL می توانـيـم Try-Catch های تو در تو ( Nested ) نيز داشته باشيم.


منبع : sqliran

ارسال شده در مورخه : سه شنبه نهم بهمن 1386 ساعت 9:45 توسط محمد جهانشاهی |

قابليت هاي جديد T-SQL در SQL Server 2005 (قسمت اول از سه )


يکي از کارهاي رايجي که اکثر برنامه نويسان پايگاه داده با آن برخورد مي کنند تبديل رکورد های داده خام به صورت View های آناليز شده می باشد. کاربران اغلب می خواهند بر اساس پارامتر های مختلفی نظير فصل ، سال يا ماه از داده ها گزارش بگيرند. اين گونه کارها نياز به تبديل سطر های داده (رکورد) به ستون های داده (فيلد) دارد.

     
قابليت های جديد T-SQL در SQL Server 2005 (قسمت اول از سه)

ویژگیهایی که در قسمت اول به معرفی آنها می پردازیم عبارتند از:

دراين سری مقالات قصد داريم به معرفی چند ويژگي و قابليت جديد زبان T-SQL در SQL Server 2005 بپردازيم ، که عبارتند از :

• قابليت جديد PIVOT برای تبديل سطرهای داده خام به ستونهای داده آناليز شده
• دستور جديد OUTPUT برای برگرداندن داده پس از اجرای دستورهای Insert و Update
• ارتقای دستور TOP N برای پذيرش عدد N به صورت پارامتر

1- PIVOT

يکی از کارهای رايجی که اکثر برنامه نويسان پايگاه داده با آن برخورد می کنند تبديل رکورد های داده خام به صورت View های آناليز شده می باشد. کاربران اغلب می خواهند بر اساس پارامتر های مختلفی نظير فصل ، سال يا ماه از داده ها گزارش بگيرند. اين گونه کارها نياز به تبديل سطر های داده (رکورد) به ستون های داده (فيلد) دارد. در SQL Server 2000 دو روش برای اين کار وجود داشت :
1- گرفتن داده های خام از Database و بردن آن به لايه Application و نوشتن کد (مثلا C# ، VB و ...) برای آناليز داده و رسيدن به فرمت گزارش مورد نظر.
- استفاده از دستور CASE برای قرار دادن داده در ستون مورد نظر بر اساس شرايط. برای مثال فرض کنيد يک جدول داده به نام OpenBalances (مطالبات باز) داريد که دارای ستونهايی به نامهای DueDate (تاريخ سر رسيد)و BalanceOwed (مطالبه وصول شد) می باشد و می خواهيم گزارشی بر اساس طول مدت وصول مطالبات با استانداردهای بازه زمانی مشخص مانند 1 تا 30 روز ، 31 تا 60 روز و ... داشته باشيم. برای اين منظور می توانيم کدی مانند کد زير را بنويسيم :

SELECT SUM(CASE WHEN DueDate BETWEEN @dAgingDate-
30 AND @dAgingDate
THEN BalanceOwed ELSE 0 END) AS Age30 ,
SUM(CASE WHEN DueDate BETWEEN @dAgingDate-
60 AND @dAgingDate-31
THEN BalanceOwed ELSE 0 END) AS Age60 ,
SUM(CASE WHEN DueDate BETWEEN @dAgingDate-
90 AND @dAgingDate-61
THEN BalanceOwed ELSE 0 END) AS Age90
FROM OpenBalances

با وجود آنکه هر يک از روش های فوق می توانند کار مورد نظر را انجام دهد ، SQL Server 2005 دستوری به نام PIVOT برای ساده کردن کار ارائه می دهد. به زبان ساده می توان گفت " PIVOT به برنامه نويسان اجازه می دهد که سطرهای داده (رکوردها) را به ستون های داده (فيلدها) تبديل کنند.

برای درک بيشتر کارکرد اين دستور بهتر است به دو نمونه کد که در آن از دستور جديد PIVOT استفاده شده است نگاهی بياندازيم . در مثال اول می خواهيم Order ها را از پايگاه داده Northwind Orders دريافت کنيم و گزارشی از سفارش های هر مشتری در سال 1997 بر اساس فصل بگيريم.

sp_dbcmptlevel Northwind, 90 -- necessary on older databases
USE northwind

-- Create a table variable to hold the results
DECLARE @tQtrPivotedTable TABLE (CustomerID char(25), M_Q1 Money,
M_Q2 Money, M_Q3 Money, M_Q4 Money)

INSERT INTO @tQtrPivotedTable
SELECT * FROM (SELECT CustomerID, DATEPART (q,OrderDate) as
OrderQtr, -- grab the Quarter of the month, using DateParts
(UnitPrice * Quantity) as Amount
FROM orders OH
JOIN [dbo].[Order Details] OD on OH.Orderid = OD.orderid WHERE
Year(OrderDate)=1997) AS TempOrders
PIVOT ( SUM(Amount) FOR OrderQtr In ( [1],[2],[3],[4])) As X -- Pivot
the Sum of the amount, based on the Quarter being 1 of the 4 values
SELECT * FROM @tQtrPivotedTable -- Dump out the results

کد بالا برای هر تاريخ سفارش ، فصل مربوط به آن را توسط دستور DatePart مشخص می کند و داده ها را در سطر هايی از يک جدول موقت نگهداری می کند. سپس کد فوق مجموع مبلغ سفارش ها را PIVOT می کند يعنی سطرهای آن به ستون های داده آناليز شده تبديل می کند.

PIVOT ( SUM(Amount) FOR OrderQtr In ( [1],[2],[3],[4]))

دستور فوق مقاديری که ستون OrderQtr آن ها يکی از مقادير فهرست IN باشد (1 ، 2 ،3 يا 4) را باهم Aggregate می کند و جمع ستون Amount آن ها را در يکی از چهار ستون مربوط به آن قرار می دهد.

در اين مثال اگر به فرض بخواهيم گزارش را به جای بر اساس فصل ، بر اساس ماه بگيريم بايد تغييرات زير را در کد اعمال کنيم :

تغيير ورودی DATEPART برای گرفتن ماه به جای فصل (DatePart(m به جای (DatePart(q ، تغيير ستون های PIVOT از 1 تا 4 به 1 تا 12 :

PIVOT (SUM(Amount) FOR OrderMonth In ([1],[2],[3],…,[12]) As X

بايد حتما توجه کنيم که ليست مقادير IN (پس از کلمه کليدی IN) بايد حتما مشخص و استاتيک باشد. (Hard Code شده باشد) متغيری که روی آن PIVOT می کنيم (در مثال فوق متغير OrderQtr که PIVOT را برای آن نوشته ايم) بايد يکی از مقادير ليست IN را داشته باشد.
حال به مثال ديگری توجه کنيد. فرض کنيد جدولی از صورت حساب مشتريان داريم که حاوی تاريخ صورتحساب ، مبلغ صورحساب و مبلغ پرداخت شده تا به حال می باشد و می خواهيم گزارشی از طول مدت تاخير وصول مبلغ صورتحساب بر اساس بازه های زمانی مشخص 1 تا 30 روز ، 31 تا 60 روز و 61 تا 90 روز ، 91 تا 120 روز و از 120 روز به بالا ، بدست آوريم.

DECLARE @tInvoices TABLE (CustomerID char(15), InvoiceNo Char(20), InvoiceDate
DateTime,InvoiceAmount decimal(14,2), ReceivedAmount decimal(14,2))

INSERT INTO @tInvoices VALUES ('Customer 1', 'ABC', '09-01-2005', 1000
0)
INSERT INTO @tInvoices VALUES ('Customer 1', 'DEF', '10-01-2005', 2000
100)
INSERT INTO @tInvoices VALUES ('Customer 1', 'GHI', '11-01-2005', 3000,
3000)
INSERT INTO @tInvoices VALUES ('Customer 1', 'JKL', '12-01-2005', 4000
175)
INSERT INTO @tInvoices VALUES ('Customer 1', 'MNO', '12-18-2005', 4000,
175)
INSERT INTO @tInvoices VALUES ('Customer 2', 'PQR', '05-01-2005', 500,
250)
INSERT INTO @tInvoices VALUES ('Customer 2', 'STU', '08-01-2005', 12000
0)
INSERT INTO @tInvoices VALUES ('Customer 2', 'WYX', '10-01-2005', 7000,
70)
INSERT INTO @tInvoices VALUES ('Customer 2', 'YYZ', '12-01-2005', 3200,
1750)
DECLARE @dAgingDate DATETIME
SET @dAgingDate = CAST('12-1-2005' AS DATETIME)

-- create brackets...could be configurable [1-45 days, etc.]
DECLARE @tAgingBrackets TABLE ( StartDay int, EndDay int, BracketNumber int,
BracketLabel char(20))
INSERT INTO @tAgingBrackets VALUES (0, 30, 1, '< 30 Days')
INSERT INTO @tAgingBrackets VALUES (31, 60, 2, '31-60 Days')
INSERT INTO @tAgingBrackets VALUES (61, 90, 3, '61-90 Days')
INSERT INTO @tAgingBrackets VALUES (91, 120, 4, '91-120 Days' )
INSERT INTO @tAgingBrackets VALUES (121, 999999, 5, '> 120 Days')
-- create our result set
DECLARE @tAgingDetails TABLE (CustomerID char(15), InvoiceNo char(20),
InvoiceDate DateTime,
Bracket1 decimal(14,2), Bracket2 decimal(14,2),
Bracket3 decimal(14,2), Bracket4 decimal(14,2), Bracket5 decimal(14,2))
INSERT INTO @tAgingDetails
SELECT * FROM (select CustomerID,InvoiceNo,invoicedate, InvoiceAmount-
ReceivedAmountAS AmountOwed, TBR.BracketNumber
FROM @tInvoices TI, @tAgingBrackets TBR
WHERE InvoiceAmount-ReceivedAmount <> 0 and
DATEDIFF(dd,invoicedate,@dagingdate) BETWEEN TBR.StartDay and
TBR.EndDay ) as Temp
PIVOT ( SUM(AmountOwed) FOR BracketNumber In ( [1], [2],[3],[4],[5])) As X
SELECT * FROM @tAgingBrackets
SELECT * FROM @tAgingDetails ORDER BY Custom rid, InvoiceNo
2- OUTPUT

آيا تا کنون در SQL Server 2000 خواسته ايد بلافاصله پس از اجرای دستوراتی مانند INSERT و UPDATE مقدار فيلدی که تحت تاثير دستور قرار گرفته است را بخوانيد ؟ اين مقدار می تواند مقدار يک فيلد محاسبه شده ، يک شناسه (Identity) و يا يک Default Value باشد. همچنين آيا تا کنون در دستوراتی خواسته ايد به مقدار پيش از اجرای دستور و بعد از اجرای دستور دسترسی داشته باشيد ؟ . برای اين گونه کارها ممکن بود از يک Select و يا استفاده از جدول های سيستمی INSERTED و DELETED که تنها در Trigger ها قابل دسترسی است ، استفاده کنيد.

برای مثال در SQL Server 2000 ، در صورتی که می خواستيم مقدار يک فيلد Identity را پس از اجرای دستور INSERT داشته باشيم ، اغلب از تابع SCOPE_IDENTITY استفاده می کرديم :

DECLARE @tTestTable TABLE ( MainPK [int] IDENTITY(1,1) NOT NULL, Name Char(50))
INSERT INTO @tTestTable VALUES ('steve Goff')
SELECT SCOPE_IDENTITY()

SQL Server 2005 دستوری را به نام OUTPUT ارائه می کند که به برنامه نويسان در اين گونه موارد کمک می کند. استفاده از دستور OUTPUT همراه با دستورهای INSERT و UPDATE می تواند به سادگی داده های Insert شده و Update شده را برگرداند.

به جای استفاده از SCOPE_IDENTITY می توانيم از OUTPUT استفاده کنيم :

DECLARE @tTestTable TABLE ( MainPK [int] IDENTITY(1,1) NOT NULL, Name Char(50))
INSERT @tTestTable OUTPUT Inserted.MainPK VALUES ('steve Goff')

و اگر با چند INSERT سروکار داريد و می خواهيد ليستی از مقادير INSERT شده را داشته باشيد می توانيد خروجی را در يک متغير از نوع Table نگهداری کنيد

DECLARE @tTestTable TABLE ( MainPK [int] IDENTITY(1,1) NOT NULL, Name Char(50))
DECLARE @tTemp table (mainpk int)
INSERT @tTestTable OUTPUT Inserted.MainPK into @tTemp VALUES ('Kevin Goff')
INSERT @tTestTable OUTPUT Inserted.MainPK into @tTemp VALUES ('steve Goff'
SELECT * FROM @tTemp

در صورتی که در دستور UPDATE بخواهيم به داده های قبل و بعد از اجرای دستور دسترسی داشته باشيم می توانيم از جدول های سيستمی INSERTED و DELETED برای داده های بعد و قبل از اجرای UPDATE استفاده کنيم. در مثال زير ، نحوه انجام اين کار را مشاهده می کنيم :

DECLARE @tTest TABLE ( MainPK [int] IDENTITY(1,1) NOT NULL ,Amount decimal(10,2))
INSERT INTO @tTest VALUES (100)
INSERT INTO @tTest VALUES (200)
INSERT INTO @tTest VALUES (300)

UPDATE @tTest SET Amount = Amount * 10
OUTPUT DELETED.MainPK, DELETED.Amount AS OldValue, INSERTED.Amount
NewValue

همچنين می توانيم اين خروجی را در متغيری از نوع Table قرار دهيم :

DECLARE @tTemp TABLE (MainPK int, OldValue Decimal(10,2), NewValue Decimal(10,2))
UPDATE @tTest SET Amount = Amount * 10
OUTPUT DELETED.MainPK, DELETED.Amount AS OldValue, INSERTED.Amount AS
NewValue INTO @tTemp

3- TOP N

درN ، SQL Server 2000 در دستـور SELECT TOP N تنـها می توانسـت يک عـدد ثابـت باشد (مـثلا SELECT TOP 5) .برنـامه نويسی که می خواست N رکورد اول يک Query را با استفاده از SELECT TOP N بگيرد به صورتـی که N يک مقدار متغير باشد و در زمـان اجرا (Runtime) مقدار آن مشـخـص شود ، بايـد از Query های Dynamic (که در زمان اجرای برنامه ساخـته و اجرا می شوند) و يا عبارت ROWCOUNT استفـاده می کـرد .

SQL Server 2005 ، در دستور SELECT TOP N با N به صورت يک متغير عددی رفتار می کند. به مثال زير توجه کنيد :

use northwind
DECLARE @nTop int
SET @nTop = 5
Select TOP (@nTop) customerid, oh.orderid, (unitprice * quantity) as amount
from orders OH
join [dbo].[Order Details] OD on oh.orderid = od.orderid
order by Amount Desc

چنانکه در کد بالا می بينيد مقدار N از يک متغير عددی خوانده می شود.

اين امکان را برای TOP N Percent که در آن N بر اساس درصد مشخص می شود و N درصد اول نتيجه Query را بر می گرداند ، نيز خواهيم داشت.

همچنين N می تواند خروجی يک تابع ، يک Stored Procedure و يا يک Query باشد. به مثال زير توجه کنيد :

SELECT TOP( SELECT COUNT(*) FROM SHIPPERS) * FROM ORDERS ORDER BY Freight
DESC

و در آخر بهتر است بدانيد که از دستور TOP N می توانيد در دستورات INSERT و UPDATE استفاده کنيد.

DECLARE @nTop int
SET @nTop = 2

DECLARE @tTest1 TABLE ( Amount decimal(10,2))
INSERT INTO @ttest1 VALUES ( 100)
INSERT INTO @ttest1 VALUES ( 200)
INSERT INTO @ttest1 VALUES ( 300)
UPDATE TOP(@nTop) @tTest1 SET Amount = Amount * 10
DECLARE @tTest2 TABLE ( Amount decimal(10,2))
INSERT TOP(2) @tTest2 SELECT * FROM @tTest1 order by amount
SELECT * FROM @ttest2

در کد بالا يک متغير از نوع TABLE تعريف شده و تعدادی سطر به آن اضافه شده ، سپس 2 سطر اول آن UPDATE شده است. متغير ديگری از نوع TABLE تعريف شده است و 2 سطر اول جدول قبلی در آن INSERT شده است.

در قسمت های بعدی به معرفی ساير امکانات جديد در T-SQL 2005 خواهيم پرداخت.

منبع : sqliran

ارسال شده در مورخه : سه شنبه نهم بهمن 1386 ساعت 9:44 توسط محمد جهانشاهی |

SQL Server و تکنيک هايي براي افزایش بازده بانک اطلاعاتی


استفاده از راهکارهايي چون افزایش تعداد سرورها یا ارتقای سرورهای موجود در پردازنده قدرتمندتر، حافظه بیشتر، هارددیسک های سریع تر و حتی ارتقای ارتباطات شبکه ای یا امثال آن از جمله ترفند هایی هستند که برای رفع معضل سرعت، مورداستفاده قرار می گیرند. در این مقاله به یکی از روش های توسعه طولی، نگاهی می افکنیم.

     

ممکن است پس از طی چند سال و درج هزاران رکورد در جداول یک بانک اطلاعاتی، سرعت جستجو در میان اطلاعات درج شده،سرعت درج اطلاعات جدید یا تغییر و حذف آن ها کند شود و مدیران یا برنامه نویسان این بانک ها را به ایجاد دگرگونی در برخی قسمت های بانک ناچار نماید.دو روش معمول برای مواجهه با چنین پدیده ای وجود دارد: روش اول یعنی توسعه عرضی ( Scale up ) که ترجیحا باید مقدم بر روش دوم مورد استفاده قرار گیرد، با استفاده از ساز وکار هایی مثل ایجاد انواع ایندکس ها بر روی جداول یا دید ( view )های بانک، کوتاه نمودن و کم حجم تر کردن تریگرها، به حداقل رساندن تعداد دستورات SQL که در هر فرایند وجود دارد، پرهیز از استفاده بی موقع و مکرر از توابع تعریف شده توسط کاربر و غیره می توان تا حدودی مشکل را برطرف نمود. اما در برخی موارد با تمام این تمهیدات باز هم اشکالات و وقفه هایی در سرعت و عملکرد سیستم، مدیران بانک های اطلاعاتی را ناگزیر می کند برای حل مشکل به روش دوم یعنی توسعه طولی ( Scale out ) رو بیاورند.

در این روش، استفاده از راهکارهایی چون افزایش تعداد سرورها یا ارتقای سرورهای موجود در پردازنده قدرتمندتر، حافظه بیشتر، هارددیسک های سریع تر و حتی ارتقای ارتباطات شبکه ای یا امثال آن از جمله ترفند هایی هستند که برای رفع معضل سرعت، مورداستفاده قرار می گیرند. در این مقاله به یکی از روش های توسعه طولی، نگاهی می افکنیم.

صورت مسئله

فرض کنید شما دارای یک بانک اطلاعاتی در حال کار، روی یک سرور هستید و در طول روز حدود پانصد کاربر به طور متناوب مشغول کار با این بانک هستند. کاملا آشکار است که هر چه سعی کنید با استفاده از سازوکارهای توسعه عرضی ( مثل ایندکس گذاری و امثال آن )، سرعت و کارایی سیستم را افزایش دهید، باز هم برای ارائه گزارش های مطلوب و استاندارد و حتی برای ایجاد یک محیط کارا و کاربرپسند برای استفاده از آن، مجبور می شوید برای اتفاقاتی که ممکن است در اثر ترافیک سنگین عملیات کاربران اتفاق بیفتد، فکر دیگری بکنید. یعنی حتی اگر سرور شما یک کامپیوتر قدرتمند با دو پردازنده Xeon، چهار گیگابایت حافظه و یک هارددیسک سریع باشد، باز هم قطعا در پاره ای از اوقات تصادم انبوه درخواست های موردنیاز کاربران در یک زمان، باعث بروز مسائلی چون قفل شدن برخی رکوردهای بانک (locking ) یا مسدود شدن برخی درخواست ها به دلیل عدم وجود زمان کافی برای پردازش آن ( Timeout Blocking ) می شود.

انتخاب راه حل

راه حل مسئله با استفاده از روش توسعه طولی، افزودن به تعداد سرورهایی است که به شکلی نقش پردازشگر اطلاعات را بازی می کنند. در این روش، سه راه حل مختلف وجود دارد که با اتکا به آن ها می توان تعداد سرورها، سرورهای لایه واسط (Application Server ) و سرورهای بانک اطلاعاتی (Database Server ) را افزایش داد. با این کار ترافیک و سنگینی پردازش فقط روی سرور لایه واسط یا سرور بانک اطلاعاتی کاهش می یابد و به نحوی پدیده توازن بار (Load Balancing ) چند سرور صورت می گیرد. در ادامه به بررسی هر سه راه حل مذکور می پردازیم.

راه حل یکم: کپی برداری (Cloning )

در این راه حل به سادگی می توان به جای استفاده از یک سرور لایه واسط که نقش پردازش اطلاعات را بازی می کند، از چندین سرور برای انجام دادن عمل مذکور استفاده نمود. سرورهای لایه واسط عمدتا محل فعالیت کامپوننت ها ( COM) یا وب سرورها هستند. بنابراین اگر بتوان تعداد آن ها را افزایش داد و هر دسته از کاربران را به سمت یکی از این سرورها هدایت نمود، عملکرد پردازشی سرورهای لایه واسط افزایش می یابد و در نتیجه تا حدود زیادی از بروز سرعت در سیستم جلوگیری می شود. ضمن این که اگر هر کدام از این سرورها نیز با مشکل روبه رو شوند، می توان به صورت موقت کاربران آن را به سمت یک سرور دیگر هدایت کرد و از ایجاد وقفه در کار آن ها جلوگیری نمود. ( شکل 1 )


 

شکل 1

راه حل دوم: تقسیم بندی(Partitioning )

این راه حل به دو روش تقسیم می شود:

روش یکم: افزایش سرورهای لایه واسط

در این روش نیز تعداد سرورهای لایه واسط افزایش می یابد. اما بر خلاف راه حل قبل که چند سرور کاملا مشابه، نقش یکسانی را در پردازش درخواست های کاربران ایفا می کردند، این بار هر کدام از سرورهای لایه میانی صرفا عمل خاصی را انجام می دهند که سایر سرورها از انجام دادن آن معافند. مثلا اگر قبلا تنها یک سرور، هم محل فعالیت COM ها بود و هم نقش یک وب سرور را بازی می کرد، اکنون دو وظیفه مذکور را بین دو سرور مختلف ( و شاید با ویژگی ها و توانایی های مختلف ) تقسیم می کنیم. یا به عنوان مثالی دیگر اگر تا کنون تنها یک سرور لایه میانی هم شامل COM هایی بود که با استفاده از اشیای ADO ، دسترسی به سرور پایگاه را فراهم می آوردند و هم شامل COM های دیگری که اعمال محاسباتی پیچیده را انجام می داد، اکنون می توان این دو وظیفه را بین دو سرور مختلف به ترتیب با نام هایی چون Data Access و Business Logic تقسیم کرد.
نقطه قوت این روش این است که علاوه بر تقسیم ترافیک و پردازش میان دو یا چند سرور جداگانه، امکان جداسازی کاربران بر اساس نوع استفاده آن ها از اطلاعات و فراهم ساختن سرورهایی با کاربرد مختلف جهت انجام دادن وظایف متعدد وجود دارد و در نتیجه ضریب امنیت دسترسی یا پردازش اطلاعات نیز بالاتر می رود. نقطه ضعف آن هم این است که در صورت از کار افتادن یکی از این سرورهای لایه میانی، سایر سرورهای این لایه نمی توانند به سرعت جایگزین آن شوند و وظیفه آن را به طور موقع بر عهده بگیرند. ( شکل 2 )


شکل 2

روش دوم :تقسیم سرور پایگاه داده

در این روش، به جای سرورهای لایه میانی، سرور پایگاه داده به دو یا چند سرور تقسیم می شود تا حجم فرایند ( Transaction) های داخلی و پرس و جو های همزمان روی آن سرور کاهش پیدا کند. برای استفاده از این روش، در نظر گرفتن یک نکته اساسی، بسیار مهم است. این نکته، تشخیص اشتراک یا عدم اشتراکی بودن داده ها میان کاربران مختلف است. بدین معنی که یک مدیر پایگاه داده باید بداند که آیا می توان داده ها را به چند دسته تقسیم کرد و هر دسته را روی یک سرور جداگانه برای کاربرد مختلف قرار داد یا نه. به عنوان مثال، اگر شرکتی دارای یک سیستم جامع، شامل سه زیرسیستم انبار، فروش و حسابداری باشد، می تواند جداول دیدها و ارتباطات مربوط به هر یک از این سه زیر سیستم را در یک پایگاه داده روی یک سرور جداگانه قرار دهد ت هر یکی از آن ها در دسترس مسئولان انبار، فروش و حسابداری شرکت قرار گیرد.
سوالی که در اینجا مطرح می شود این است که اگر این سه زیر سیستم با یکدیگر در ارتباط باشند، باید چه کرد؟ مثلا فرض کنید که مسئول انبار برای خروج یک کالا از انبار باید بتواند به داده هایی از جداول مربوط به سیستم فروش دست یابد. بنابراین باید در این روش، راهی وجود داشته باشد تا در عین جدا بودن اطلاعات مذکور از یکدیگر، امکان استفاده کاربران مختلف از یکی از آن ها یا تلفیقی از آن ها نیز فراهم گردد.
در SQL Server نسخه 2000 برای این کار امکاناتی پیش بینی شده است. به عنوان مثال، شما با استفاده از قابلیت Linked server قادر خواهید بود یک بانک اطلاعاتی مقیم در یک سرور دیگر را طوری به یک بانک اطلاعاتی سرورتان پیوند بزنید که گویی هر دو در یک سرور قرار دارند.پس از این کار حتی می توانید پرس و جوهایی انجام دهید که از لینک کردن چند جدول و یا دید از هر دو بانک اطلاعاتی حاصل شود. به این قابلیت، جستجوی توزیع شده یعنی Distributed Query گفته می شود.
علاوه بر این خاصیت دیگری در این نسخه تعبیه شده است که امکان انجام دادن یک فرایند واحد روی چند بانک اطلاعاتی موجود در چند سرور مختلف را فراهم می کند(Distributed Transaction ). این قابلیت ها به گونه ای است که حتی امکان تعریف روابط وابستگی از طریق کلیدهای اولیه و کلید های خارجی میان بانک های مذکور نیز وجود دارد و یا مثلا ساخت یک دید با استفاده از لینک کردن جداول موجود در چند سرور نیز میسر گشته که به آن Distributed Portioned View گفته می شود.
به هر حال، بسیاری از راه حل های مربوط به "توزیع" در SQL Server برای استفاده همزمان از قدرت و قابلیت چندین سرور در نظر گرفته شده است. درشکل سه مثالی را مشاهده می کنید که در آن به صورت بسیار ساده جدول مشتریان یک شرکت به دلیل زیاد بودن و قابل جدا کردن اطلاعات آن، به سه دسته مشتریان شرق، غرب و مرکز کشور تقسیم بندی شده و هر کدام در عین ارتباط با یکدیگر و با کاربران، بر روی یک سرور مجزا قرار گرفته اند .(شکل 3 )


شکل 3

راه حل سوم: Replication

این راه حل نیز مشابه روش دوم Partitioning است. اما بر خلاف آن روش که سرور بانک اطلاعاتی را به چند سرور حاوی اطلاعات مختلف مورد نیازشان تقسیم می کردیم، در اینجا چند سرور بانک اطلاعاتی با استفاده از سازوکار Replication دقیقا شامل اطلاعات یکسان و همانند می باشند.
به عنوان مثال فرض کنید در یک شرکت بزرگ که دارای سه واحد اصلی فروش، انبار و حسابداری است، سه سرور بانک اطلاعاتی کاملا یکسان در نظر گرفته شده که هر یک از واحد ها داده های موردنیازشان را از جداول مربوط به خودشان از سروری که به آن ها اختصاص یافته دریافت می کنند و هر گاه تغییری را در آن اطلاعات به وجود آوردند، یا در همان لحظه باید در کلیه سرورهای دیگر نیز اعمال شود و یا طبق یک برنامه زمانبندی شده، در زمان دیگری مثلا در ساعات غیر اداری ک میزان ترافیک اطلاعات کاهش می یابد، به دیگر سرورها منتقل شود.اگر بخواهیم تغییر اطلاعات در همان لحظه به دیگر سرورها اعمال شود، می توان از Replication نوع فرایندی (Transactional) استفاده کرد.
در این روش با استفاده از قابلیتی به نام تغییر دو مرحله ای اطلاعات یا اصطلاحا Two Phase Commit هر تغییری بلافاصله در سایر سرورها نیز لزوما اعمال می شود. اما اگر بخواهیم تغییرات در زمان خاصی و به تعداد معمولی ( مثلا دو یا سه بار طی شبانه روز ) به سرورهای دیگر منتقل شود، می توان از Replication نوع ادغام استفاده کرد .(شکل 4)
بنابراین در این حالت هر سرور ضمن داشتن آخرین اطلاعات مربوط به واحد خود، آخرین اطلاعات رسیده از سایر سرورها (یا واحدهای دیگر) را نیز دارد.
لازم به ذکر است که عملیات انتقال اطلاعات با استفاده از Replication نکات و مسائل فنی فراوانی دارد که به تنهائی در قالب چند مقاله قابل بررسی است.


شکل 4


منبع : sqliran

ارسال شده در مورخه : سه شنبه نهم بهمن 1386 ساعت 9:37 توسط محمد جهانشاهی |

جداول موقت و متغيرهاي جدولی


يکي از مسائلی که همواره پیش روی یک طراح یا برنامه نویس بانک های اطلاعاتی قرار دارد ، استفاده یا عدم استفاده از جداول موقت در زمان نیاز است . جداول موقت ، جداولی هستند که به فراخور نیاز در برخی روال های ذخیره شده یا تریگرها برای انجام پردازش بر روی اطلاعات مورد استفاده قرار میگیرند . هرچند استفاده از هر نوع جدول موقت به دلیل کند بودن پردازشگر فیزیکی اطلاعات بر روی آن ها چندان توصیه نمی شود، اما مواردی پیش می آید که آن ها را تبدیل به تنها راه یا بهترین راه پردازشگر اطلاعات خاص می کند.

     

یکی از مسائلی که همواره پیش روی یک طراح یا برنامه نویس بانک های اطلاعاتی قرار دارد ، استفاده یا عدم استفاده از جداول موقت در زمان نیاز است . جداول موقت ، جداولی هستند که به فراخور نیاز در برخی روال های ذخیره شده یا تریگرها برای انجام پردازش بر روی اطلاعات مورد استفاده قرار میگیرند . هرچند استفاده از هر نوع جدول موقت به دلیل کند بودن پردازشگر فیزیکی اطلاعات بر روی آن ها چندان توصیه نمی شود، اما مواردی پیش می آید که آن ها را تبدیل به تنها راه یا بهترین راه پردازشگر اطلاعات خاص می کند. مثلا فرض کنید در یک سیستم پرداخت حقوق و دستمزد کارمندان یک شرکت ، ابتدا حقوق پایه آن ها در یک جدول موقت قرار گرفته ، آنگاه برنامه پردازش حقوق ، فاکتورهای مختلف و موءثر بر حقوق چون مالیات ،بیمه ، اقساط وام و .. را به تدریج و بر حسب اولویت بر آن اعمال کرده و مقادیر آن ها را تغییر می دهد . آنگاه مقادیر نهایی از این جدول موقت به جدول اصلی حقوق به عنوان رقم نهایی حقوق کارمندان کپی شده و سپس جدول موقت برای استفاد بعدی سیستم ، به کلی از سیستم پاک می شود . دستور ساخت یک جدول موقت به شکل زیر است :

(…)create table #T

اولین سوالی که ممکن است در این زمینه جا مطرح شود ،این است که چرا اساسا با وجود جدول اصلی حقوق ، پردازش ها باید در یک جدول موقت انجام شود . در جواب می توان به دو دلیل عمده در این رابطه اشاره کرد :
اول این که ممکن است به دلایلی ، عملیات پردازش حقوق در میان راه با مشکل مواجه شده و از ادامه کار بازبماند . بدین ترتیب در صورت عدم استفاده از جدول موقت ، احتمال باقی ماندن رکوردهای حاصل از پردازش ناقص در جدول اصلی حقوق کارمندان بسیار زیاد خواهد بود .

دوم این که در صورت استفاده از جدول اصلی برای پردازش اطلاعات ، ممکن است کاربران دیگر نیز در همان زمان به این جدول رجوع کنند . در این صورت نیز دو مشکل دیگر در شرف امکان قرار خواهند گرفت . اولا در حالی که یک کاربر مشغول عملیات درج و تغییر در این جدول است ، کاربر دیگر در حال خواندن اطلاعات از آن است . این مساله ممکن است به کلیه پیامدهای ناشی از همزمانی و تداخل کاربران در یکدیگر مثل پدیده Locking بیانجامد . دوما این که در صورتی که یکی از کاربران دیگر در همان زمان مشغول گرفتن گزارشاتی از وضعیت حقوق کارمندان باشد ، احتمال خوانده شدن رکوردهای ناقص و یا اطلاعات باقی مانده از یک فرآیند نا موفق (Dirty read) و درنتیجه تولید یک گزارش اشتباه نیز بسیار محتمل است .

بنابراین در این گونه موارد ، جداول موقت تنها به عنوان یکی از راه حل های قابل انتخاب توسط برنامه نویسان می تواند راه گشای آنان در این زمینه باشد . چراکه کافیست مقادیر یک جدول موقت پس از حصول اطمینان از صحیح بودن اطلاعات آن ، طی یک فرآیند کوچک و با استفاده از دستوری چون

 
INSERT INTO MAIN_T SELECT * FROM TEMP_T

به یکباره وارد جدول اصلی شود .

اما استفاده از جداول موقت تنها یکی از روش های پردازش اطلاعات است و نکته مهمی که قبل از شروع به کار با این روش باید درنظر گرفته شود ، نقاط قوت و ضعف آن در مقایسه با روش های دیگر است . یکی از روش های کمتر شناخته شده اما مفید برای پردازش اطلاعات ، متغیر جدول یا همان Table Variable است . متغیر جدول در واقع بیشتر امکانات یک جدول بانک اطلاعاتی را در اختیار برنامه نویس قرار می دهد و وی را قادر می سازد تا همانند یک جدول معمولی به درج ، حذف و تغییر اطلاعات در آن بپردازد . در Sqlserver و بسیاری از بانک های اطلاعاتی دیگر ،از این نوع داده (data type) به عنوان جایگزینی مناسب برای جداول موقت استفاده می گردد . دستور تعریف یک متغییر جدول به شکل زیر است :

(…)declare @T table

اما قبل از استفاده از هرکدام از این دو روش باید نقاط برتری هر یک را در مقایسه با دیگری مورد بررسی قرار داد .

1- محل ساختن و قرار گرفتن یک جدول موقت ، در پایگاه TempDB است در حالیکه متغییر جدول همانند هر متغیر دیگری ، در حافظه سیستم قرار میگیرد ؛ همچنین محاسبات انجام گرفته بر روی یک متغیر جدول ، در سیستم لاگ نمی شود . بنابراین این متغیر از قوانین مربوط به فرآیندها (Transaction) معاف است . مثال زیر گویای این مساله است . همانطور که مشاهده می کنید ، برگشت فرآیند با استفاده از دستور Rollback هیچ تاثیری بر تغییر رکورد درج شده در متغییر جدول ندارد اما باعث برگشت مقدار تغییر یافته در جدول موقت شده است

create table #T (s varchar(128))
declare @T table (s varchar(128))
insert into #T select 'old value #'
insert into @T select 'old value @'
begin transaction
update #T set s='new value #'
update @T set s='new value @'
rollback transaction
select * from #T
select * from @T

s
---------------
old value #
s
---------------
new value @

بنابراین واضح است که به دلیل لاگ نشدن عملیات روی یک متغییر جدول و همچنین قرار گرفتن آن در حافظه اصلی سیستم ، سرعت کار با آن نیز در مقایسه با جدول موقت بیشتر است .

2- متغیر جدول فقط در حوزه کاری جاری (Scope ) قابل دسترسی است بنابراین امکان استفاده از آن در داخل یک روال یا تریگر دیگر وجود ندارد . این مشکل در مورد جداول موقت وجود ندارد چراکه این جداول ماهیتی فیزیکی در داخل بانک Tempdb داشته و توسط کاربر سازنده آن از هر نقطه ای قابل دسترس می باشند . اما در عوض یک متغییر جدول پس از اتمام پردازش حوزه تعریفش ، به طور اتوماتیک از حافظ خارج می شود و کاربر را از هرگونه اشتباهی در استفاده مجدد از آن دور می دارد در صورتیکه جداول موقت به همراه آخرین اطلاعاتشان ، تا زمان اتصال کاربر به بانک اطلاعاتی در سیستم باقی می مانند .

3- ساختار یک جدول موقت با استفاده از دستور ALTER قابل تغییر است در صورتیکه یک متغییر جدول پس از تعریف ، قابل تغییر نیست . همچنین متغیر جدول فقط میتواند دارای کلید (Primary key) باشد اما امکان گذاشتن ایندکس های غیر خوشه ای (Nonclustered index) بر روی آن وجود ندارد . بنابراین اگر قصد جستجو های آتی متنوع و فراوان در اطلاعات موقتتان دارید ، بهتر است از جدول موقت استفاده کنید .

بنابراین با توجه به این موارد ، استفاده و انتخاب بین جداول موقت و متغیرهای جدولی ، بستگی به شرایط طراحی بانک و هدف برنامه نویس دارد و نمی توان از پیش ، استفاده از یکی را فارغ از درنظر گرفتن کلیه شرایط موجود ، به برنامه نویسان توصیه نمود .


منبع : sqliran

ارسال شده در مورخه : سه شنبه نهم بهمن 1386 ساعت 9:36 توسط محمد جهانشاهی |

نگاهي به قابليت هاي جديد SQL Server 2005 – مبحث مدیریت خطا


در SQL Server 2000 ، خطا و مسائل مربوط به آن را مي توان به طور کلي به دو دسته تقسيم کرد: يک دسته از آن ها در زمان فراخواني و اجراي يک دستور T-SQL به صورت اشتباه بروز مي کنند. نوع دوم خطاها در SQL Server 2000 ، خطاهای قابل پیش بینی و در واقع آن دسته از خطاهایی هستند که نه مربوط به مشکل استفاده نادرست از دستورات T-SQL است و نه پاس شدن اشتباه پارامتر به بانک اطلاعاتی.

     


کشف خطاها (Error Detection ) و نحوه مقابله و تعامل با آن ، همواره یکی از حساس ترین مراحل برنامه نویسی در زمان ساخت نرم افزار بوده و هست. نرم افزاری که فاقد راهکارهای لازم جهت پیش بینی ، تشخیص و مواجهه با خطاهای احتمالی در سیستم باشد، هم کاربر و هم سیستم را دچار اشتباه و مشکل می نماید و ممکن است در برخی مواقع باعث ثبت و تغییر ناخواسته اطلاعات شود. بخصوص در زبان های برنامه نویسی یا بانک های اطلاعاتی این امر از اهمیت ویژه ای برخوردار است. البته در زبان های برنامه نویسی معمولا بروز یک خطا به راحتی آشکار می گردد و کاربر در همان لحظه، متوجه اشکال در عملات یا ثبت اطلاعات می شود، اما در بانک های اطلاعاتی که در بسیاری مواقع به صورت دسته ای ( Batch ) و در قالب یک یا چند فرآیند (Transaction ) در سیستم انجام می شود، کشف خطا و راه حل آن ، پیچیده تر و حساس تر است.  

در SQL Server 2000 ، خطا و مسائل مربوط به آن را می توان به طور کلی به دو دسته تقسیم کرد: یک دسته از آن ها در زمان فراخوانی و اجرای یک دستور T-SQL به صورت اشتباه بروز می کنند. به عنوان مثال، فرض کنید که در یکی از روال های ذخیره شده یا تریگرها، دستوری نوشته اید که یک عدد بزرگ را به یک متغیر یا فیلد کوچک مثل Small int نسبت می دهد. این عمل باعث می شود بانک اطلاعاتی یک خطای غیر منتظره را کشف نماید و با آشکار کردن آن، از ادامه اجرای دستورالعمل های بعدی اجتناب کند و به طور کلی تمام دستورالعمل های موجود در آن فرآیند به طور خودکار ملغی شود ( Auto RollBack ) . این گونه خطاها را باید حتی الامکان در سطح برنامه های دسکتاپ کاربر (Application ) کنترل نمود و در واقع از اشتباه کاربر در پاس کردن پارامترهای غیر مجاز به سطح بانک اطلاعاتی، جلوگیری کرد.حتی در صورت وقوع چنین امری، باز هم نباید گذاشت بانک اطلاعاتی بدون کنترل کردن پارامتر های دریافتی، اقدام به استفاده از آن ها نماید تا سیستم را دچار بروز خطای غیر قابل پیش بینی کند. به عنوان مثال، در مورد استفاده از اعداد بزرگ در متغیر های کوچک می توان این کنترل که عدد مذکور تا دامنه خاصی قرار گرفته است یا نه را به سادگی توسط یک دستور IF و مقایسه مناسب ، قبل از اجرای دستور العمل مربوطه انجام داد.


Declare @Var2 smallint
IF @Var<32767
Begin
(Select @Var2=@Var ) اجرای دستورالعمل
End

البته همان طور که حتما متوجه شده اید، انجام داد چنین کنترل هایی در سطح بانک اطلاعاتی کاری بسیار مشکل است که ممکن است تعداد خطوط برنامه نویسی در یک بانک را بی جهت تا حد زیادی افزایش دهد. در SQL Server 2005 راهی برای کنترل این نوع خطاهای غیر قابل پیش بینی اندیشیده شده است که به آن خواهیم پرداخت.

نوع دوم خطاها در SQL Server 2000 ، خطاهای قابل پیش بینی و در واقع آن دسته از خطاهایی هستند که نه مربوط به مشکل استفاده نادرست از دستورات T-SQL است و نه پاس شدن اشتباه پارامتر به بانک اطلاعاتی. کنترل این گونه خطاها را طراح و برنامه نویس برای جلوگیری از ورود، تغییر یا حذف اطلاعات حساس در سیستم ، به صورت عمدی در روال ها یا تریگر ها قرار می دهد تا از اشتباه کاربر با اطلاعات حساس جلوگیری کند. به عنوان مثال، فرض کنید در یک برنامه حسابداری، حذف سند تایید شده ( سندی که فیلد stt آن برابر یک باشد ) غیر محاز است. بنابراین، برنامه نویس می تواند با اضافه کردن خطوط زیر به تریگر مربوط به حذف رکورد از جدول اسناد، یک نوع خطای کنترل شده را آشکار نماید و از ادامه کار توسط کاربر جلوگیری کند.

Select @stt=stt from Deleted
If @stt=1
Begin

(1 , 16 و " سند تایید شده قابل حذف نمی باشد " ) raiserror
Return
End

همان گونه که مشاهده می کنید، در این جا از دستور العمل raiserror استفاده شده است که برای آشکار کردن اشتباه کاربر در حذف اطلاعات و برگرداندن یک پیغام اخطار به کاربر را مشخص می کند. دومین پارامتر severity است. اگر این عدد برابر شانزده باشد، به معنی این است که ضمن نمایش پیغام خطا، تمام اعمال انجام شده توسط کاربر در این فرآیند به صورت خودکار ملغی می شود. اما اگر بین یازده تا پانزده باشد، صرفا یک پیغام خطا به کاربر نشان داده می شود، ولی عملیات موردنظر وی انجام می شود ( از این حالت، بیشتر برای نمایش پیغام های جانبی و نه پیغام های بروز خطا استفاده می شود، چرا که عملیات موردنظر کاربر ملغی نمی شود ) و اگر این پارامتر برابر ده یا کمتر باشد ، هیچ پیغامی به کاربر نمایش داده نمی شود و همچنین عملیات موردنظر وی ( فرآیند جاری ) انجام می شد و ملغی نمی گردد.

همانگونه که متوجه شده اید ، دستور العمل raiserror کاربردهای متفاوتی دارد که لزوما به معنای ملغی کردن فرآیند کاربر نیست. اما علاوه بر دستورالعمل فوق ، در ASQL Server 2000 یک متغیر محیطی ( Enviromental Varialble ) وجود دارد که موتور بانک اطلاعاتی وظیفه کنترل و مقدار دهی آن را در زمان های بروز خطا، به عهده دارد و می تواند خطاهای ناخواسته و کنترل نشده را که قبلا با استفاده از دستور If مشخص می کردیم، به نحو ساده تری آشکار کند. این متغیر که با عبارت @@Error شناخته می شود، بلافاصله بعد از بروز هر گونه خظای ناخواسته مثل خطای حاصل از تقسیم بر صفر ، به صورت خودکار مقدار دهی می شود و برنامه نویس بانک اطلاعاتی می تواند بعد از انجام دادن هر دستور العملی که شکی در انجام گرفتن درست آن وجود دارد، با بررسی مقدار موجود در این متغیر محیطی، خطای احتمالی را آشکار نماید. به عنوان مثال ، اگر بخواهیم بدون استفاده از دستور If برای کنترل پیش از مقداردهی یک عدد بزرگ به یک متغیر smallint ، خطای احتمالی ناشی از آن را کنترل کنیم، می توانیم به جای روش قبل از تکه کد زیر استفاده نماییم:

Declare @Var2 smallint
Select @Var2=@Var
If @@error=220
Begin 
(1 , 16 و " عدد بزرگ تر از 32767 مجاز نیست " ) raiserror
End

البته همانگونه که در شکل 1 نتیجه حاصل از اجرای چنین کدی را مشاهده می کنید، حتی در صورت عدم استفاده از دستور raiserror نیز، برنامه به طور خودکار پیغام خطایی را به کاربر نمایش خواهد داد. اما نمایش یک پیغام فارسی ساده و گویا، مناسب تر از نمایش پیغام سیستمی OverFlow برای کاربران است. در هر صورت با این روش کلیه عملیات موجود در آن فرآیند، تریگر یا روال ملغی می شود.
پس از ارائه نسخه جدید SQL Server در سال 2005 برنامه نویسان بانک های اطلاعاتی با واژه جدیدی رو در رو گشتند که از برخی زبان های برنامه نویسی مایکروسافت مثل ویژوال سی یا سایر زبان های دات نت مثل ویژوال بیسیک و سی شارپ اقتباس شده بود.


شکل 1


در واقع مایکروسافت در راه نزدیک تر کردن هر چه بیشتر محیط های توسعه دات نت با یانک اطلاعاتی خود، علاوه بر افزودن امکانات کار با XML و CLR در موتور SQL Server 2005 ( که در شماره پیشین مورد بررسی قرار گرفت ) برخی ساختار های برنامه نویسی را نیز به این بانک اطلاعاتی اضافه کرد که یکی از مهم ترین آن ها ساختار موسوم به TRY-CATCH است که برای کشف خطا در برنامه ها کاربرد بسیاری دارد و همان گونه که از نام آن برمی آید، این ساختار شامل دو قسمت است: یکی برای دربرگرفتن آن دسته از دستورات T-SQL که احتمال بروز خطا در زمان اجرای آن ها وجود دارد و دیگری، برای آشکار کردن خطای مذکور. بدیهی است که در قسمت دوم یعنی بلاک CATCH ، باید از دستوری چون raiserror یا متغیری مثل Error@@ استفاده کرد تا همانند قبل بتوان پیغام مناسب را به کاربر نمایش داد.
به عنوان مثال تکه کد زیر، انتساب مقدار بزرگتر از حد برای متغیر Var2@ را کنترل می کند و در صورت بروز آن، پیغام متناسب کاربر را به وی نمایش می دهد.

Begin TRY
Select @Var2=@Var
End TRY
Begin CATCH
If @@Error=220
Begin
(1 , 16 و " عدد بزرگتر از 32767 مجاز نیست " ) raiserror
End

همانطور که مشاهده می کنید، در این جا نیز برای مشخص نمودن نوع خطا از متغیر محیطی Error@@ و برای نمایش پیغام به کاربر از تابع raiserror استفاده شده است. دو نکته مهمی که در زمان استفاده از ساختار TYR- CATCH باید مورد توجه قرار گیرند این است که اولا، بین دو بلاک TRY و CATCH هیچ دستور SQL نباید وجود داشته باشد. در ثانی، هر کدام از دو بلاک مذکور فقط شامل یک دستور SQL باشند.
اما تغییرات ایجاد شده در مدیریت خطا در نسخه 2005 فقط به ساختار مذکور محدود نمی شود، بلکه در این نسخه توابعی گنجانده شده است تا به شکلی نقطه ضعف استفاده از متغیر محیطی Error@@ را برطرف نماید. توابع مذکور قادرند برخلاف این متغیر محیطی که فقط بیانگر شماره خطا است، اطلاعات دیگری را نیز در اختیار برنامه نویس یا کاربر قرار دهند. به عنوان مثال، اگر بخواهیم به جای استفاده از متغیر مذکور در قطعه کد قبل، از یکی از این توابع برای نمایش پیغام خطا استفاده کنیم، به جای بلاک CATCH قبل خواهیم داشت:

Begin CATCH
Raiserror (ERROR_MESSAGE(),16,1)
End CATCH

شکل 2


همان گونه که مشاهده می کنید، تابع ERROR_MESSAGE متن پیغام خطای سیستم را مستقیما به raiserror می دهد تا در صفحه نمایان شود. جدول زیر فهرستی از این توابع و کاربرد آن ها را نشان می دهد.


شماره خطی از روال یا تریگر که این خطا رخ داده است. ERROR_LINE
پیغام سیستمی متناسب با خطای مذکور که در جدول سیستمی SysMessages قرار گرفته است. ERROR_MESSAGE
شماره خطا و مقدار  @@ERROR ERROR_Number
شماره روال یا تریگری که این خطا در آن رخ داده است. ERROR_Procedure

منبع : sqliran

ارسال شده در مورخه : سه شنبه نهم بهمن 1386 ساعت 9:35 توسط محمد جهانشاهی |

10 عملي که يک DBA نبايد هرگز انجام دهد

بر عهده داشتن وظيفه راهبري پايگاه داده، حتي در محیط های برنامه نویسی، همیشه خطیر بوده و از اهمیت بسیار بالایی برخوردار است، به طوری که حتی اشتباهاتی کوچک از جانب یک DBA می تواند موجب بروز اشکالاتی در عملکرد کلی سیستم ها گردد. اگر قصد دارید به عنوان یک DBA مشغول به کار شوید، پس در نظر گرفتن موارد زیر در سمت کاری آینده شما بسیار تاثیر گذار است. در صورتی هم که در حال حاضر در این سمت مشغول به کار می باشید، باز هم این امکان وجود دارد که تا به حال به بعضی از موارد زیر توجه نکرده باشید.

     

با تجربیاتی که در مدت هفت سال کار با SQL Server کسب کرده ام، ده موردی که در این مقاله ذکر می کنم ، کارهایی هستند که احساس می کنم یک راهبر پایگاه داده (DBA ) نباید هرگز انجام دهد.
بر عهده داشتن وظیفه راهبری پایگاه داده، حتی در محیط های برنامه نویسی، همیشه خطیر بوده و از اهمیت بسیار بالایی برخوردار است، به طوری که حتی اشتباهاتی کوچک از جانب یک DBA می تواند موجب بروز اشکالاتی در عملکرد کلی سیستم ها گردد. اگر قصد دارید به عنوان یک DBA مشغول به کار شوید، پس در نظر گرفتن موارد زیر در سمت کاری آینده شما بسیار تاثیر گذار است. در صورتی هم که در حال حاضر در این سمت مشغول به کار می باشید، باز هم این امکان وجود دارد که تا به حال به بعضی از موارد زیر توجه نکرده باشید:

1. Rebuild کردن Index در ساعات کاری

این عمل موجب افزایش چشم گیر I/O دیسک می شود. بهتر است این عمل بعدازظهر یا در طول شب ( زمانی که فعالیت کاربران به حداقل می رسد ) انجام شود.لازم به ذکر است که می توانید از سرویس Agent job جهت برنامه ریزی انجام خودکار این عملیات استفاده کنید.

2. Stop کردن Database بدون اطلاع رسانی قبلی

چرا؟!... تعداد زیادی کاربر که نمی توانند با برنامه خود کار کنند ... تلفن شما هم تا زمان راه اندازی مجدد Database از زنگ زدن دست بر نمی دارد.

3. نصب Service Pack در ساعات کاری

نصب سرویس پک، موجب Stop و Start های متعدد پایگاه داده می شود. توصیه می کنم این کار را نیز در ساعات کاری شرکت یا سازمان خود انجام ندهید. چون با این کار کاربران بسیاری را دلخور می کنید.

4. اجرای Query های تستی بر روی سرور اصلی

اگر این کار را انجام می دهید پس حتما نمی دانید که این Query ها به چه میزان منابع Server را به خود اختصاص می دهند.

5. Defragment کردن درایوهایی که فایل های دیتابیس روی آن قرار دارند

آیا تا به حال این کار را روی کامپیوتر شخصی خود انجام داده اید؟! پس حتما متوجه اید که چرا نباید این کار را روی سرور شرکت یا سازمان خود در ساعات کاری انجام دهید!!

6. بداخلاقی با برنامه نویسان

سعی کنید منطق دستورات خود را به آن ها توضیح دهید. بهتر است همیشه صبور باشید و تلاش کنید در حین ارجاع کار به آن ها دانش خود را نیز به آن ها منتقل کنید. نتیجه کار مستقیما به کار گروهی شما بستگی دارد.

7. پشتیبان گیری در ساعات کاری

این موضوع هم به I/O دیسک سرور مربوط می شود. اگر مجبور هستید این کار را در طول روز و در ساعات کاری انجام دهید، پس به گزینه هایی مانند differential Backups یا Transactional log Backups توجه کنید، این نوع پشتیبان گیری ها بسیار سریعتر صورت می پذیرد.

8. نصب Update های نرم افزاری قبل از تست و پشتیبان گیری

ممکن است نرم افزار های جانبی بر روی سرور پایگاه داده شما نصب شده باشد. نصب نرم افزار و یا نصب Update های نرم افزاری حتما باید با توجه ویژه و تست قبلی صورت پذیرد. تولید کنندگان نرم افزار ممکن است نتوانند صحت عمکرد نرم افزار خود را بر روی سخت افزار و شرایط مختلف بررسی کنند. قبل از اعمال هر تغییری در نرم افزارهای سرور از دیتابیس خود Backup بگیرید.

9. ایمن نکردن SQL Server

غالبا DBA ها فکر می کنند که سرورهایشان از امنیت بالایی برخوردار است!! آیا شما هم این طور فکر می کنید؟!
بهتر است برنامه Microsoft Baseline Security Analyzer را بر روی سرور خود اجرا کنید. شاید از مشاهده نتیجه آن تعجب کنید.

10. اجرای دستور Drop قبل از اطمینان کامل

قبل از اینکه دکمه Enter را فشار دهید خوب فکر کنید، اجرای این دستور با سهل انگاری ممکن است موجب اخراج بلادرنگ شما شود!

منبع : sqliran

ارسال شده در مورخه : سه شنبه نهم بهمن 1386 ساعت 9:34 توسط محمد جهانشاهی |

10 دليل قانع کننده استفاده از SQL Server 2005


از آنجائي که نسخه SQL Server 2005 داراي قابلیت ها و ویژگی های نوین و کاملتری نسبت به نسخه ها قدیمی مانند SQL Server 2000 می باشد ، و با توجه به اینکه متاسفانه در حال حاضر استفاده از این نسخه در کشور ما ایران بسیار کم رنگ تر از نسخه های قدیمی می باشد ، در این مقاله 10 دلیل اصلی را که شما را ترغیب به ترفیع به SQL Server 2005 می کند ، را به شکلی فهرست وار توضیح می دهم.

     

در حال حاضر بسیاری از سازمان ها و شرکت ها از نسخه SQL Server 2000 استفاده می کنند. زمانی که شرکت Microsoft نسخه SQL Server 2005 را ارائه داد، بسیاری از مدیران IT و راهبران پایگاه داده با این سوال مواجه شدند: آیا لازم است ورژن SQL Server خود را upgrade کنیم ؟!

مسلما پیشرفت هایی که در نسخه SQL Server 2005 به چشم می خورد به قدری حائز اهمیت می باشند که شما به عنوان یک IT Manager یا DBA در صورت شناخت، خود را موظف به این امر خواهید دانست .

1. هر برنامه کاربردی که در حال حاضر کار می کند، بدون هیچ تغییری با SQL Server 2005 نیز کار خواهد کرد

ابزار SQL Server 2005 Management Studio جایگزین ابزار Enterprise Manager خواهد شد. اما شما با این ابزار جدید نیز قادر به مدیریت پایگاه های داده SQL Server 2000 نیز خواهید بود. البته از این ابزار جهت مدیریت SQL Server 6.5 و SQL Server 7.0 نمی توان استفاده نمود .
برنامه های کاربردی و سایت های شرکت یا سازمان شما بدون نیاز به انجام هیچ گونه تغییری به فعالیت ادامه خواهد داد. وجود این سازگاری بسیار مهم است. به اهمیت آن بیشتر فکر کنید.

2. SQL Server 2005 دارای ابزار های بیشتری می باشد

در نسخه های قدیمی SQL Server اجزا گوناگون مانند Analysis Services در بسته های نرم افزاری مختلفی قرار گرفته بود. اما در نسخه SQL Server 2005 شرکت مایکروسافت رویکرد بازاریابی خود را تغییر داده و تمامی اجزا را در یک بسته قرار داده است.
همان طور که در مقاله
آموزش نصب SQL Server 2005 توضیح داده ام، شما می توانید سرویس ها و اجزا مختلف را هنگام نصب انتخاب کنید.

3. دسترسی آسان و یکپارچه به همه اجزا

SQL Server Management Studio یا SSMS به شما این امکان را می دهد که خیلی ساده و واضح به همه اجزا مانند Data Transformation Services ( DTS ) ، profiler ، Reporting Services ، Tuning Advisor و حتی SQL Server Integration SSIS )Services ) و  OLAP ) Online Analytical Processing )  دسترسی داشته باشید.
این یکپارچگی موجب افزایش کارایی و هزینه کمتر آموزش می گردد. حتی اگر شما نسخه های SQL Server 2000 داشته باشید، توسط ابزار SSMS می توانید آن ها را مدیریت کنید.

4. بهره گیری از قدرت Net. برای ایجاد اشیا پایگاه داده

در این نسخه شما قادر می باشید از زبان های برنامه نویسی سطح بالا مانند Visual Basic.Net یا C#.Net جهت تولید اشیا پایگاه داده مانند Stored Procedures ، Functions و Triggers استفاده کنید. در واقع قرار گیری CLR در هسته اصلی SQL Server 2005 استفاده از هزاران class موجود در Net. را در پایگاه داده میسر ساخته است.
لازم به ذکر است استفاده از CLR برای تولید اشیا پایگاه داده زمانی ارزشمند است که شی ساخته شده دارای منطق عملیاتی پیچیده ای باشد، در واقع قدرت عملکرد اشایی که با CLR ساخته می شود، به مراتب بالاتر از اشیایی می باشد که با T-SQL ساخته شده باشد.

5. بهره گیری از مزایای Reporting Services

به یک قاعده کلی اشاره می کنم، " هر چیزی که Back end می تواند انجام دهد، باید Back end انجام دهد و نباید به Front end سپرده شود. "
برای مثال ساخت یک Query به صورت Dynamic معمولا کار سخت و زمان فرسایی می باشد که مستلزم کد نویسی زیادی در لایه Application می باشد. در واقع راه بهتر حالت دریافت پارامتر ها از کاربر و ارسال آن ها به یک Stored Procedure می باشد.
SQL Server Reporting Services این مفهوم را بسیار بهینه و کاراتر ساخته است. در نسخه های قدیم SQL Server ، گزارشات توسط برنامه های Front end مانند ( VB ، C++ ، Crystal Reports و ... ) صورت می پذیرفت .
در SQL Server 2005 شما می توانید از مزایای بسیار Reporting Services استفاده نمائید.
اول از همه شما می توانید کلیه منطق های مربوطه را از برنامه کاربردی جدا نموده و به Reporting Services بسپارید. پس از آن از هر Frond end دیگری می تواند جهت فراخوانی گزارشات به سادگی استفاده کنید.

6. Business Intelligence موجود در SQL Server 2005

سیستم های هوشمند و تحلیلی که بیشتر با عنوان سیستم های ( OLAP ) شناخته می شوند درون SQL Server 2005 قرار گرفته شده است. یکپارچگی هوش تجاری با موتور پایگاه داده قابلیت های فراوانی را به طراحان برنامه های کاربردی و تحلیل گران داده های سازمانی ارائه می دهد.

7. با DTS خداحافظی کنید و به SSIS خوش آمد گوئید !

SQL Server 2005 ویژگی جدیدی به نام SSIS را معرفی می کند که از نظر امنیتی ، مدیریتی و کاربردی بسیار مناسب عمل می کند. این ویژگی که جایگزین مانسبی برای DTS می باشد، عملیات ارسال و دریافت داده ها و تغییر آن ها را میان پایگاه های داده و فایل های مختلف به شکلی ساده و حرفه ای مدیریت می کند.

8. بهره گیری از مکانیسم امنیتی نوین و مطمئن با مدیریت آسان تر

توسط این نسخه می توانید دسترسی های خاص تر به افراد خاصی بدهید، طراحی جدید Schema به شما امکان می دهد به کاربران خود فقط دسترسی هایی را بدهید که به آن نیاز دارند.

9. قابلیت بسط پذیری در سازمان های بسیار بزرگ

بدون شک یکی از اصلی ترین مشکلات SQL Server 2000 ، عدم قابلیت یا بهتر است بگوئیم عدم کارایی این نسخه با حجم وسیعی از داده ها در سطح Enterprise بوده است. در واقع یکی از مهم ترین نقاط مورد توجه در طراحی این نسخه از SQL Server ، قابلیت رقابت این سیستم با رقبای تجاری مانند Oracle و DB/2 بوده است.

10. ارائه روش های جدید برای برنامه نویسی پایگاه داده

نسخه SQL Server 2005 دارای ویژگی های متعددی جهت افزایش کارایی و کاهش زمان برنامه نویسی می باشد.
این ویژگی ها شامل موارد زیر می باشد:

ADO.Net version 2.0
• Hosted Common Language Runtime
• Security Enhancement
• Transact-SQL Enhancement
• Service Broker
• Web Services- HTTP Endpoints
• Native XML Support
• Embedded Reports