How To: Enable the Use of Sessions On Your WordPress Blog

WordPress does not use sessions to hold any data being that it is a stateless application. This makes it quite a problem for tasks like a shopping cart, which requires data(the user’s selected product) to be remembered from one page to the next. This means that if you want to use PHP sessions in your plugins or custom modifications of WordPress you will need to do some custom coding.

Luckily the fix is a simple one that anyone can handle! You only need to do a little hacking to enable sessions within WordPress.

Understanding Sessions

A session is a combination of a server-side file containing all the data you wish to store, and a client-side cookie containing a reference to the server data. The file and the client-side cookie are created using the function session_start() – it has no parameters, but informs the server that sessions are going to be used.

When you call session_start(), PHP will check to see whether the visitor sent a session cookie – if it did, PHP will load the session data. Otherwise, PHP will create a new session file on the server, and send an ID back to the visitor to associate the visitor with the new file. Because each visitor has their own data locked away in their unique session file, you need to call session_start() before you try to read session variables – failing to do so will mean that you simply will not have access to their data. Furthermore, as session_start() needs to send the reference cookie to the user’s computer, you need to have it before the body of your web page – even before any spaces.

The WordPress Fix For $_SESSION Variables

So in order to activate session variables within your WordPress installation the only thing you have to do is call session_start(); before any output is send to the client. Normally upgrading your WordPress installation will replace all files, so we will want to install the code within our site theme to avoid the changes from being lost.

We will add the next lines of code to our functions.php file within our theme:

if ( !session_id() )
add_action( 'init', 'session_start' );


