Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

SQL 2005 Memory Bleed

Status
Not open for further replies.

1DMF

Programmer
Jan 18, 2005
8,795
GB
Please tell me if i'm barking up the wrong forum, but as my script is perl, seemed like a good place to start!

OK, we have had some server issues, which our dedicated host provider said is SQL 2005 having memory bleed, to the point the machine locks up and requires a re-boot after @ two weeks of operation without a reboot.

As I use my own SQL module to access SQL and retreive the recordset as an array of hashes, I would like to eliminate this as the cause of the memory bleed, so your input is appreciated.

Here is an example of my getSQL routine....

Code:
###############################################
############## Get SQL Routine ################
###############################################

sub getSQL {

#_0 = Table
#_1 = Columns
#_2 = Where
#_3 = Order By

# Define Record Set Array & Hash
my @rs;

#Build SQL Statement
my $sel = "SELECT $_[1] FROM $_[0] WHERE $_[2]";

# Check for ORDER BY
if($_[3]){$sel .= " ORDER BY $_[3]";}

# Open DB Connection
my $db;

if(!$HLP){
    $db = new Win32::ODBC($MDB) || die "getSQL Error Connecting (Web): " . Win32::ODBC::Error();
}
else{ 

    $db = new Win32::ODBC("FILEDSN=$DSN;") || die "getSQL Error Connecting (SBS): " . Win32::ODBC::Error();
}

# Run SQL Command
if(!$db->Sql("$sel")) {

	# Loop SQL Record Set
		while($db->FetchRow()){ 
				# Build Array of Hashes with SQL Data
				my %dt = $db->DataHash();
			    $rs[@rs] = \%dt;	
		}
	# Close DB Connection
	$db->Close();

	# Return Record Set Array of Hashes
	@rs;

} 
else{die "Error in getSQL ($sel)" . Win32::ODBC::Error();}

}
One thing I notice is if there is an error executing the SQL statement it dies with the error message.

Does die kill a SQL connection or do I need to issue the $db->Close(); before I kill the script, could this be the cause of the memory bleed?

Having been studying Java, it is clear that any operation that might cause an Exception should be encapsulated in a try/catch/finally clause, so you can gracefully try to close an open file.

I was wondering if the same needs to be done in my SQL module? Though I can't find a try/catch for perl.

Your advice is appreciated.





"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts
 
I normally use DBI for database access, so I can't comment on the behaviour of Win32::ODBC. DBI will close any open database handles during program termination.

You might want to consider switching to DBI - it has a number of debugging features which might be useful, as well as a whole slew of methods that return hashes and arrays of records similar to the one you construct in your loop. Because all your access is from a common subroutine, you could afford to experiment with DBI quite cheaply...

From a design perspective, the way you substitute your variables into the SQL string leaves you wide open to SQL injection attacks unless you are analysing the variables elsewhere (in which case you should probably refactor and move the analysis into this subroutine to avoid duplication). If you don't know about SQL injection, just Google 'SQL injection attack' and prepare to be shocked by how much damage they can do.

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object::perlDesignPatterns)[/small]
 
Hi steve,

Well yes I could use DBI I guess , I have written a SQL module based on the DBI module as well so no extra work really.

Also yes, I do handle SQL injection else where, I guess I could change my module to handle it, but that would mean having to change scores of other scripts to not deal with single quotes, so it's more work I think than reward.

Hindsight is a wonderful thing!

I've only used DBI for non-MS SQL connectivity, can you tell me what the DBI:DRIVER part of the connection string is for MSSQL as I've only ever used 'mysql'.

Cheers,
1DMF





"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts
 
I found it thanks but it still isn't working...

DBD::ODBC::st fetchrow_hashref failed: [Microsoft][ODBC SQL Server Driver]String data, right truncation (SQL-01004)

Any idea why this is happening?

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts
 
Also, any idea how you pass it a FILEDSN.

I can't seem to find the syntax for using file DSN so I can connect to remote SQL servers at other locations other than the local DSN for the webserver?

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts
 
Can't you connect to the local server using the remote connection string? i.e. treat it as a remote server that just happens to be co-located on the same box?

