Lets take a break from SQL and talk a little poker for those who give a shit.
This one is for all my fellow poker players, fans, enthusiasts etc... Most reading this blog who know me know I am an avid player and i do my best to make it to the WSOP if I can. While I normally stick to mixed game events (HORSE, 8Game etc) Every once in a blue I will play a No Limit Event either 6 max, shoot out, or heads up style.
While playing the 2011 WSOP this hand came up. Note I am not one for bad beat stores, as I have given many, and have taken many over the years and it sure has balanced out IMO. What I am interested in is if ANY math based player at all could have possibly NOT went broke when this hand / situation occurred or was it just destiny. I do NOT see how so spoiler alert I DID INDEED GO BROKE with this hand.
Event - $2500 No Limit Hold'Em
Set The Stage:
Blinds are 400/800
My Stack = 52,000
UDG Stack = 44,000
UDG+1 Stack = 115,200
UDG+2 Stack = 88,000
Avg Stack = 28,000
My Position = Button
Under The Gun player opens the pot for 2800 (his standard raise). This guy was loose to say the least. He had done this before and shown multi-way pots where he just decided to go nuts and make this play with 6-8 and 9-2 twice in the same orbit, and at the lower levels was even worse. UDG+2 and +3 both call... Just to add a bit more light to the subject, UDG+2 was your average ABC player, +3 was pretty solid and had some trickery to him. Very good all around player.
Gets to me I look down at QH - QD. I know I have to re-raise (in my mind anyway) I had no desire to play this hand even in position 4 ways. I opted to raise to 5600. My thinking on why a small re-pop was to me it would look super strong with others in the pot, and in the event I got re-raised because the nut was in the pot the person re-popping me would pretty much be polarizing his range as I had not show down a single bad hand in 8 hours of play. UDG folds (odd), UDG +1 flats (odder) UDG +3 folds (oddest). We take the flop heads up which is what I thought at the time I wanted... or so I THOUGHT.
Pot Size - 16,800
Flop - Qc-8h-8c (bingo!)... or so i THOUGHT!
Suckpot as I will call him checks, I bet out 1/2 pot. and he flat calls. This REEKED of over pair as I could not see him calling with anything that had an 8 in his hand. 7-8 suited, no dice not him. not with all that pre-flop action this is a guy who folded jacks on the button to a 3 bet pot when he had both the other stacks covered. A bit nitty to say the least. Remembering that Jacks fold. (he folded face up) is kind of what got the idea of 8-8 out of my head as well.
Pot Size - 36,400
Turn - 2c
Board - Qc-8h-8c-2c
Seems like a great card for me, but then again they ALL do at this point. Now Suckpot bets out 17,500. My thought was to ship right here but thinking of the hands other than 8-8 he could have had, there was nothing that I didn't want to see. AA, KK, AcQx XcXc (most likely) 78, Q8, 82 (for arguments sake) I opt to just call which proved to be my fatal mistake HOWEVER even if I had shoved. I did NOT IMO have much fold equity at all as the pot would have been 53,900 and I only had another 20,500. I already had 50% of my stack invested.
My hope is that he has either hit his flush, or made a lower boat. Well nothing, and I do mean NOTHING could have prepped me for what happened on the river.
River - 2s
Board - Qc-8h-8c-2c-2s
He checks pretty much knowing as well as I did before the river I was going to ship it. After seeing what he had even if i didn't ship it, he would have moved in on me if I bet say 1/2 my remaining stack to make it look like a real REAL sucker bet anyway. As soon as he check I insta-shove. He snap calls. Now yes, what I seen was sick, what he beat me with was horrible, and I can go on and on about how bad it was to be felted by this hand and all of that but I will save all of that for another article when i feel like complaining. He tables 2h-2d. Gross yes, but my question for this article and anyone who cares to analyze this hand from a math / game theory perspective is this...
Is there ANY way I could have played this hand differently and not went broke. If so please explain how and why because maybe there is a line I have missed or something I didn't see. How do I ever come away from that hand with chips in front of me?
encodeThis - a quest in SQL or sometimes SQ-Hell
Tuesday, June 25, 2013
Repost from Davild Klein's blog : Programatic SSIS
Location of Microsoft.SqlServer.Dts.Runtime when Programmatically Running an SSIS 2008 Package. If you are having problems finding the DLL to reference to programmatically run an SSIS Package, you should find it in the following location:
%Program files%\Microsoft SQL Server\100\SDK\Assemblies\Microsoft.SQLServer.ManagedDTS.dll
Take note that you may have several directories under %Program files%\Microsoft SQL Server\
If you have upgraded through different versions of SQL Server. Try looking through each of these to find the correct version of Microsoft.SQLServer.ManagedDTS.dll
So assuming you installed it on C:\ you should find it in the following locations:
For SQL 2005:
C:\Program files\Microsoft SQL Server\90\SDK\Assemblies\Microsoft.SQLServer.ManagedDTS.dll
For SQL 2008:
C:\Program files\Microsoft SQL Server\100\SDK\Assemblies\Microsoft.SQLServer.ManagedDTS.dll
*Updated for SQL 2012*
C:\Program Files\Microsoft SQL Server\110\SDK\Assemblies
** Make sure you have the Client SDK installed or it may be a little hard to find =]
%Program files%\Microsoft SQL Server\100\SDK\Assemblies\Microsoft.SQLServer.ManagedDTS.dll
Take note that you may have several directories under %Program files%\Microsoft SQL Server\
If you have upgraded through different versions of SQL Server. Try looking through each of these to find the correct version of Microsoft.SQLServer.ManagedDTS.dll
So assuming you installed it on C:\ you should find it in the following locations:
For SQL 2005:
C:\Program files\Microsoft SQL Server\90\SDK\Assemblies\Microsoft.SQLServer.ManagedDTS.dll
For SQL 2008:
C:\Program files\Microsoft SQL Server\100\SDK\Assemblies\Microsoft.SQLServer.ManagedDTS.dll
*Updated for SQL 2012*
C:\Program Files\Microsoft SQL Server\110\SDK\Assemblies
** Make sure you have the Client SDK installed or it may be a little hard to find =]
Cleaning up "Excel Objects" is directly related to braining yourself with a claw hammer.
At first I really did blame myself, I figured no way could something "so simple" be "so difficult" being the nit that I am, I hit my favorite site Stack Overflow for some relief from the Gods of development. To my surprise after seeing this thread : http://stackoverflow.com/questions/158706/how-to-properly-clean-up-excel-interop-objects-in-c I am not sure there is an "elegant" way to do it at all. God Bless Microsoft!!
Thursday, May 9, 2013
Dumping IO Stats to Powershell... Get em Girl!
Hello All,
A 2 part post this month, i guess i finally removed head from arse and got around to posting updates. First a super useful query for IO stats of log and data files. Please note these are at file level. This may exist already and im sure there are better ways to do this, but since i have been going through a ton of logs and data files at work recently, i figured it was worth a post.
[code]
SELECT DB_NAME(tblFileStat.database_id) AS databaseName ,tblFileStat.file_id ,tblMasterFile.physical_name ,tblIOPending.io_pending ,tblFileStat.io_stall_read_ms ,tblFileStat.io_stall_write_ms ,tblFileStat.file_handle ,tblIOPending.NumberofIOPendingRowsFROM sys.dm_io_virtual_file_stats(NULL, NULL) tblFileStatINNER JOIN ( SELECT io_handle , MAX(io_pending) AS io_pending ,COUNT(*) AS NumberofIOPendingRows FROM sys.dm_io_pending_io_requests GROUP BY io_handle) tblIOPendingON tblFileStat.file_handle = tblIOPending.io_handleINNER JOIN sys.master_files tblMasterFileON tblFileStat.database_id = tblMasterFile.database_idAND tblFileStat.file_id = tblMasterFile.file_idORDER BY tblFileStat.io_stall_read_ms DESC
[/code]
Second for a little bit of comic relief a list of DBA jargon i am entitling WTF did he just say. Note I have never in 15 years heard any of these phrases used but I still think they are pretty funny. http://www.brentozar.com/archive/2012/10/learn-speak-dba-slang-terms/
A 2 part post this month, i guess i finally removed head from arse and got around to posting updates. First a super useful query for IO stats of log and data files. Please note these are at file level. This may exist already and im sure there are better ways to do this, but since i have been going through a ton of logs and data files at work recently, i figured it was worth a post.
[code]
SELECT DB_NAME(tblFileStat.database_id) AS databaseName ,tblFileStat.file_id ,tblMasterFile.physical_name ,tblIOPending.io_pending ,tblFileStat.io_stall_read_ms ,tblFileStat.io_stall_write_ms ,tblFileStat.file_handle ,tblIOPending.NumberofIOPendingRowsFROM sys.dm_io_virtual_file_stats(NULL, NULL) tblFileStatINNER JOIN ( SELECT io_handle , MAX(io_pending) AS io_pending ,COUNT(*) AS NumberofIOPendingRows FROM sys.dm_io_pending_io_requests GROUP BY io_handle) tblIOPendingON tblFileStat.file_handle = tblIOPending.io_handleINNER JOIN sys.master_files tblMasterFileON tblFileStat.database_id = tblMasterFile.database_idAND tblFileStat.file_id = tblMasterFile.file_idORDER BY tblFileStat.io_stall_read_ms DESC
[/code]
Second for a little bit of comic relief a list of DBA jargon i am entitling WTF did he just say. Note I have never in 15 years heard any of these phrases used but I still think they are pretty funny. http://www.brentozar.com/archive/2012/10/learn-speak-dba-slang-terms/
What the hell was that constraint called?
Over the years I have been guilty so many times of writing a rollback script that rolls column additions to a table. Which is essentially a script that will drop the added columns. When i create a new column with a default value i ALWAYS use a constraint name which i created. In the event you inherit someone else database who does not (not mine of course) :) forgetting to drop the default value constraint (which is something only an inexperienced DBA would do NOT ME of course) :)
As luck would have it if you forget to add your own name SQL Server will add one for you. with a very easy to remember name. If DF__Beta_foo__bar__5629CD9C is easy to remember that is. So all of that being said, here is a quick script to get a list of all the constraints and the tables / columns they are on so you can easily add them to your rollback script.
As luck would have it if you forget to add your own name SQL Server will add one for you. with a very easy to remember name. If DF__Beta_foo__bar__5629CD9C is easy to remember that is. So all of that being said, here is a quick script to get a list of all the constraints and the tables / columns they are on so you can easily add them to your rollback script.
SELECT
b.name AS TABLE_NAME, d.name AS COLUMN_NAME, a.name AS CONSTRAINT_NAME,
c.text AS DEFAULT_VALUE
FROM
sys.sysobjects a
INNER JOIN (
SELECT name, id FROM sys.sysobjects WHERE xtype = 'U'
) b
ON ( a.parent_obj = b.id )
INNER JOIN sys.syscomments c
ON ( a.id = c.id )
INNER JOIN sys.syscolumns d
ON ( d.cdefault = a.id )
WHERE
a.xtype = 'D'
ORDER BY
b.name, a.name
Toyota and Database nothing in common, until NOW!
Turn the key, hear the engine catch go to put it in drive and... shit Darn it golly gee a stall. This is NOT just for cars anymore. One of the biggest performance issue indicators I have ever used in practice to check for DB issues has been an IO Stall test metric. In days of old, you know when 16 bit gaming consoles made you the man if you had one, and Mortal Kombat was THE GAME to play.. (still is now by the way if anyone is on PSN and wants to take a beating ProphetDE come find me) I had no monitoring software. So I used the script below and dumped the results to a text file. Now that tools have come so far (As have video game consoles) I am using Red Gate's SQL Monitor. The new version gives you the ability to add custom metrics. Below I will explain IO Stalls, what they mean, and how to track them.
What causes an IO stall?
In our case there are 3 main causes of IO stalls.
1. A poorly performing disk - Now a days this is almost ALWAYS caused by a misconfiguration in the SAN. I now understand why SAN Admins get paid as much as they do.
2. Poorly defined / written queries. I don't just mean the obvious Oh Johnny used a cursor to update 22.7 million rows one at a time because he thinks set based operations are the antichrist. I mean all issues some silly some not so much.
3. Overloaded disks. You may or may not hear the term "data bursts" often. I will not go into the explanation. What I will say is there is a wonderful all inclusive article on disks, how they work, how they don't work and data bursts, which can be found here: http://www.symantec.com/connect/articles/getting-hang-iops
Needless to say just like you do not want your Toyota to stall, you do not want your database to stall either. Troubleshooting database stalls, and disk contention issues can be for lack of a better term a real pain in the proverbial arse. The script will essentially check the average time of reads and writes in MS / number of total reads and writes. Ideally you never want to exceed 100MS. This is just a general number with larger systems you may and that could be fine. The 100MS baseline is simply the guideline i use.
[code]
SELECT CAST(SUM(io_stall_read_ms + io_stall_write_ms) / SUM(1.0 + num_of_reads + num_of_writes) AS NUMERIC(10,1)) AS [avg_stall]
FROM sys.dm_io_virtual_file_stats(DB_ID(), NULL)
WHERE FILE_ID = 2;
[/code]
Now the all important question: "John that metric just returned 12,948,102MS what the hell do I do"
Well grasshopper its not that simple... Let me rephrase it COULD BE that simple, but may not be. If you are using a virtual environment, the first thing I would recommend trying would be to allocate a few more processors and memory to the cause. A good start would be to double what you currently have. This may also be practical for your physical environment and if it is bravo!!
Secondly (or if adding hardware is a no go) I would recommend getting very familiar with SQL profiler. Go through and run those overly complex stored procedures you inherited from Bob who is now working at Kinko's because he decided it would be a good idea to write them. "What do you mean writing dynamic SQL using a cursor to update 22.7M rows one at a time for only one field is a bad idea?!" Try taking just one of those and re-writing er... re-factoring it. Then run again, you will be surprised how often I hear "Wow all i did was re-write one sproc and I am getting a 22% performance boost.
Finally I would recommend a SAN Admin. If you do NOT have one, and your company does not want to staff a proper one fine. I would then say get one to re-configure the SAN and document the new subsystem for you. If your infrastructure is to large and contracting someone, or hiring someone perm is a no go, I would make a strong case to management why they need to fork over the 4 - 6K and get someone trained in the area.
Trust me I didn't think it was a necessary evil... it IS. Use that script and keep the above in mind, and I can assure you your Toyota will be purring like the day you got her off the show room floor and took her for that first test drive.
What causes an IO stall?
In our case there are 3 main causes of IO stalls.
1. A poorly performing disk - Now a days this is almost ALWAYS caused by a misconfiguration in the SAN. I now understand why SAN Admins get paid as much as they do.
2. Poorly defined / written queries. I don't just mean the obvious Oh Johnny used a cursor to update 22.7 million rows one at a time because he thinks set based operations are the antichrist. I mean all issues some silly some not so much.
3. Overloaded disks. You may or may not hear the term "data bursts" often. I will not go into the explanation. What I will say is there is a wonderful all inclusive article on disks, how they work, how they don't work and data bursts, which can be found here: http://www.symantec.com/connect/articles/getting-hang-iops
Needless to say just like you do not want your Toyota to stall, you do not want your database to stall either. Troubleshooting database stalls, and disk contention issues can be for lack of a better term a real pain in the proverbial arse. The script will essentially check the average time of reads and writes in MS / number of total reads and writes. Ideally you never want to exceed 100MS. This is just a general number with larger systems you may and that could be fine. The 100MS baseline is simply the guideline i use.
[code]
SELECT CAST(SUM(io_stall_read_ms + io_stall_write_ms) / SUM(1.0 + num_of_reads + num_of_writes) AS NUMERIC(10,1)) AS [avg_stall]
FROM sys.dm_io_virtual_file_stats(DB_ID(), NULL)
WHERE FILE_ID = 2;
[/code]
Now the all important question: "John that metric just returned 12,948,102MS what the hell do I do"
Well grasshopper its not that simple... Let me rephrase it COULD BE that simple, but may not be. If you are using a virtual environment, the first thing I would recommend trying would be to allocate a few more processors and memory to the cause. A good start would be to double what you currently have. This may also be practical for your physical environment and if it is bravo!!
Secondly (or if adding hardware is a no go) I would recommend getting very familiar with SQL profiler. Go through and run those overly complex stored procedures you inherited from Bob who is now working at Kinko's because he decided it would be a good idea to write them. "What do you mean writing dynamic SQL using a cursor to update 22.7M rows one at a time for only one field is a bad idea?!" Try taking just one of those and re-writing er... re-factoring it. Then run again, you will be surprised how often I hear "Wow all i did was re-write one sproc and I am getting a 22% performance boost.
Finally I would recommend a SAN Admin. If you do NOT have one, and your company does not want to staff a proper one fine. I would then say get one to re-configure the SAN and document the new subsystem for you. If your infrastructure is to large and contracting someone, or hiring someone perm is a no go, I would make a strong case to management why they need to fork over the 4 - 6K and get someone trained in the area.
Trust me I didn't think it was a necessary evil... it IS. Use that script and keep the above in mind, and I can assure you your Toyota will be purring like the day you got her off the show room floor and took her for that first test drive.
Django? ill Pass.
Subscribe to:
Posts (Atom)