It is best place to add these lines is at the top of functions.php, immediately after the php start tag (

If your server is currently running register_globals on you will also need to modify a function named wp_unregister_GLOBALS and can be found in your wp-settings.php file located in the root directory of the WordPress install. The code you are looking for is located around line 39:

$noUnset = array(‘GLOBALS’, ‘_GET’, ‘_POST’, ‘_COOKIE’, ‘_REQUEST’, ‘_SERVER’, ‘_ENV’, ‘_FILES’, ‘table_prefix’);


To allow sessions you simply have to insert _SESSION into the array. The final code will be:

$noUnset = array(‘_SESSION’,'GLOBALS’, ‘_GET’, ‘_POST’, ‘_COOKIE’, ‘_REQUEST’, ‘_SERVER’, ‘_ENV’, ‘_FILES’, ‘table_prefix’);


Victory!

Sessions are now enabled on your WordPress blog! You can now use PHP sessions on your WordPress plugins or custom modifications.

http://www.myguysolutions.com/2010/04/14/how-to-enable-the-use-of-sessions-on-your-wordpress-blog/

Getting an ASP.NET 4 application to work on IIS6

http://johan.driessen.se/posts/getting-an-asp.net-4-application-to-work-on-iis6

Now, for the last 5 months or so, I’ve been involved in a project where we develop an application with ASP.NET MVC on .NET 4 (we started on the beta 2). The main part of this application is hosted on servers running Windows 2008 Server R2 and IIS 7.5. But unfortunately, one part of the application has to be deployed to servers running Windows 2003 Server, and thus IIS 6.0.

Turns out, it’s a bit tricky to get .NET 4 working on IIS 6.0.

I did the usual stuff, I installed .NET 4 Framework, restarted the server, created a new application in IIS, running in its own Application Pool, and changed the ASP.NET version to 4. Then I tried to access my application. I was greeted by this:

Strange. I’m pretty sure this is not what should happen. Now, since I’m running ASP.NET MVC, and have to do some mapping stuff on IIS6 (described for example by Phil Haack back in 2008), I naturally suspected this to be the problem. So I created a new application, and just added a default.aspx that prints the current date. Exactly the same result. Weird.

After some extensive googling (Yes, googling. Not Binging.) I got the tip to look at my IIS logfile to see what the error was, and I found this row:

?

1	2010-04-13 14:27:05 W3SVC674436196 127.0.0.1 GET / - 80 - 127.0.0.1 Mozilla/4.0+(*snip*) 404 2 1260

So, the error is 404.2. A look at the IIS status codes told me what this means: 404.2 – Lockdown policy prevents this request. WTF? Well, it turns out that just because you install .NET 4 on Windows 2003 Server, you’re not automatically allowed to use it i IIS! The article provided a few useful links to the Knowledge base:

• 328505 How to list Web Server Extensions and Extension files in IIS 6.0
• 328360 How to enable and disable ISAPI extensions and CGI applications in IIS 6.0

Following the instructions from the first of these, I checked what extensions where available on my server:

Notice that the Status for the .NET 4 ASP.NET ISAPI extension is 0? Well, that means that it is disabled. Now, if you read the other knowledge base article, it will tell you how to enable it. Just run the following command:

?

1	cscript iisext.vbs /EnFile C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll

And If I now run the /ListFile command again, I will se that the ASP.NET 4 extension is now showing a little “1” as status, telling me that it is now enabled.

And after this, my application worked fine. And not only the test application that printed today's date, but even my ASP.NET MVC application!

نکته در استفاده از دستور SubmitChanges در linq

حتما به این نکته توجه داشته باشید که جدول شما باید دارای Primary Key باشد، وگرنه دستور SubmitChanges کار نمی کند.

یادتان نرود که اگر جدول را در Sql Server تغییر دادید، حتما باید مجددا آن را در فایل dbml بارگذاری کنید تا تغییرات بروز شود.

SQL Server Data Types

SQL Server Data Types

Character strings:

Data type	Description	Storage
char(n)	Fixed-length character string. Maximum 8,000 characters	n
varchar(n)	Variable-length character string. Maximum 8,000 characters
varchar(max)	Variable-length character string. Maximum 1,073,741,824 characters
text	Variable-length character string. Maximum 2GB of text data

Unicode strings:

Data type	Description	Storage
nchar(n)	Fixed-length Unicode data. Maximum 4,000 characters
nvarchar(n)	Variable-length Unicode data. Maximum 4,000 characters
nvarchar(max)	Variable-length Unicode data. Maximum 536,870,912 characters
ntext	Variable-length Unicode data. Maximum 2GB of text data

Binary types:

Data type	Description	Storage
bit	Allows 0, 1, or NULL
binary(n)	Fixed-length binary data. Maximum 8,000 bytes
varbinary(n)	Variable-length binary data. Maximum 8,000 bytes
varbinary(max)	Variable-length binary data. Maximum 2GB
image	Variable-length binary data. Maximum 2GB

Number types:

Data type	Description	Storage
tinyint	Allows whole numbers from 0 to 255	1 byte
smallint	Allows whole numbers between -32,768 and 32,767	2 bytes
int	Allows whole numbers between -2,147,483,648 and 2,147,483,647	4 bytes
bigint	Allows whole numbers between -9,223,372,036,854,775,808 and 9,223,372,036,854,775,807	8 bytes
decimal(p,s)	Fixed precision and scale numbers. Allows numbers from -10^38 +1 to 10^38 –1. The p parameter indicates the maximum total number of digits that can be stored (both to the left and to the right of the decimal point). p must be a value from 1 to 38. Default is 18. The s parameter indicates the maximum number of digits stored to the right of the decimal point. s must be a value from 0 to p. Default value is 0	5-17 bytes
numeric(p,s)	Fixed precision and scale numbers. Allows numbers from -10^38 +1 to 10^38 –1. The p parameter indicates the maximum total number of digits that can be stored (both to the left and to the right of the decimal point). p must be a value from 1 to 38. Default is 18. The s parameter indicates the maximum number of digits stored to the right of the decimal point. s must be a value from 0 to p. Default value is 0	5-17 bytes
smallmoney	Monetary data from -214,748.3648 to 214,748.3647	4 bytes
money	Monetary data from -922,337,203,685,477.5808 to 922,337,203,685,477.5807	8 bytes
float(n)	Floating precision number data from -1.79E + 308 to 1.79E + 308. The n parameter indicates whether the field should hold 4 or 8 bytes. float(24) holds a 4-byte field and float(53) holds an 8-byte field. Default value of n is 53.	4 or 8 bytes
real	Floating precision number data from -3.40E + 38 to 3.40E + 38	4 bytes

Date types:

Data type	Description	Storage
datetime	From January 1, 1753 to December 31, 9999 with an accuracy of 3.33 milliseconds	8 bytes
datetime2	From January 1, 0001 to December 31, 9999 with an accuracy of 100 nanoseconds	6-8 bytes
smalldatetime	From January 1, 1900 to June 6, 2079 with an accuracy of 1 minute	4 bytes
date	Store a date only. From January 1, 0001 to December 31, 9999	3 bytes
time	Store a time only to an accuracy of 100 nanoseconds	3-5 bytes
datetimeoffset	The same as datetime2 with the addition of a time zone offset	8-10 bytes
timestamp	Stores a unique number that gets updated every time a row gets created or modified. The timestamp value is based upon an internal clock and does not correspond to real time. Each table may have only one timestamp variable

Other data types:

Data type	Description
sql_variant	Stores up to 8,000 bytes of data of various data types, except text, ntext, and timestamp
uniqueidentifier	Stores a globally unique identifier (GUID)
xml	Stores XML formatted data. Maximum 2GB
cursor	Stores a reference to a cursor used for database operations
table	Stores a result-set for later processing

C# Data Types

C# Type	.Net Framework (System) type	Signed?	Bytes Occupied	Possible Values
sbyte	System.Sbyte	Yes	1	-128 to 127
short	System.Int16	Yes	2	-32768 to 32767
int	System.Int32	Yes	4	-2147483648 to 2147483647
long	System.Int64	Yes	8	-9223372036854775808 to 9223372036854775807
byte	System.Byte	No	1	0 to 255
ushort	System.Uint16	No	2	0 to 65535
uint	System.UInt32	No	4	0 to 4294967295
ulong	System.Uint64	No	8	0 to 18446744073709551615
float	System.Single	Yes	4	Approximately ±1.5 x 10^-45to ±3.4 x 10^38with 7 significant figures
double	System.Double	Yes	8	Approximately ±5.0 x 10^-324to ±1.7 x 10^308with 15 or 16 significant figures
decimal	System.Decimal	Yes	12	Approximately ±1.0 x 10^-28to ±7.9 x 10^28with 28 or 29 significant figures
char	System.Char	N/A	2	Any Unicode character (16 bit)
bool	System.Boolean	N/A	1 / 2	true or false

Configuring Database Options

هر Database در SQL Server داراي چندين Option است كه يكسري از رفتار هاي Database را كنترل مي كند اين Option ها به چندين بخش تقسيم مي شوند

Recovery
Auto Options

Recovery Options

Recovery Options رفتار Transaction Log را تعيين مي كند و همچنين چگونگي Handle , Page هاي آسيب ديده

Recovery Models

هر Database در داخل SQL Server داراي يك سري خصوصياتي است كه Recovery Model ناميده مي شود . Recovery Model انواع Backup هايي كه ما مي توانيم از يك Database را بگيريم مشخص مي كند .
چند نوع Recovery Model در SQL Server 2008 وجود دارد :

Full
Bulk-Logged
Simple

Full Recovery Model

زماني كه مدل Full Recovery براي يك Database انتخاب مي شود , تمام تغييراتي كه توسط data manipulation
language (DML) و data defi nition language (DDL), رخ مي دهد در فايل Transaction Log ثبت مي شود
اين نوع Recovery بهترين نوع مي باشد زير تمام Log ها را ثبت مي كند و اگر زماني اطلاعات شما از بين رفت مي توان توسط Transaction Log اطلاعات را بازيابي نمود .
نكته : بهتر است براي Databaseهاي حائز اهميت از اين نوع Recovery استفاده شود زيرا در صورت از بين رفتن اطلاعات شانس بازيابي نسبتا زياد است .

Bulk-Logged Recovery Model

در مورد Database هايي كه BULK INSERT هاي سنگيني دارند , اين نوع Recovery مفيد خواهد بود زيرا در حالت Buli-Logged تمام جزئيات مربوط به BULK INSERT ثبت نمي شود كه اين امر هم باعث بالا رفتن سرعت BULK INSERT مي شود و هم Log File به صورت ناگهاني رشد نمي كند .

در مورد موارد زير مي توانيم از Bulk-Logged Recovery Model استفاده كنيم :

BCP
BULK INSERT
SELECT. . .INTO
CREATE INDEX
ALTER INDEX. . .REBUILD

Simple Recovery Model

سومين نوع Recovery , Simple است , كه عمليات ثبت Log ها در داخل Transaction Log را دقيقا مانند Full Recovery Model انجام مي دهد , ولي فقط Transactionها ي Live و يا تازه رو ثبت مي كند. SQL , Transcation هايي كه با موفقيت به پايان رسيده اند را در يك فاصله زماني مشخص پاك مي كند به همين دليل هيچ وقت تمام Transaction ها ثبت نمي شوند
نكته: زماني كه ما Simple Recovery Model استفاده مي كنيم , نمي توانيم از Transaction Log Backup استفاده كنيم , زيرا تمام Log ها در فايل Transaction Log ثبت نمي شود

Recovery Model يكي از خصوصيات Database است كه شما مي توانيد با استفاده از دستور زير نوع Recovery Model مربوط به Database خود را تغيير دهيد .

ALTER DATABASE database_name
SET RECOVERY { FULL | BULK_LOGGED | SIMPLE }

Auto Options

هر بانك اطلاعاتي جديدي كه در SQL Server ايجاد مي شود , براساس بانك اطلاعاتي Model ساخته مي شود , گاهي اوقات مي بايست براي بالا رفتن Performance , Database بعضي از اين گذينه ها را تغيير داد .
چندين Option براي هر Database در SQL Server وجود دارد :

Auto Close

وقتي كاربري به يك DB وصل مي شود آن DB*مي بايست باز شود , وقتي يك DB* باز است از منابع سيستم مثل Ramو Cpu استفاده مي كند , زماني كه اين گذينه True باشد , زماني كه آخرين كاربر ارتباطش با DB قطع شد , DB*بسته مي شود

Auto Create Statistic

در SQL به محض اينكه يك Query*اجرا مي شود , Query Analiyzer به منظور تعيين بهترين روش براي برگرداندن نتايج عمل مي كند كه اين كار رو با خوندن يك سري آمار در باره هر كدام از ستون هاي مطرح در دستور Select انجام مي دهد, زماني كه اين گذينه True باشد خود SQL به صورت خودكار اين آمار را براي هر ستون آماده مي كند .


Auto Update Statistic

زماني كه اين گذينه يه صورت True باشد خود SQL Server به صورت خودكار آمار ها را Update مي كند
Default Cursor
زماني كه مقدار local براي اين گذينه انتخاب شود , اين به اين معنا است كه تنها پروسيجر ايجاد كننده هر Cursor مي تواند از آن استفاده كند .
مقدار Global به اين معتا است كه پروسيجر هاي ديگر نيز مي توانند ا اين Cursor استفاده كنند , مثلا ما يك پروسيجر به نام test داريم كه در آن يك cursor وجود دارد , در صورتي كه اجراي پروسيجر test موجب اجراي پروسيجر هاي ديگر شود آن پروسيجر ها نيز مي توانند از cursor موجود در پروسيجر test*استفاده كنند .

ANSI NULL Default

در SQL زماني كه يك جدول ايجاد مي كنيم مي توانيم مشخص كنيم كه Column هاي ما مي توانند خالي و يا NULL باشند يا خير , اگر در هنگام ايجاد و يا تغيير جدول , مشخص نكنيم كه ستون مي تواند خالي باشد و چنانچه مقدار اين گذينه False باشد , در آن صورت تخصيص مقدار NULL به ستون مجاز نيست , اگر مقدار اين گذينه True باشد و تخصيص مقدار NULL نيز در هنگام ايجاد و يا تغيير جدول مجاز شده باشد در آن صورت ستون ها مي توانند مقدار NULL دريافت كنند .

ANSI NULL Enable

زماني كه مقدار اين گذينه True باشد , انجام هر گونه مقايسه با NULL منجر به NULL مي شود ولي اگر مقدار False براي اين گذينه انتخاب شود , با NULL*مانند صفر بر خورد مي شود

ANSI Padding Enable

اين گذينه روش ذخيره سازي مقادبر كوچكتر از هر ستون را مشخص مي كند , اگر مقدار اين گذينه True باشد در آن صورت كاراكتر هايي به ستون هاي نوع Char(n) Not Null , Char(n) Null , Char(n) , Binary(n) Null اضافه مي شود ولي چيزي به ستون هاي نوع Varchar(n) وVarBinery(n) اضافه نمي شود و داده هاي انتهايي نيز برش داده نمي شود

ANSI Warning Enable

اگر مقدار False براي اين گذينه انتخاب شود , اگر بخواهيم عددي را بر صفر تقسيم كنيم و يا در يك عبارت رياضي از Null استفاده كنيم , SQL مقدار Null رو برمي گردانه و خطا نمي دهد ولي اگر مقدار اين گذينه True باشد , SQL يك پيغام نمايش مي دهد .

Arithmetic Abort Enable

اين گذينه براي SQL Server مشخص مي كند كه در هنگام خطاي سرريز يا تقسيم بر صفر چگونه برخورد كند , اگر True انتخاب شود SQL كل Transaction را لغو مي كند ولي اگر مقدار False براي اين كذينه انتخاب شود SQL دستور را اجرا مي كند و در نهايت يك پيغام هشدار نمايش مي دهد .

Concatenate Null Yields Null

اين گذينه مشخص مي كند كه در ادغام يك رشته به مقدار Null چطور برخورد كند , اگر اين گذينه True باشد , نتيجه Null مي باشد ولي زماني كه مقدار False براي اين گذينه انتخاب شود با Null مانند صفر برخورد مي شود پس نتيجه ادغام يك رشته با Null خود رشته مي شود .

Numeric Round Abort

اين گذينه مشخص مي كند كه SQL با خطاي گرد كردن چطور برخورد كند , اگر مقدار اين گذينه True باشد SQL به محض از بين رفتن بخشي از دقت عدد خطايي را اعلام مي كند ولي اگر اين گذينه False باشد هيچ خطايي نمايش داده نمي شود

Parameterization

چنانچه مقدار اين گذينه Semple باشد , SQL هنگام تعيين پارامتر هاي Query از رفتار هاي پيش فرض DB تبعيت مي كند , براي اينكه براي تمام Query هاي DB از پارامتر ها استفاده شود بايد مقدار اين گذينه Forced شود .

Quoted Identifiers Enable

اگر بخواهيم در نام جدول از فاصله و يا كاراكتر ها رزرو شده استفاده كنيم به صورت پيش فرض بايد نام را در بين دو [] بزاريم , اگر مقدار اين گذينه True باشد مي تونيم از علائم نقل قول جفتي نيز استفاده كنيم .

Recursive Triggers Enable

چنانچه اين گذينه True باشد اگر اجراي يك Trigger موجب اجراي يك Trigger ديگر شود Trigger دوم نيز اجرا مي شود .

Page Verify

SQL در صورت خرابي سخت افزار و يا قطع برق ممكن است نوشتن داده ها در ديسك را متوقف مي كند كه اين وضعيت خطاي I/O ناميده مي شود كه منجر به خراب شدن DB مي شود , اين گذينه سه روش جهت برخورد با اين گونه مشكلات در اختيارمان مي گذارد :

CheckSum

اين گذينه پيش فرض سبب ايجاد يك مقدار checksum براي كل data page ها مي شود و آن رو در هنگام نوشتن محتواي page ديسك در هدر صفحه ذخيره مي كند , وقتي در آينده آن page خوانده ميشود اين مقدار دوباره محاسبه شده و با مقدار ذخيره شده در هدر مقايسه مي شود اگر دو مقدار يكي بودند محتواي صفحه قابل اطمينان مي باشد.


TornPageDetection

وقتي صفحه ايي در ديسك ذخيره مي شود اين گذينه بيتي را به صورت معكوس براي هر سكتور 512 بايتي در هدر صفحه مي نويسد و وقتي صفحه در آينده خوانده مي شود چنانچه اين بيت در وضعيت قبلي نباشد در آن صورت مشخص است كه محتواي صفحه دچار مشكل شده است

Database Read Only

اين گذينه باعث مي شود كه DB به حالت فقط خواندني شود , در اين صورت هيچ چيز در DB قابل نوشتن نخواهد بود , اين DB ها معمولا سريعتر از DB هاي معولي هستند و معمولا براي DB هاي آرشيو از آنها استفاده مي شود

DataBase Status

اين گذينه غير قابل ويرايش مي باشد و وضعيت DB را مشخص كي كند كه داراي 5 گذينه زير مي باشد;

Emergency

DB در اين حالت فقط خواندني خواهد بود , برقراري ارتباط غير فعال مي شود و تنها مديران مي توانند به DB دستيابي داشته باشند

Inaccessible

اين مقدار مشخص مي كند كه Server محل نگهداري DB غير فعال شده و از طريق شبكه قابل دستيابي نيست .

Normal

اين گذينه مشخص مي كند كه همه چيز در حالت عادي قرار درد .

Offline

اين مقدار مشخص مي كند كه DB بسته شده و قابل تغيير نمي باشد .

Suspect

اين گذينه مشخص مي كند كه DB مشكل دارد و احتمالا DB بايد دوباره Restor شود .

Restrict Access

توسط اين گذينه مي توانيم كاربرانيكه به DB وصل مي شوند را كنترول كنيم كه داراي سه گذينه مي باشد

Multiple

اين مقدار پيش فرض امكان دسترسي تمامي كاربران به DB را فراهم مي كند


Single

اين گذينه در يك لحظه فقط به يك نفر امكان Connect شدن به DB را مي دهد


Restricted

با انتخاب اين گذينه تنها اعضاي db_owner و همچنين dbcreater و sysadmin مي توانند به DB دسترسي داشته باشند

نكته : ارتبا ط افرادي كه در حال كار هستند قطع نمي شود ولي هر كدام از آنها به محض قطع شدن ارتباطش با بانك ديگر قادر به ارتباط با DB نخواهد بود

برگرفته از سایت آشیانه

نکات شرینک کردن فایل های دیتابیس در SQL Server

ما دو نوع شرينك كردن داريم

• شرينك كردن ديتا فايل (خيلي بد)
• شرينك كردن لاگ فايل (بد)

يه سري مفاهيم اوليه در شرينك هست كه در هر دو نوع شرينك ثابته اول اين مفاهيم رو مرور كنيم.
وقتي فايل هاي ديتابيس ميخوان بزرگ بشن بر اساس Autogrowth ي كه ست كرديد اون مقدار مورد نظر براي اطمينان از نداشتن بد سكتور بايد zero byte فرمت بشه حال فرض كنيد رشد بانك به صورت درصدي باشه (كه به صورت پيشفرض هست) و ديتابيس شما گيگا بايتي باشه چه حجم زيادي بايد zero byte فرمت بشه و اين يعني افت Performance. البته خبر خوب اينه كه عمل بزرگ شدن فايل از SQL Server 2005 به بعد فقط براي ديتا فايل با zero byte فرمت انجام نميشه (Instant File Initialization).همه اينا رو گفتم تا برسم به اينجا كه بزرگ شدن فايل يه عمليات زمانبريه پس اگه شما از نظر حجم Storage مشكلي نداريد تا جاي كه امكان داره فايلهاي ديتابيستون رو شرينك نكنيد.

چرا شرينك كردن ديتا فايل خيلي بده!
وقتي شما ديتا فايلتون رو شرينك ميكنيد SQL مياد Extent (واحدي هست براي مديريت فضا شامل هشت Page پشت سر هم) هاي آخر فايل رو بدون توجه به ترتيب منطقي Page ها و Index ها تو قسمت هاي خالي اول فايل ميزاره و اين يعني تك تكه شدن (Fragmentation) ايندكس هاي شما (البته Clusterd ها) بنابراين كلا بيخيال اين نوع شرينك بشيد…
نکته:شرینک کردن با سویچ TRUNCATEONLY این جابجائی Extend ها رو نداره
همونطور كه ميدونيد شرينك كردن يكي از Task هاي موجود در Maintenance Plan هستش و بقول استادم

SQL Server ي كه Maintenance Plan نداشته باشه معلومه DBA بالاسرش نيست

پس تقريبا همه سرور ها Maintenance Plan رو دارن چندتا نكته

• شرينك كردن رو تا حد ممكن اتومات نكنيد
• با انجام Rebuild Index و بعد Shrink فقط و فقط وقت و منابع وكارايي و… سرور رو هدر كردين.دلیلش چيه؟

چرا شرينك كردن لاگ فايل بده؟
وقتی شما لاگ فایلتون (Transactional Log File) رو شرینک میکنید همونطور که قبلا گفتم با توجه به اینکه لاگ فایل باید zero byte فرمت بشه موقع بزرگ شدن فایل بسته به میزان Autogrowth انتخابی سیستم شما افت Performance داره.البته از بین دو نوع شرینکی که گفتم انجام این نوع شرینک منطقی هست که البته بیشتر افراد برای «پراندن لاگ» میان لاگ فایل رو شرینک میکنن پس اگه شما مشکل حجم Storage ندارید میتونید این نوع شرینک رو هم انجام ندید توجه کنید تمام این پیشنهاد های که داده میشه با توجه به اینه که مدل Recovery شما رو FULL ست شده.

یک نکته مهم «Truncate شدن لاگ اندازه فیزیکی اونو کم نمیکنه»

همنطور که میدونید اگه مدل Recovery شما FULL باشه بعد از لاگ بکاپ گرفتن لاگ فایل شما Truncate میشه ولی نکته مهم اینه Truncate شدن لاگ اندازه فیزیکی اونو کم نمیکنه بلکه اون قسمت رو مجددا قابل نوشتن میکنه.همنطور که گفتم انجام این نوع شرینک منطقی هست. کی و کجا؟
فرض کنید شما تو سرور ساعت 5 صبح Maintenance Plan تعریف کردید و همیشه میبنید که لاگ بکاپ ساعت 7 صبح شما خیلی بزرگه مشکل کجاس؟
تمام عملیات Maintenance Plan تو لاگ نوشته میشه (والبته تمام عملیات SQL Server به صورت write-ahead) و این باعث میشه لاگ فایل شما بزرگ بشه و چون حتی پس از لاگ بکاپ گرفتن این فضا کم نمیشه ازاینرو یکی از جاهای که میشه لاگ رو شرینک کرد(پراند) اینجاس.البته برای کم کردن اندازه لاگ بکاپ ساعت 7 فکر میکردم تغییر مدل Recovery به BULK_LOGGED جواب بده

به نقل از dotnetdev.info

راهكارهايي براي‌ افزايش سرعت در بانك‌هاي اطلاعاتي SQL Server

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

توسعه  به‌طور كلي براي افزايش سرعت يك بانك اطلاعاتي مي‌توان به دو روش اقدام كرد. در واقع پنج عامل مورد اشاره در بالا‌، به دو دسته طولي و عرضي تقسيم‌بندي مي‌شوند. در توسعه طولي كه در اصطلاح انگليسي به Scalp up نيز شناخته مي‌شود، مدير سيستم با صرف هزينه‌، به ارتقاي سخت‌افزار (مثل پردازنده‌ها يا هاردديسك‌ها) يا به‌طوركلي ايجاد شبكه‌اي سريع‌تر اقدام مي‌نمايد يا مثلاً سيستم‌عامل خود را به نسخه‌اي جديدتر و پايدارتر ارتقا مي‌دهد. اما در روش عرضي (Scale out) تقريباً با حفظ همان سخت‌افزار و ساختار شبكه، به بهينه‌سازي روابط موجود ميان عناصر دخيل در سرعت مثل برنامه‌هاي كاربردي، بانك اطلاعاتي و سرور اقدام مي‌كند.

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

راه‌حل يكم: افزايش حافظه مورد استفاده SQL Server از يك به سه گيگابايت. اين كار را بايد با دستكاري در فايلBoot.ini سرور 2000 يا 2003 كه SQL Server در آنجا قرار دارد، انجام دهيد. براي اطلاع از چگونگي انجام‌دادن اين كار، به سايت پشتيباني مايكروسافت رجوع كنيد نشاني(http://support.microsoft.com) و در آنجا عبارت AWE SQLServer را جستجو كنيد تا مقالاتي كه در اين زمينه وجود دارد، در دسترس شما قرار گيرد.

راه‌حل دوم: ارتقاي سيستم‌عامل ويندوز 2000 به 2003 كه در فرايند caching، سيستم‌عاملي پايدارتر و هوشمندتر قلمداد مي‌شود.

راه‌حل سوم: استفاده از پردازنده‌هاي Xeon به جاي پنتيوم 4 در سرور. اين پردازنده‌ها به دليل ويژگيhyper threading، مي‌توانند سرعت پردازش اطلاعات در سمت سرور را به دو برابر افزايش دهند.

راه‌حل چهارم: هاردديسك‌هاي اسكازي با 15‌هزار دور در دقيقه و سرعت سه مگابيت در ثانيه و يا Sata با 10‌هزار دور در دقيقه و دو مگابيت در ثانيه نسبت به هاردديسك‌هاي IDE با 7500 دور در دقيقه و يك مگابيت در ثانيه از عملكرد بهتري برخوردارند.پس درصورت امكان، از اين ادوات ذخيره‌سازي در سرور بانك اطلا‌عاتي استفاده كنيد.

 راه‌حل پنجم: جداسازي محل ذخيره فايل‌هاي داده‌اي بانك اطلاعاتي (mdf) و فايل‌هاي لاگ (ldf) برروي دو هاردديسك مختلف يا دو ديسك مختلف از يك RAID. معمولاً براي نگهداري mdf استفاده از RAID1 و براي ldf  استفاده از RAID5 توصيه مي‌شود.

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

راه‌حل ششم: راه‌حل آخر و در واقع مشكل‌ترين راه، تقسيم بانك اطلاعاتي (در صورت لزوم) به دو بانك جدا از هم و بر روي دو سرور مختلف است. به عنوان مثال، فرض كنيد كه عمليات روزانه سيستم شما به دو دسته تقسيم مي‌شود: دسته يكم عملياتي است كه طي آن بايد از آخرين اطلاعات موجود بر روي سيستم استفاده شود و هرگونه تغيير نيز بايد فوراً  در همان لحظه بر روي بانك سيستم‌ها (جداول مربوط به آن‌ها كه به
online transactional Processing) OLTP) مشهورند،) اعمال شود.

دسته دوم نيز شامل عملياتي است كه طي آن مي‌توان از اطلاعات چند ساعت يا چند روز پيش نيز استفاده كرد و لزومي به داشتن آخرين اطلاعات به صورت لحظه‌اي نيست. به عنوان نمونه فرض كنيد تعدادي از گزارش‌هاي سيستم مربوط به تحليل آماري فرايندهاي مختلف ماه پيش است. بنابراين بايد تمهيداتي انديشيده شود تا تهيه اين گزارش‌ها -كه البته ارزش آني ندارند، اما به دليل بازه زماني و نوع تحليل آن‌ها، منابع زيادي از سيستم براي خواندن اطلاعات انبوه و تجزيه و تحليل صرف مي‌شود، بايد بر روي سرور دومي در شبكه كه به
سيستم‌هاي online Analytical Processing) OLAP) مشهورند قرار گيرند تا در كار كساني كه مشغول  كار با OLTP  هستند، خللي ايجاد نشود.

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

