Rip's Domain

ORA-12504: TNS:listener was not given the SERVICE_NAME in CONNECT_DATA with Linked Server

Posted in MSSQL, Oracle, SQL, TechSupport by rip747 on July 18, 2011

most likely this is and issue with the look up for your alias. a quick workaround for is to set the Data Source and Provider Strings to the following:

<FQ hosting name>:<port>/<alias>

oracleserver.mycompany.com:1521/db

thanks to bkgroups<AT>yahoo<DOT>com for the post all the way back in 2007 on sqlmonster.com for the answer.

Advertisements

Query taking too long? Could be a null.

Posted in ColdFusion, MSSQL, SQL by rip747 on February 5, 2009

I was smacking my head against the wall trying to figure out why in the world a scheduled task I wrote was timing out on my production server, but not on my development server.

I started by looking at the database first since I know that that is the place that 99% of performance tuning could be done. I fired up Query Analyzer and popped in the SQL statement and began combing through the tables and views that made up the query.

To make a long story short (too late), I noticed that in one view I was returning a count aggregate and in my development database every row returned a value, but on my production database there was a row that was returning a null. I patched the problem with a quick isnull() and reran the query again. IT WORKED!!!!

The lessons I learned, double check your work, always account for nulls on joins and aggregates and never write business logic views at 4 in the morning.

SQL Management Studio Error: An error occurred while executing batch. Error message is: The directory name is invalid.

Posted in SQL by rip747 on October 5, 2008

While trying to execute a query inside Management Studio, I recieved this gem of an error. The solution is quite simple, just log off and then log back in.

Tagged with:

My many hats

Posted in ColdFusion, Jokes, SQL, TechSupport by rip747 on July 10, 2008

I wear a lot of hats where I work. People often ask me what hats I wear when I perform the many tasks at hand. Here is the list:

Network administration: a Sherlock Holmes hat

Database administration: wizard hat (and robe)

Website Administration: Baseball cap

Technical Support: Yamika

ColdFusion Programming: Sombrero

.Net Programming: a jimmy hat 😛

Rebulding MSDB in SQL Server 2005

Posted in SQL, TechSupport by rip747 on May 26, 2008

Again I spent a gorgeous day in front of the computer trying to solve a major problem.

Seems that because of some diskspace issures we had in April, my MSSQL configure got hosed and the server hasn’t been able to perform any backups nor has the sql server agent been running. This was due to the fact that the MSDB database has been corrupted.

The following are the steps that I took to get everything back up and running. I will warn you that by doing these steps, you will lose all you Maintenance Plans that you had and you will have to recreate them. Figure that this is a small price to pay because let’s face it, you got to have backups.

I would strongly suggest that you don’t be an idiot like me and make sure that you backup your msdb database. However if you are like me and didn’t do this, these steps should get everything back on track.

  1. Put MSSQL into single user mode
    1. Click -> START -> Microsoft SQL Server 2005 -> Configuration Tools – > SQL Server Configuration Manager
    2. Right click on SQL Server and choose Properties
    3. Click on the Advanced tab. Under Startup Parameters you will be adding the following parameters to the beginning of the string: -m;-c;-T3608
  2. Restart SQL Server
  3. Connect to SQL server through the Management Console. From this point on we will be using TSQL to issue the commands so click the New Query button on the top left. At this point you should be in the master database inside the query window.
  4. Detach the MSDB database using the following commands:
    use master
    go
    sp_detach_db ‘msdb’
    go

    and click Execute

  5. We need to move (or rename, I prefer moving them) the existing MDF and LDF files for the MSDB database so that we can recreate it.
    1. Usually these files are located in the following directory:
      C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data
      Your’s might differ.
    2. Move (or rename) the MSDBDATA.mdf and MSDBLOG.ldf files.
  6. Back to the Management Studio. Open up the instmsdb.sql file in a new query window. This file is usually located in the following directory:
    C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Install
  7. Execute the file. If you see any errors about xp_cmdshell, just ignore them. They are common and the script will take care of it.
  8. At this point you should have your MSDB database restored. The only thing left is cleanup.
  9. Execute the following command to make sure that xp_cmdshell is once again set to disable for security reasons:
    EXEC sp_configure ‘show advanced options’, 1
    GO
    RECONFIGURE WITH OVERRIDE
    GO
    EXEC sp_configure ‘xp_cmdshell’, 0
    GO
    RECONFIGURE WITH OVERRIDE
    GO
  10. Shutdown SQL Server
  11. Go back into your Startup Paremeters for your server in the SQL Server Configuration Manager and removed the -c;-m;-T3608 parameters we added earlier.
  12. Restart SQL Server

Everything should be cool at this point and you’ll be able to recreate any Maintenance Plans and Jobs.

