" از عبارت ON برای مشخص کردن محدوده Trigger در سطح SQL Instance (در این صورت ON All SERVER نوشته میشود) و یا در سطح Database (در این حالت ON DATABASE نوشته میشود) استفاده میشود و از عبارت FOR برای مشخص کردن رویداد یا گروه رویدادی که سبب فراخوانی Trigger میشود، استفاده خواهد شد. "
در خصوص مثالی که اشاره کردید، به نظرم میرسد از Trigger برای این منظور استفاده نمیشود (در حوزهی بکاپ و ریستور)، شاید اگر قصدتان به منظور ثبت log و ... بایست از Auditing استفاده کنید. به این منظور در Auditing با توجه به جدول زیر میتوان اقدام به ثبت موارد نمود:
Action group name | Event Class | Description |
BACKUP_RESTORE_GROUP | Audit Backup/Restore | یک دستور Backup یا Restore صادر شود |
بررسی SQL Server Audit
بازبینی (Auditing) شامل پیگیری و ثبت رویدادهایی است که در سطح SQL Instance و یا Databaseهای روی یک سیستم اتفاق میافتد. چندین سطح برای Auditing در SQL Server وجود دارد که به صلاحدید و نیازمندیهای نصب شما وابسته است. شما میتوانید گروه اقدامات بازبینی سرویس دهنده (server audit action groups) را به ازای هر SQL Instance و گروه اقدامات بازبینی بانک اطلاعاتی (database audit action groups) را به ازای هر بانک اطلاعاتی ثبت کنید. رویداد Audit هر زمان عملی که مورد رسیدگی قرار گرفته اتفاق افتد، رخ میدهد.
تا پیش از SQL SERVER 2008، شما باید از خصیصههای متعددی برای انجام یک مجموعه کامل بازبینی (Auditing) برای نمونه DDL Trigger، DML Trigger و SQL Trace، بر روی یک SQL Instance استفاده میکردید.
SQL SERVER 2008، همه قابلیتهای Auditing را روی یک audit specification ترکیب میکند. Audit Specification با تعریف یک شی بازبینی (audit object) در سطح سرویس دهنده برای ثبت (logging) یک دنباله بازبینی (audit trial) آغاز میشود. توجه شود که بایست یک شیء بازبینی ایجاد کنید پیش از اینکه یک Server Audit Specification و یا Database Audit Specification ایجاد کنید.
Server Audit Specification، گروه اقدامات در سطح سرویس دهنده را جمع آوری میکند که با رویدادهای وسیعی فعال میشوند، این گروه اقدامات تحت عنوان Server-Level Audit Action Groups تشریح شده اند. شما میتوانید یک Server Audit Specification را به ازای هر Audit ایجاد کنید چرا که هر دو در محدوده یک SQL Instance ایجاد میشوند.
Database Audit Specification، گروه اقدامات در سطح بانک اطلاعاتی را جمع آوری میکند که با رویدادهای وسیعی فعال میشود. این گروه اقدامات تحت عنوانهای Database-Level Audit Action Groups و Database-Level Audit Actions تشریح شده اند.می توانید یک Database Audit Specification را به ازای هر Audit در بانک اطلاعاتی SQL Server ایجاد کنید.
همچنین میتوانید هر گروه اقدامات بازبینی(audit action groups) یا رویدادهای بازبینی(audit events) را به یک Database Audit Specification اضافه کنید. گروه اقدامات بازبینی، گروه اقدامات از پیش تعریف شده ای هستند و رویدادهای بازبینی اقدامات تجزیه ناپذیری هستند که توسط موتور بانک اطلاعاتی مورد رسیدگی قرار میگیرند، هر دو در محدوده بانک اطلاعاتی (Database) هستند. این اقدامات برای Audit فرستاده میشوند تا در Target (که میتواند یک فایل، Windows Security Log و یا Windows Application Log باشد) ذخیره شوند. برای نوشتن در Windows Security Log لازم است که Service Account سرویس دهنده شما به Policy، Generate security audits اضافه شده باشد، به صورت پیش فرض Local System، Local Service و Network Service بخشی از این Policy میباشند. پس از اینکه Audit را ایجاد و فعال کردید، Target ورودیها را دریافت خواهد کرد.
Server-Level Audit Action Groups (گروه اقدامات بازبینی در سطح سرویس دهنده)
این گروه اقدامات به گروه رویداد Security Audit شبیه هستند. به طور خلاصه این گروه اقدامات، اقداماتی را که در یک SQL Instance شامل میشوند، در بر میگیرد. برای مثال اگر گروه اقدام مناسب با Server Audit Specification اضافه شده باشد هر شیء در هر Schema که مورد دستیابی قرار میگیرد، ثبت میشود. اقدامات در سطح سرویس دهنده به شما اجازه نمیدهد که جزئیات اقدامات در سطح بانک اطلاعاتی را فیلتر کنید. یک بازبینی در سطح بانک اطلاعاتی برای انجام به جزئیات دقیق فیلتر کردن نیاز دارد، برای مثال اجرای دستور Select روی جدول Customers برای login هایی که در گروه Employee هستند.
Database-Level Audit Action Groups (گروه اقدامات بازبینی در سطح بانک اطلاعاتی)
این گروه اعمال به کلاسهای رویداد Security Audit شبیه هستند.
Database-Level Audit Actions
اقدامات در سطح بانک اطلاعاتی، اقدامات بازبینی خاصی را به طور مستقیم روی Database، Schema و اشیاء Schema (از قبیل جداول، View ها، رویههای ذخیره شده، توابع و ... ) فراهم میکند. این اقدامات برای فیلدها (Columns) صدق نمیکنند.
Audit-Level Audit Action Groups
شما میتوانید اقداماتی را که در فرآیند Auditing هستند، بازبینی کنید که میتواند در محدوده سرویس دهنده یا بانک اطلاعاتی باشد. در محدوده بانک اطلاعاتی تنها برای database audit specification رخ میدهد.
جهت بررسی بیشتر به این لینک مراجعه شود.
وبلاگها ، سایتها و مقالات ایرانی (داخل و خارج از ایران)
- مروری بر Delphi 2009 و مهاجرت به آن
- تصحیح خودکار کلمات فارسی در برنامه اپنآفیس
- دانلود عکس از سایت
- ۱۰ قانون برای نوشتن در وب
- استفاده از SQL Server در PHP
- بلوهاست و ایران
- سورس و گزارش پروژه فارسی نت منتشر شد
- درون یک ISP چه می گذرد؟
- تابعهای جادویی PHP 5
- راهنمای کوچک همکاری در پروژههای بازمتن
- nsis قدرتمندتر از آنچه یک نصب کننده نرم افزار نیاز دارد!
- چند اشتباه رایج در طراحی وب
امنیت
Visual Studio
ASP. Net
طراحی و توسعه وب
PHP
اسکیوال سرور
سی شارپ
VB
CPP
عمومی دات نت
مسایل اجتماعی و انسانی برنامه نویسی
- چه برنامهنویسهایی را استخدام نکنید؟
- چرا خانمها کمتر در پروژههای سورس باز ظاهر میشوند؟!
- IE6 را نمیخواهیم!
متفرقه
وبلاگها ، سایتها و مقالات ایرانی (داخل و خارج از ایران)
- ریستارت کردن سایت ASP.NET
- انتشار نسخه نهایی راهنمای امنیتی WCF
- صنعت حل کپچای هند و راهحلهای مقابله با اسپم با تکیه بر تحلیل محتوا
- بالابردن ضریب موفقیت پیاده سازی ITIL در سازمان
- تکست باکس قابل ویرایش بوسیله ASP.NET AJAX
- لیستی از نرم افزارهای ORMapper
- استفاده مشترک از یک یا چند User Control در چندین IIS Application
Visual Studio
ASP. Net
طراحی و توسعه وب
- تعیین اعتبار زیباتر فیلدهای یک فرم
- آشنایی با یک سری تگ مجهور HTML !
- در انتخاب رنگهای مناسب و هماهنگ مشکل دارید؟
- معرفی 10 فریم ورک جاوا اسکریپتی
اسکیوال سرور
عمومی دات نت
ویندوز
متفرقه
EF Code First #5
در کل این بحث در اینجا ادامه پیدا نکند بهتر است. چون نه مشخص است تنظیمات سرور شما چی هست. نه رشته اتصالی شما رو من دیدم. نه تنظیمات برنامه و Context شما مشخص است و نه تعداد وهلههای سرور. نه سطح دسترسی یوزر اتصالی شما و نه نوع اعتبار سنجی لاگین یوزر متصل به سرور (ویندوزی است یا مخصوص sql server است).
SET STATISTICS TIME ON
SELECT ProductID, StartDate, EndDate, StandardCost FROM Production.ProductCostHistory WHERE StandardCost < 500.00;
SQL Server parse and compile time: CPU time = 0 ms, elapsed time = 1 ms. (269 row(s) affected) SQL Server Execution Times: CPU time = 1 ms, elapsed time = 2 ms.
-
زمان کامپایل و تجزیه و تحلیل ( parse and compile time) : زمانیکه یک کوئری را برای اجرا به SQL Server ارائه میدهید، SQL Server آنرا از نظر خطای نحوی بررسی مینماید و بهینه ساز یک نقشه بهینه را برای اجرا تولید مینماید. اگر به خروجی نگاه کنید، زمان پردازش ( CPU time) و زمان سپری شده ( elapsed time) را نشان می دهد. منظور از زمان پردازش زمان واقعی صرف شده روی پردازنده میباشد و زمان سپری شده اشاره به زمان تکمیل شدن عملیات کامپایل و تجزیه و تحلیل میباشد. تفاوت بین زمان پردازش و زمان سپری شده ممکن است زمان انتظار در صف برای گرفتن پردازنده و یا انتظار برای تکمیل عملیات IO باشد.
-
زمان اجرا ( Execution Times) : این زمان اشاره به زمان سپری شده برای تکمیل اجرای نقشه کامپایل شده دارد. زمان پردازش اشاره به زمان واقعی صرف شده روی پردازنده دارد و زمان سپری شده نیز مجموع زمان صرف شده تا تکمیل اجرای دستور که شامل زمان انتظار برای تکمیل عملیات IO و زمان صرف شده برای انتقال خروجی به کلاینت میباشد، دارد. زمان پردازش میتواند به عنوان مبنایی برای اندازهگیری کارآیی مورد استفاده قرار بگیرد. این مقدار در اجراهای مختلف تفاوت چندانی با هم ندارند جز اینکه کوئری و یا دادهها تغییر نمایند. توجه نمایید که زمان براساس میلی ثانیه میباشد. زمان سپری شده نیز به فاکتورهایی مانند بارگذاری روی سرور، بارگذاری IO، و پهنای باند بین سرور و کلاینت وابسته میباشد. بنابراین همیشه زمان پردازش به عنوان مبنایی برای اندازهگیری کارایی استفاده میشود .
- SQL Server Database Engine از کلمه کلیدی SPARSE برای تعریف یک ستون که مقادیر آن میبایست بهینه شود استفاده مینماید.
- نمای Catalog جداول با ستون sparse شبیه جداول معمولی میباشد.
- مقدار برگشتی از تابع COLUMNS_UPDATED با ستون sparce متفاوت از ستون معمولی است.
geography | text |
geometry | timestamp |
image | user-defined data types |
ntext |
نوع داده | بایت بدون sparse | بایت sparse | درصد null |
bit | 0.125 | 5 | 98% |
tinyint | 1 | 5 | 86% |
smallint | 2 | 6 | 76% |
int | 4 | 8 | 64% |
bigint | 8 | 12 | 52% |
real | 4 | 8 | 64% |
float | 8 | 12 | 52% |
smallmoney | 4 | 8 | 64% |
money | 8 | 12 | 52% |
smalldatetime | 4 | 8 | 64% |
datetime | 8 | 12 | 52% |
uniqueidentifier | 16 | 20 | 43% |
date | 3 | 7 | 69% |
نوع داده | بایت بدون sparse | یابت sparse | درصد null |
(datetime(2 | 6 | 10 | 57% |
(datetime(2 | 8 | 12 | 52% |
(time(0 | 3 | 7 | 69% |
(time(7 | 5 | 9 | 60% |
(datetimetoffset(0 | 8 | 12 | 52% |
(datetimetoffset (7 | 10 | 14 | 49% |
(decimal/numeric(1,s | 5 | 9 | 60% |
(decimal/numeric(38,s | 17 | 21 | 42% |
(vardecimal(p,s |
نوع داده |
بایت بدون sparse | یابت sparse | درصد null |
sql_variant | 2* | 2* | 60% |
varchar or char | 2* | 4*+ | 60% |
nvarchar or nchar | 2* | 4* | 60% |
varbinary or binary | 2* | 4* | 60% |
xml | 2* | 4* | 60% |
hierarchyid | 2* | 4* | 60% |
- sparse column می بایست nullable باشد و نمیتواند ROWGUIDCOL یا IDENTITY باشد.
- sparse column مقدار پیش فرض نمیتواند داشته باشد
- ستون محاسبه ای نمیتواند sparse باشد
- sparse column نمیتواند بخشی از clustered index یا unique primary key index باشد
- sparse column نمی تواند بخشی از user-defined table باشد
CREATE TABLE Employees_sparse ( EMP_ID INT IDENTITY(5001,1) PRIMARY KEY, SSN CHAR(9) NOT NULL, TITLE CHAR(10) SPARSE NULL, FIRSTNAME VARCHAR(50) NOT NULL, MIDDLEINIT CHAR(1) SPARSE NULL, LASTNAME VARCHAR(50) NOT NULL, EMAIL CHAR(50) SPARSE NULL) GO
CREATE TABLE Employees ( EMP_ID INT IDENTITY(5001,1) PRIMARY KEY, SSN CHAR(9) NOT NULL, TITLE CHAR(10) NULL, FIRSTNAME VARCHAR(50) NOT NULL, MIDDLEINIT CHAR(1) NULL, LASTNAME VARCHAR(50) NOT NULL, EMAIL CHAR(50) NULL) GO
sp_spaceused 'Employees' GO sp_spaceused 'Employees_sparse'
یکی از مواردی که در محیط کاری زیاد پیش میآید بحث همگام نبودن دیتابیس توسعه با دیتابیس کاری است.
منظور از دیتابیس توسعه، همان دیتابیسی است که برای برنامه نویسی و آزمایش از آن استفاده میشود و دیتابیس کاری هم مشخص است (برای مثال بر روی یک سرور در اینترانت داخلی یک شرکت و یا بر روی یک سرور اینترنتی قرار دارد). عادتهای مختلفی هم اینجا ممکن است وجود داشته باشد، برای مثال تغییرات جدید بر روی دیتابیس کاری اعمال شود و سپس فراموش شود که همانها نیز باید به دیتابیس توسعه هم اعمال شوند تا در تغییرات بعدی برای آزمایش دچار مشکل نشویم و برعکس. بعد از یک مدت هم تبدیل به کابوس میشود؛ نمیدانیم الان دیتابیس کاری جدیدتر است یا دیتابیس توسعه؛ و یا اینکه کلا دو دیتابیس مفروض چه تفاوتهای ساختاری با هم دارند (بدیهی است بحث دیتا در اینجا در درجهی اول اهمیت قرار ندارد). فرصت این هم وجود ندارد که تک تک جداول، ویووها، رویههای ذخیره شده و خلاصه تمامی اشیاء مرتبط را بررسی کنیم که چه اختلافی با هم دارند. اینجا مستندات هم کمکی نخواهند کرد چون صحبت از یک جدول با 5 فیلد در میان نیست که موارد را سریع و به صورت دستی تطابق دهیم. همچنین این مشکل عموما زمانی رخ میدهد که یکی از دو طرف در حال حاضر مستندات کامل و به روزی ندارد. اکنون چه باید کرد؟
اولین فکری که به ذهن خطور میکند مراجعه به ابزارهای جانبی است (مثلا Red Gate's SQL Compare چند صد دلاری) غافل از اینکه خود Visual studio 2008 (نگارشهای تیمی و دیتابیسی) این قابلیت را نیز ارائه میدهد (شکل زیر).
پس از انتخاب new schema comparison ، در صفحهای که ظاهر میشود، بر روی new connection کلیک کرده و دیتابیسهای مبداء و مقصد را جهت مقایسه ساختاری انتخاب نمائید و سپس بر روی دکمه Ok کلیک کنید.
اگر اس کیوال سرور 2008 را نصب کرده باشید، با پیغام زیر روبرو خواهید شد:
برای رفع این مشکل باید بسته به روز رسانی زیر را نصب کرد تا این نگارش نیز پشتیبانی شود:
(برای نصب حتما باید SP1 مربوط به VS.Net 2008 پیشتر نصب شده باشد)
پس از کلیک بر روی دکمه Ok، کار آنالیز دو دیتابیس شروع شده و تفاوتها گزارش داده میشوند:
همچنین جهت سهولت کار، اسکریپت T-SQL ایی را نیز به نام schema update script تولید میکند که با اجرای آن به سادگی کار به روز رسانی دیتابیس مقصد صورت خواهد گرفت.
در پایان یا میتوان اسکریپت تولید شده را ذخیره کرد و در زمانی دلخواه اجرا و اعمال نمود و یا میتوان بلافاصله بر روی دکمه write updates که در نوار ابزار ظاهر شده است کلیک کرد تا دیتابیس مقصد از لحاظ ساختاری با دیتابیس مبداء یکی شود.
EF Code First #1
با پیشنهادتان برای ارتباط با دیتابیس، این سری از آموزشها رو شروع کردم.
سوال:
در قسمت تشکیل خودکار بانک اطلاعاتی و افزودن اطلاعات به جداول
1- مقدار Data Source و Initial Catalog رو از کجا باید پیدا کرد؟ یا بهتر بگویم کانکشن استرینگ رو چطوری میشه از SQL بدست آورد؟
این کانکشن بعد از نصب SQL Server 2008 Enterprise :
سپاس.
آیا میدانید آخرین باری که از یک دیتابیس مفروض بکآپ گرفته شده، چه زمانی بوده است؟ (یا اینکه اصلا چه اهمیتی داره؟!)
USE master;
SELECT B.name AS Database_Name,
ISNULL(STR(ABS(DATEDIFF(day, GetDate(),
MAX(Backup_finish_date)))), 'NEVER') AS DaysSinceLastBackup,
ISNULL(CONVERT(char(10), MAX(backup_finish_date), 101), 'NEVER') AS
LastBackupDate
FROM master.dbo.sysdatabases B
LEFT OUTER JOIN msdb.dbo.backupset A
ON A.database_name = B.name
AND A.type = 'D'
GROUP BY
B.Name
ORDER BY
B.name
همانطور که مطلع هستید در SQL Server 2008 امکان فشرده سازی خودکار بک آپها هم فراهم شده است. با استفاده از اسکریپت زیر میتوان از درصد فشرده سازی بکآپها گزارش گرفت:
SELECT bs.server_name,
bs.database_name AS 'Database Name',
CONVERT (BIGINT, bs.backup_size / 1048576 ) AS
'Uncompressed Backup Size (MB)',
CONVERT (BIGINT, bs.compressed_backup_size / 1048576 ) AS
'Compressed Backup Size (MB)',
CONVERT (NUMERIC (20,2), (CONVERT (FLOAT, bs.backup_size) /
CONVERT (FLOAT, bs.compressed_backup_size))) AS 'Compression Ratio',
DATEDIFF (SECOND, bs.backup_start_date, bs.backup_finish_date) AS
'Backup Elapsed Time (sec)',
bs.backup_finish_date AS 'Backup Finish Date'
FROM msdb.dbo.backupset AS bs
WHERE DATEDIFF (SECOND, bs.backup_start_date, bs.backup_finish_date) > 0
AND bs.backup_size > 0
AND bs.type = 'D' -- Change to L if you want Log backups
ORDER BY
bs.backup_finish_date DESC
برای فعال سازی گزینه فشرده سازی بکآپها با استفاده از دستورات T-SQL میتوان به صورت زیر عمل کرد (در SQL server 2008):
USE master;
EXEC sp_configure 'backup compression default', '1';
RECONFIGURE WITH OVERRIDE;
ماخذ مورد استفاده:
http://www.sqlservercentral.com