توسعه عرضي (Scale out) 

نام خانوادگي	نام	شماره تامين اجتماعي بيمه شده	شماره سريال بيمه شده
ب	الف	ايندكس خوشه‌اي يا خاصيت منحصر به فرد	كليد اوليه ايندكس غيرخوشه‌اي

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

1 - از ساخت جداولي كه فاقد كليد اوليه (Primary key) باشند، خودداري كنيد. كليد اوليه علاوه بر جلوگيري از  ورود اشتباه اطلاعات از سوي كاربر، به دليل داشتن خاصيت منحصر به‌فرد بودن (Unique) به سريع‌تر پيدا‌شدن ركورد موردنظر از همان جدول كمك شاياني مي‌كند. تا آنجا كه براي سيستم امكان دارد براي كليد اوليه از فيلدهاي عددي استفاده كنيد.

استفاده از فيلدهاي رشته‌اي (string) مثلchar ياvarchar به‌عنوان كليد اوليه، كمي كندتر از فيلدهاي عددي است. از انتخاب فيلدهاي رشته‌اي با طول زياد و يا فيلدهايي مثل Memo ،Text و Picture به عنوان كليد اوليه نيز اجتناب كنيد.

2 - تمام كليدهاي خارجي (Foreign key) قابل تعريف در بانك را تعريف كنيد. وجود كليدهاي خارجي نيز علاوه بر جلوگيري از اشتباه كاربر در واردكردن يا حذف اطلاعات، موجب مي‌شود هنگام لينك شدن (join) جداول مادر و فرزند از طريق كليدهاي خارجي، سيستم سرعت بيشتري را در انجام دستورات Select شما از خود نشان دهند.