Let me know if you have a better way or a way to restore the configuration information from the old msdb database.

Other SQL optimization tips

Posted in Microsoft, MSSQL, SQL, TechSupport by rip747 on March 28, 2008

Ben started a whirl wind of ideas with his recent post about optimizing SQL queries for better performance. I was getting too carried away with commenting and decided that further tips that I had should be put down in my own post. Below are the ideas that I commented on, along with some new ones.

1) Create indexes on foreign key(s)

I think, no wait, I know that this is the most overlooked design aspect on almost every database. Far too often people forget to create an index for the foreign key(s) that are on a table. I guess the reason is because since all database servers automatically create an index on the columns that you specify to make up the primary key, why shouldn’t it do the same for foreign keys? Well it doesn’t and this is why it’s the most overlooked and biggest culprit of performance lost in a database.

2) Normalization

How many times have you seen a statement that joins 10 different tables all to grab a single value from each table? I’m so guilty of this, I should be thrown to the wolves. Again this is a HUGE performance hog and can be avoided by sitting down and taking the time to normalize your database. What is normalization you ask? It’s the idea that some data that is in one table can be copied into another table to prevent a join from occurring. I guess an example I can give is:

You have 2 tables named employees and companies. Companies has an one to many relation to Employees. When you write a query to retrieve an employee’s company name, you create a join between the employees table and the companies table and retrieve the company name.

It’s simple and we all do it and it’s probably not the greatest example, but I wanted something simple. Now if you wanted to normalize this, you would create a column on the employees table called company_name and copy the value from the companies table into that column, thus preventing you from have to create a join when retrieving the company name in a query which will improve the performance of the query. This can be accomplished at the application level or by using triggers within the database.
Now I wouldn’t use normalization in this situation, again I wanted something simple to explain the concept. With that said, when should you start and how do you determine what to normalize all depends on the data and the time the queries are taking to retrieve it. Most of time though I only normalize simple data that isn’t changed too often. For that stuff I use views.

3) Views and Indexed Views

Yes they’re different and indexed views aren’t supported on all database platforms so this doesn’t pertain to everyone.

Normalization is tough to deal with and maintain. So how do we go about increasing the performance of our database with copying columns and data everywhere, we use views!

Views are basically queries that you can save and then use like normal table when writing other queries. The idea is that instead of writing the same sub-queries or derived tables all the time and throughout your application, you can move those statements into views and then interact with them as you would with any other table.

Views are a great place to house the business logic of your application when you don’t want to or can’t use stored procedures. I use them a lot in applications to calculate expiration dates of memberships, totaling up line items in a shopping cart or just about any other calculations that the application needs.

Imagine trying to maintain a set of complicated calculations and business logic in an application that is copied over and over in queries scattered everywhere? You can’t!

Now I understand that most people argue that calculations like these should be moved into classes with the application, but I’ve found that that’s not always a smart thing to do and can sometimes cause bigger performance lost then realized. Imagine if you would, you have a method in your application that calculates the expiration date of a member and you need to access to this information at the database level. Well if the calculation is performed at the application level, that means you will need to copy and translate the logic to your database. By moving this calculation to a view you now have access to the information from both your database and the application and it’s all in one place! Also now since the calculation is being performed at the database level it makes you write less code in your application and not have to calculation for each record you return.

Ok great… so what is an indexed view? An index view is the basically the same thing as a regular view only you have the option of creating indexes on it where as a regular view you can’t. This can greatly increase the performance of queries that use views or span across multiple views. BE FOREWARNED though there are STRICT guidelines that you must follow in the creation and use of these views and they differ between database servers. You must consult your database servers documentation when attempting to use them.

Examples on using and creating indexed views in MSSQL 2000 can be found here.

4) Clustered Indexes

At the beginning of this article I mentioned that placing indexes on foreign key can be a big help and that almost all database server automatically create indexes for primary keys. Well expanding on that is the use of clustered indexes versus regular indexes.

When you create a regular old index on a table your database server basically creates a file on the server with information about where everything is within that table. Nothing happens to the data within the original table. Not so when you create a clustered index. A clustered index tells the database server how to physically write the data for this table onto the server’s disk. This is the reason why you can only have one clustered index on a table and it’s THE MOST important decision you can make when talking about performance.

Remember the advice at the beginning about placing index on foreign keys? Well to expand on that, you should also determine if your foreign key should be used as or be part of the clustered index on the table.

Let’s look back at the scenario I gave between the employees and the companies. After we’ve written our application, we noticed that throughout our application, there are many times when we query to list or find employees that are part of a particular company. Further investigation reveals that the only time we’re ever querying the employees table directly is when We’re authenticating a login or retrieving their profile.

