SQLIO is a tool provided by Microsoft which can also be used to determine the I/O capacity of a given configuration.
It can be downloaded here.
Brent Ozar has a nice introduction about its features and a walkthrough on how to use it here.
SQLIO's output comes in a textfile which isnt ordered nicely yet.
I found a powershell script to directly import it into Excel.
Its from jonathan kehayias and can be found/downloaded here.
A few sqlio parameters for my own reference below:
Creating:
sqlio -kW -s10 -fsequential -o8 -b8 -LS -Fparam.txt timeout /T 10
Generating output, example/baseline set:
sqlio -kW -t2 -s120 -dH -o1 -frandom -b64 -BH -LS Testfile.dat
sqlio -kW -t2 -s120 -dH -o1 -fsequential -b64 -BH -LS Testfile.dat
sqlio -kR -t2 -s120 -dH -o1 -frandom -b64 -BH -LS Testfile.dat
sqlio -kR -t2 -s120 -dH -o1 -fsequential -b64 -BH -LS Testfile.dat
sqlio -kW -t8 -s120 -dH -o1 -frandom -b64 -BH -LS Testfile.dat
sqlio -kW -t8 -s120 -dH -o1 -fsequential -b64 -BH -LS Testfile.dat
sqlio -kR -t8 -s120 -dH -o1 -frandom -b64 -BH -LS Testfile.dat
sqlio -kR -t8 -s120 -dH -o1 -fsequential -b64 -BH -LS Testfile.dat
sqlio -kW -t32 -s120 -dH -o1 -frandom -b64 -BH -LS Testfile.dat
sqlio -kW -t32 -s120 -dH -o1 -fsequential -b64 -BH -LS Testfile.dat
sqlio -kR -t32 -s120 -dH -o1 -frandom -b64 -BH -LS Testfile.dat
sqlio -kR -t32 -s120 -dH -o1 -fsequential -b64 -BH -LS Testfile.dat
sqlio -kW -t64 -s120 -dH -o1 -frandom -b64 -BH -LS Testfile.dat
sqlio -kW -t64 -s120 -dH -o1 -fsequential -b64 -BH -LS Testfile.dat
sqlio -kR -t64 -s120 -dH -o1 -frandom -b64 -BH -LS Testfile.dat
sqlio -kR -t64 -s120 -dH -o1 -fsequential -b64 -BH -LS Testfile.dat
woensdag 16 maart 2011
Scripting jobs sql2008, fun issue
Ofcourse always know what you are doing when well...when u do anything but never assume stuff...
Like i did with this example, if u decide to copy a job in the sqlserveragent (sql2008) by scripting the job and then run it under a different name on the same instance (change jobname in script) then u have 2 jobs which have the same jobsteps / schedules.
Only difference is the name.
Don't assume u can change the schedule in the newly created job and it will only apply for that job.
Nope, the fact that u scripted it from an existing job makes it have the same schedule_id and thus if u change the schedule properties for job 2 u will also change the schedule properties for job 1.
U can delete the schedule of a job, the schedule itself will still exist but will not be referenced to that job anymore.
Its a different discussion on why u want to do this in the first place (getting a base layout for a new job with lots of jobsteps in our case) but don't assume its a different and unique object all together.
Like i did with this example, if u decide to copy a job in the sqlserveragent (sql2008) by scripting the job and then run it under a different name on the same instance (change jobname in script) then u have 2 jobs which have the same jobsteps / schedules.
Only difference is the name.
Don't assume u can change the schedule in the newly created job and it will only apply for that job.
Nope, the fact that u scripted it from an existing job makes it have the same schedule_id and thus if u change the schedule properties for job 2 u will also change the schedule properties for job 1.
U can delete the schedule of a job, the schedule itself will still exist but will not be referenced to that job anymore.
Its a different discussion on why u want to do this in the first place (getting a base layout for a new job with lots of jobsteps in our case) but don't assume its a different and unique object all together.
Abonneren op:
Posts (Atom)