3 - همان‌طور كه مي‌دانيد ايندكس‌ها در دو نوع خوشه‌اي (cluster) و غيرخوشه‌اي (Non cluster) قابل ساخت هستند. ايندكس‌ها باعث افزايش سرعت خواندن اطلاعات به‌وسيله دستور Select مي‌شوند.
ما تعريف بي‌رويه آن‌ها در سيستم نيز باعث كاهش سرعت اجراي دستورات فرايندي مثل Insert ،Update و Delete  مي‌شود. بنابراين سعي كنيد ايندكس‌هاي ضروري را در سيستم تعريف كنيد. اما در اين راه دست و دلبازي بي‌مورد از خود نشان ندهيد. به عنوان مثال، فرض كنيد در يك شعبه اداره تأمين اجتماعي، جدولي ويژه تعريف بيمه‌شدگان به شكل زير وجود دارد.  

مبلغ	تاريخ	شماره سريال
1	جزء دوم كليد اوليه	جزء اول كليد اوليه
1		كليد خارجي از جدول قبل
1	جزئي از ايندكس خوشه اي	جزئي از ايندكس خوشه اي

جدولي نيز براي نگهداري وجه حق بيمه از بيمه‌شدگان نيز تعريف شده است.

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

نكته مهم ديگر اين است كه لا‌زم است تمام كليدهاي اوليه جداول ايندكس داراي باشند (خوشه‌اي يا غيرخوشه‌اي) نكته ديگر در زمان ساخت ايندكس‌ها فاكتور پرشدن (Fill Factor) آن‌ها است. اين فاكتور در واقع بيانگر ميزان فضاي مياني است كه بايد براي ركوردهايي كه در آينده درج يا حذف مي‌شوند، خالي نگه داشته شود. بنابراين اگر احساس مي‌كنيد جدول شما به‌طور مداوم مورد عمليات حذف و درج (Insert،‌Delete) قرار مي‌گيرد، اين فاكتور را پايين (مثلاً 30 درصد) انتخاب كنيد. اما اگر صرفاً عمليات درج بر روي يك جدول انجام مي‌گيرد و ميزان حذف اطلاعات از آن بسيار كم است، مي‌توانيد اين ميزان را به ارقام بالاتر مثلاً 90 درصد افزايش دهيد. زيرا اين نوع جداول نيازي به داشتن فضاي خالي مياني براي ركوردهايي كه در آينده جانشين ركوردهاي حذف شده مي‌شوند، ندارد.