By looking at this scenario it would probably make sense to include the company foreign key within the clustered index on the employees table and make it the first column of the index. Reason is that this will dramatically speed up the seek time of getting all the employees for a company since they will all be located around each other.

Now let me pull the reigns back a little. I’m not saying that you should go about doing this on every table in your database. There are very specific situations where this action makes sense and it doesn’t occur often. The only way to be completely sure is to load test your database in a testing environment with the change. Another HUGE WARNING! Doing this will cause the physical restructuring of data on the disk and as such it can take an incredibly long time to complete this change on large tables. Again, only testing can determine if a change like this is worth making.

5) Dropping, Rebuilding and Defragging Indexes and General Maintenance

When was the last time you rebuild or defragged your indexes?

Have you updated the statistics on the database lately?

How about checked the integrity of your data?

When was the last time you backed up your data?

Do you have any idea what I’m saying?

If your aren’t continually performing proper maintenance on your database, none of the ideas I talked about make any sense doing. Without proper maintenance your database will continue to degrade in performance no matter what you do. Almost all aspects of maintenance is automated and it’s so simple there’s no reason not to do it. MSSQL is especially easy since it has the Database Maintenance Plan wizard to guide you though it all. Check out the documentation the came with your database server to see what maintenance options or wizards it comes with.

Tagged with: , ,

Linked Servers: Performing Select, Insert, Update and Delete (CRUD) actions

Posted in SQL, TechSupport by rip747 on December 14, 2007

You could literally spend hours combing the internet trying to figure out how to do something.

In my last post, I spend 4 hours trying to figure out exactly how to get a linked server working with SQL Server. After I finally getting the server linked so I could perform simple queries against it, I needed to now figure out how I could perform inserts, updates and deletes to it.

Scouring the internet again proved totally a waste of time and I decide to just try to figure it out on my own. Well after another 2 hours, I have figured it out. Here is the syntax to do select, insert, update, and delete (CRUD) actions against a linked server. Remember that your syntax might vary slightly. All queries use the OPENQUERY command.

SELECT:

select * from openquery(‘my_linked_server’, ‘select * from table_schema.table_name’)

INSERT:

insert openquery(‘my_linked_server, ‘select column_1, column2 from table_schema.table_name’)
values (‘my_value1’, ‘my_value2’)

UPDATE:

update openquery(‘my_linked_server, ‘select column_1, column_2 from table_schema.table_name where pk = pk_value’)
set column_1 = ‘my_value1’, column_2 = ‘my_value2’
DELETE:

delete from openqueryopenquery(‘my_linked_server, ‘select * from table_schema.table_name where pk = pk_value’)

There you have it, I just saved you 2 hours (can I get mine back).

SQL Server 2000: Linked Oracle Server Errors

Posted in Oracle, SQL, TechSupport by rip747 on December 14, 2007

I HATE ORACLE!!! Why does this always happen to me?

Again, I spent the last 4 hours of my day trying to get something as simple as a linked server in MSSQL 2000 to work. What I was doing was setting up a linked server between MSSQL 2000 and Oracle 9i and ran into a lot of problem. Below is ranting and how I finally solved my problem.

The one thing I can’t stand about setting up a linked server in MSSQL with Oracle is that it’s never the same. Sometime you can get away with using the “Microsoft OLE DB Provider for Oracle”, other times you need to use the “Microsoft OLE DB Provider for ODBC Drivers” and still sometimes you need to use the “Oracle Provider for OLE DB”. In summary you have 3 different providers to choose from depending on nothing but the toss of a hat.

Just to prove my point, I already have a linked server setup on another MSSQL 2000 server using the “Microsoft OLE DB Provider for Oracle” provider. On the server I’m setting up, I following the EXACT same configuration and used the same provider and it wouldn’t connect. I’m getting Error 7312 and Error 7399 every time I try to connect and view the tables.

{Error 7399: OLE DB provider ‘MSDAORA’ reported an error. OLEDB error trace [OLE/DB Provider ‘MSDAORA’ IDBInitialize::Initialize returned 0x80004005: ]}

{Server: Msg 7321, Level 16, State 2, Line 1 An error occurred while preparing a query for execution against OLE DB provider ‘OraOLEDB.Oracle’. [OLE/DB provider returned message: ORA-00942: table or view does not exist]
OLE DB error trace [OLE/DB Provider ‘OraOLEDB.Oracle’ ICommandPrepare::Prepare returned 0x80040e14]. }

After playing around for 4 hours, I finally found the right combination to connect and run my queries. Here is what I tried. I will say this, that there is no definitive solution for this. You are going to have to try each suggestion and see which one works for you. I should note that I do all of this inside of Enterprise Manager.