Also, there is another possibility, but the first one you posted looks like a plausible answer - you can override the regional setting on the connection string (allegedly).

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object::perlDesignPatterns)[/small]
 
Can't you connect to the local server using the remote connection string? i.e. treat it as a remote server that just happens to be co-located on the same box?

Sorry you've lost me, the two servers are 50 miles from each other connected by a VPN tunnel.

You cannot just give it a DSN to connect, the DSN on one server is not visible to the other. Or at least I've never been able to see one from the other, but I might be doing something wrong.

Thanks for the other link, though i'm starting to wish I never listened to you about using the DBI module ;-)



"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts
 
Still cannot get the FileDSN to work, I use the following syntax
Code:
$db = DBI->connect("DBI:ODBC:FILEDSN=$DSN") || die "Error Connecting (SBS): $DBI::errstr";

But it just errors with
Error Connecting (SBS): [Microsoft][ODBC SQL Server Driver][SQL Server]Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection. (SQL-28000) [err was 1 now 1] [state was 28000 now 01S00]
[Microsoft][ODBC SQL Server Driver]Invalid connection string attribute (SQL-01S00)

The file DSN has the following in it...
Code:
[ODBC]
DRIVER=SQL Server
CommandTimeout=900
ConnectionTimeout=900
ReadTimeout=900
DATABASE=myDB
SERVER=myIP
DESCRIPTION=myDescription
UID=myUID
PWD=myPWD
Regional=No

Which works fine with the Win32::ODBC module?

Any ideas why I can't get the ODBC FILEDSN to work with the DBI module?

Cheers, 1DMF




"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts
 
From every thing I've read, eval() = try/catch, for perl
 
Thanks Max, I'll check it out.

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts
 
Thanks.

Can anyone help with the FileDSN syntax?

If I can't get this to work then DBI is not a viable option.

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts
 
Does your $DSN include the path? The examples on the EasySoft tutorial do, and they have some stuff about silent failure if it can't be found...

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object::perlDesignPatterns)[/small]
 
Hi Steve,

Yes $DSN has full path.

I've found that the FileDSN works if you pass userID & password as part of the connection string.

Code:
$db = DBI->connect("DBI:ODBC:FILEDSN=$DSN"[blue],"USERID","PASSWORD"[/blue]) || die "Error Connecting (SBS): $DBI::errstr";
So I've concluded that DBI is not fully Windows ODBC FileDSN specification compatible. As you should be able to specify the UID/PWD in the fileDSN and not have to pass it on the connection string. Which works fine with Win32::ODBC!

This now means a massive re-write of the system tomorrow, just to see if DBI resolves my SQL woes.

Oh well keeps me busy I guess!

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts
 
Looks like the Regional = No doesn't work.

I had to set the LongReadLen.

This DBI module has caused nothing but problems compared to the ease of using Win32::ODBC

I just hope now it's been implemented we get rid of our 'General Network Error' woes and SQL memory bleed!

"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts
 
[banghead] looks like DBI has made no difference.

Had first DBI error reported and it's exactly the same...
DBI connect('FILEDSN=C:/my/path/to/file.dsn;Regional=No;','myid',...) failed: [Microsoft][ODBC SQL Server Driver][DBNETLIB]General network error. Check your network documentation. (SQL-08001) [err was 1 now 1] [state was 08001 now 01000]
[Microsoft][ODBC SQL Server Driver][DBNETLIB]ConnectionOpen (PreLoginHandshake()). (SQL-01000) [err was 1 now 1] [state was 01000 now 01S00]
[Microsoft][ODBC SQL Server Driver]Invalid connection string attribute (SQL-01S00) at

In fact in some ways the DBI error is worse, it's giving away full path and userid in the error message!!!!! hardly a secure way of baulking!

Anyways, does any of this error message mean anything to anyone?



"In complete darkness we are all the same, only our knowledge and wisdom separates us, don't let your eyes deceive you."

"If a shortcut was meant to be easy, it wouldn't be a shortcut, it would be the way!"

Google Rank Extractor -> Perl beta with FusionCharts
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top