اين مسئله براي ايندكس‌هايي كه برروي ديدها (Indexed Views) ساخته مي‌شوند نيز صادق است. به‌طوركلي گذاشتن ايندكس برروي ديدها به افزايش سرعت آن‌ها كمك مي‌كند. در اين حالت، كليه مطالب مذكور از جمله سياست استفاده از ايندكس‌هاي خوشه‌اي و غيرخوشه‌اي و همچنينFill Factor در جداول، در مورد ديدها نيز عيناً بايد رعايت گردد.

4 - در هنگام نوشتن دستورات Select يا در هنگام ساختن ديدها، از استفاده بي‌مورد از پارامترهاي پردازش مثلDistinct و LIKE order by و لينك‌هاي خارجي (Outer join) اجتناب كنيد. در صورت استفاده از اين پارامترها، مطمئن باشيد كه گذاشتن آن‌ها كاملاً ضروري است و چاره ديگري نداريد.

5 - از واگذاري پردازش‌هاي رياضي يا آماري سنگين و مداوم به سرور بانك اطلاعاتي بپرهيزيد. مثلا‌ً به دستور زير نگاهي بيندازيد.

SELECT( a*( b+c )) +( d* E+F))  %G/H From ... WHERE ...

به‌جاي اين‌كار، مي‌توانيد ابتدا با استفاده از يك Select معمولي مثل Select a ,b ,c ,d ,E ,F ,G ,h  فيلدهاي موردنظر را در حافظه كلاينت لود كنيد و سپس عمليات رياضي مذكور را در همان جا انجام دهيد. با اين كار پردازشي كه سرور بايد مثلاً براي 50 كلاينت در عرض چند دقيقه انجام دهد، بين آن 50 كلاينت تقسيم مي‌شود و در واقع هر كلاينت فقط سهم پردازشي مربوط به خود را انجام مي‌دهد.