First off, pick one of the following providers and create your linked server:
Microsoft OLE DB Provider for Oracle
Microsoft OLE DB Provider for ODBC Drivers
Oracle Provider for OLE DB

Now once you have your linked server created, expand the link server and clicked on TABLES to see if you get a list of the tables or if you get the 7399 error. If you get the error, try a different provider until you get the list of tables. When you finally get the listing of tables, remember the value in the “schema” column for that table, it might come into play in the next part.

After you get the list of tables, open up Query Analyzer and try to do a query against the linked server. I have always had to use OPENQUERY to get the query to work. There are two syntaxes that you will have to try:

First try this:

select * from openquery(my_linked_server, ‘select * from table_name’)

If you get the 7321 error try this:

select * from openquery(my_linked_server, ‘select * from schema_value.table_name’)

One of those should work. If anyone else comes up with weird errors or a difference method to connect, leave your suggestion in the comments below.

Optimizing your database with indexes

Posted in Microsoft, SQL, TechSupport by rip747 on December 3, 2007

While browsing Reddit, I came across an article about why you should index your database.

In short, the author finally figures out that using an index can decrease the execution time of a query dramatically. An incredibly uninformative article, since there is no mention of what he indexed or any advice as how you should go about doing it yourself.

Well being a database guy at heart I thought that I would give some hints in this subject since it’s a fairly common one. Many a times in my career I’ve been asked by people about what they should be indexing in their databases. I don’t know why, but people seem scared to place an index on a table. Let me just tell you that you aren’t going to destroy your database by experimenting with indexes, you might slow it down a bit, but you won’t mess up any data. So don’t be afraid to start playing around.

So what should we index? As a rule of thumb you should be indexing the following:

  1. Any foreign keys linking table together (you will be amazed that this is the most overlooked index to create)
  2. Any columns that you will use to create joins between table (usually these are the same as the foreign keys, but they could differ sometimes)
  3. Any columns that you will be filtering against in your queries (these are columns in your queries that you reference in your where clauses)

By going down those 3 items, you will most likely see a performance gain in your database. Now there are some gotchas with this:

  1. Be careful to not index a column more then once. This could be common if you place an index on a foreign key and then include that foreign key within another index. There are obviously exceptions to the rule.
  2. You don’t want to place an index on every column in a table even if you do use even column in where clauses throughout your application. By doing so you will be killing the performance of the table. Try to use judgment in selecting the most important columns within the table.

Can you have too many indexes on a table? Of course you can! One of the ways that you know that you have too many indexes is if you see a lag when altering data on a table (inserting, updating and deleting). Remember that your database server has to maintain and do housecleaning on all indexes affected by altering the data on a table. Because of this, if you place too many indexes on a table, it will slow down the write and updates of the indexes which will cause lags.

For people just getting started with indexes and using SQL Server, a great way to learn and practice is to use the Index Tuning Wizard that is included with SQL Server. To practice, place a slow running query or a query that you want to optimize in Query Analyzer and execute it. Next, try figuring out on your own which columns on which tables you should index in order to make the query perfomrm better and write them down. Run the Index Tuning Wizard and see if your suggestions matches the ones that the Index Tuning Wizard comes up with.

Good luck optimizing your tables with indexes. If you have any questions, suggestions or comments, leave them below.

Opinion: To Use Or Not To Use Stored Procedures?

Posted in ColdFusion, Rants, SQL by rip747 on November 15, 2007

I was browsing around on Reddit today and came across an article that particular struck my interest: To Use Or Not To Use Stored Procedures?

What intrigued me was that I have been a proponent of stored procedures in the past and now avoid them like the plague. I think the switch came when I started to realize how difficult and time consuming it was to write and maintain a project using stored procedures versus a project that just use parametrized queries. I also remember how difficult it was to write dynamic sql statements within a stored procedure.

I think really the only reason I used them in the past was because CF at the time didn’t support cfqueryparam and it as the only way to protect yourself against SQL injections. Once cfqueryparam came onto the seen, it took awhile for me to adopt it in my code and actually realized the benefits. Now I could write my SQL statements within CF and still have the security of a stored procedure protecting me against SQL injections. It was a blissful time; I could really pound out projects and code and debugging an application became a snap.

There were a few still out there that still voiced the myth that using stored procedures gave you a speed boost over
parameterized queries. Those people were soon put to rest when most RDMS and ODBC drivers made it so that using either way gave you the speed benefits of caching the query plan. Now this point is mute.

Today, I silently laugh at people that still think that using stored procedures in projects as the main way to communicate with their database. By creating views, using cfqueryparam and knowing the proper ways of using the different joins available; I can mimic almost any behavior a stored procedure can do when it comes to pulling data from a database.

To me I see the stored procedure in CF going the way of CFX tags… away.