6 - گاهي عمل اجتماع بين دو Select  توسط دستور Union به شدت بر عملكرد و سرعت سيستم اثر منفي مي‌گذارد. بنابراين در صورت امكان به جاي استفاده از روش مذكور، از روش‌هاي ديگري كه هدفتان را برآورده نمايد، استفاده كنيد.

7 - سعي نماييد فيلدهايي كه از نظر مقدار و ارزش با يكديگر مقايسه مي‌شوند، از يك جنس (type) باشند. در غير اين‌صورت سيستم‌مجبور مي‌شود به طور ضمني، عمل تبديل داده را انجام دهد كه كمي برايش وقت‌گير است. به مثال زير توجه كنيد و فرض بگيريد فيلد customer ID در جدول customers از جنس nchar تعريف شده است. 

Declare@custID char (5)
Set @ CustID =' FDLKO'
Select * From Customers where customerID=@custID

8 - تاحد ممكن از به كار بردن توابع (چه پيش ساخته توسط SQL Server و چه ساخته شده توسط كاربر) در قسمت WHERE يا order by اجتناب كنيد. مثال زير نمونه‌اي از اين مورد است:

Select * Form orders Where DateAdd (Day, 15, orderdata) = '2005/23/07'

9 - در زمان نوشتن تريگر (trigger) بر روي جداول يك بانك اطلاعاتي، از نوشتن تعداد زيادي دستورالعمل در آن‌ها خودداري كنيد. به عبارت ديگر تريگرها را تا حد امكان كوتاه كنيد و دستورالعمل‌ پياد‌ه‌سازي آن‌ها را كم نماييد.
10 - در زمان ساخت كرسر (cursor) درون توابع، روال‌ها و تريگرها از پارامترهاي Forward only يا read only و همچنين local استفاده كنيد تا SQL Server با دانستن اين نكته كه شما قصد تغيير داده‌ها در كرسر موردنظر را نداريد، تغيير يافتني بودن آن‌ها را درنظر نگيرد و آن را براي شما سريع‌تر بسازد.

11 - در صورتي كه تكه‌اي از برنامه شما به ساخت يك جدول موقت (temporary table) نياز دارد، اين كار بايد با ظرافت خاصي صورت بگيرد. اصولا SQL Server براي اجتناب برنامه‌نويسان از ساخت جداول موقت، از يك نوع داده(Data type) خاص به نام Table پشتيباني مي‌كند كه مزيت استفاده از آن اين است كه به‌جاي هاردديسك، در حافظه رم قرارگرفته است و در نتيجه نسبت به جداول موقت سرعت بيشتري دارد.

اما به ياد داشته باشيد كه استفاده بي‌رويه از اين نوع داده، حافظه زيادي را صرف مي‌كند كه مي‌تواند باعث كاهش كارايي سيستم شود. بنابراين اگر احساس مي‌كنيد تعداد جداول موقت، ركوردهاي آن‌ها و زمان استفاده از آن‌ها كم است، از اين نوع داده استفاده كنيد. در غير اين‌صورت، راه‌حل جدول موقت را انتخاب كنيد.
 
12-  قفل‌گذاري بر روي ركوردهايي كه در حال خواندن، درج شدن، حذف شدن يا تغيير كردن هستند، هميشه از مباحث مهم بانك‌هاي اطلاعاتي بوده‌است. همان‌طور‌كه مي‌دانيد يك فرايند (Transaction) شامل يك يا چند دستورالعمل SQL است كه يا بايد همگي به صورت موفقيت‌آميز اجرا شوند (committed) يا در صورت ايجاد خطا در زمان اجراشدن يكي، اجراي بقيه نيز منتفي شود (Rollbacked).
 

ايندكس گذاري برروي ديده ها(Indexed Views) يكي از بهترين راههاي فوري جهت افزايش سرعت جستجو بر روي ديدهااست. در حالت عادي گزينه Manage Indexes بر روي ديدها قابل انتخاب نيست مگر آنكه اولا كليه جداول يا ديدهاي موجود در آن، خود داراي ايندكس باشد و دوم اينكه كليه ديدهاي موجود در آن و هم خود ديد مورد نظر با دستور زير ساخته شده باشند.
Create View....Whit Schema Binding AS....... 

فرايند به دو صورت قابل پياده‌سازي است. اين كار يا با استفاده از دستورات Begin trans و Committrans انجام مي‌شود كه به آن حالت صريح (Explicit) مي‌گويند يا به صورت ضمني (Implicit) صورت مي‌گيرد كه در آن اثري از دو دستور مذكور ديده نمي‌شود و هر دستور SQL يك فرايند مجزا به حساب مي‌آيد. در هر دو روش ركوردهايي كه تحت‌تأثير دامنه فرايند قرار مي‌گيرند، توسط سيستم قفل مي‌گردند و براي ديگر كاربران نيز غيرقابل استفاده مي‌شوند و در نتيجه باعث كاهش سرعت كار آن‌ها به دليل ايجاد انتظار براي آزاد شدن ركوردها مي‌شود.
 
بنابراين براي رسيدن به حداكثر كارايي سيستم، بايد از ايجاد قفل‌هاي بي‌مورد بر روي ركوردهاي جداول بانك اطلاعاتي جلوگيري كرد. اين كار با استفاده از دستور SET Transaction Isolation Level Read Uncommitted براي فرايندهاي صريح (قبل از شروع فرايند، يعني قبل از دستور (begin Trans  و يا استفاده از دستور WITH NOLOCK  براي فرايندهاي ضمني (پس از قسمت From هر دستور SQL) قابل انجام است. در مورد مسئله فرايندها و انواع قفل‌گذاري مطالب خواندني زيادي در سايت مايكروسافت وجود دارد كه درصورت تمايل مي‌توانيد به آن‌ها نيز مراجعه كنيد.

13 - روال‌هاي ذخيره شده (stored Procedures) پس از هر اجرا، به ازاي هر دستورالعملي كه اجرا مي‌كنند،  جهت اطلاع برنامه فراخوان (كلاينت) از موفقيت‌آميز بودن اجراي آن دستور SQL، پيغامي را به سمت آن برنامه مي‌فرستند. اين مسئله باعث افزايش ترافيك شبكه در اثر فرستادن مداوم پيغام ازSP به سمت كاربر مي‌شود. با تايپ دستور زير در ابتداي يكSP، مي‌توانيد آن را از انجام اين كار منع كنيد:
SET NOCOUNT ON

نتيجه‌گيري‌

مطالب فوق تنها قسمتي از راهكارهاي قابل انجام براي رسيدن به‌سرعت و بازدهي مناسب در بانك‌هاي اطلا‌عاتي مبتني بر SQL Server است. در ضمن‌ بايد اين نكته را هم درنظر داشت كه اصولا‌ً در سيستم‌هاي بزرگ اطلا‌عاتي تحت شبكه، توپولوژي و نوع اجزاي موجود در شبكه از اهميت بسيار زيادي در تعيين سطح كارايي يك بانك اطلا‌عاتي برخورداراست. گاهي حتي در حالي‌كه بهترين طراحي و پيكربندي SQL Server براي يك بانك اطلا‌عاتي انجام شده، يك اشتباه كوچك در سطح شبكه مي‌تواند تمام زحمات را بر ‌باد دهد يا مثلا‌ً يك سهل‌انگاري در نوشتن روال‌هاي ذخيره شده يا تريگرها مي‌تواند سيستم را به‌يك لوپ (Loop) پردازشي بي‌نهايت ببرد و باعث افت شديد سرعت اجراي برنامه‌ها شود. بنابراين در اين‌گونه سيستم‌ها، استفاده بجا و مناسب از منابع سيستم و شبكه و دقت در طراحي و پياده‌سازي جداول، ديدها، روال‌هاي ذخيره‌شده و تريگرها بسيار مهم  و حياتي است.

چند افزونه مفید برای فایرفاکس

Organize Search Engines 1.7

https://firefox.maltekraus.de/extensions/organize-search-engines

Tab Mix Plus 0.3.8.6

http://tmp.garyr.net

Firebug 1.8.4

http://getfirebug.com

IDM CC 7.3.14

http://www.internetdownloadmanager.com

Redirector 2.6

http://www.einaregilsson.com/redirector

RightToClick 2.7.8

http://netticat.ath.cx/extensions.html

پیغام خطا Package does not support server operating systems هنگام نصب پلاگین windows media player

در هنگام نصب پلاگین windows media player برای فایرفاکس بر روی ویندوز سرور 2003 (windows server 2003) به یک پیغام خطا برخورد کردم، به شرح زیر

Package does not support server operating systems

پس از جستجو، راه حل آن را یافتم

فایل exe پلاگین را می توانید از اینجا دانلود کنید

پسوند آن را از exe به rar تغییر دهید و آن را توسط برنامه winrar از حالت فشرده درآورید

نتیجه یک فایل msi و چند فایل دیگر است که ما با آن فایل msi کار داریم

به اینجا رفته و Windows® Server 2003 SP1 Platform SDK را با توجه به ورژن ویندوز خود، دانلود کنید.

آن را بر روی کامپیوتر خود نصب کنید. از میان برنامه های این sdk، برنامه orca را از فولدر Program Files\Microsoft Platform SDK\Bin نصب کنید.

بوسیله برنامه orca آن فایل msi مرحله قبل را باز کنید و تغییرات زیر را در آن اعمال کنید و آن را save کنید، سپس پلاگین ویندوز مدیا پلیر را با خیال راحت نصب کنید.

تغییرات:

در سمت چپ به دنبال LaunchCondition بگردید و آن را انتخاب کنید

در پنجره سمت چپ، بر روی MsiNTProductType=1 راست کلیک کنید و گزینه Drop Row را بزنید

بر روی VersionNT >= 600 OR ((VersionNT = 501 OR VersionNT = 502) AND ServicePackLevel >= 2) یک کلیک کنید، به حالت قابل تغییر در می آید، آن را به VersionNT >= 600 OR ((VersionNT = 501 OR VersionNT = 502) AND ServicePackLevel >= 1) تغییر دهید.

به منوی فایل رفته save را بزنید و برنامه را ببندید.

برنامه msi آماده اجرا است