Upgrade and deployment issues with SQL Server 2008

This article is a question-and-answer form to introduce SQL Server2008 upgrade and deployment, hope that through this article can give you some improvement and help.

Q: Now that my company is using this version of SQL 2005, what is the best way to choose the SQL 05 upgrade to the PDS (Data protection System) of SQL 08? Will the SSIS (generation of high-performance data integration solution platforms) improve after upgrading to SQL 08?

A: The DPS upgrade from the DPS in SQL 2000 to SQL 2005 is the same, and the method we recommend is still rewritten because SQL 2005 and SQL 2008 of the engines are basically similar. But these two versions and SQL 2000 are not an engine at all, although you can upgrade to use, but the performance does not reach the original, so I suggest you rewrite, according to SQL 2005 or SQL 2008 Inside the recommended way to rewrite. SSIS are much more efficient because the current record-maker of data conversions in the industry is kept by Microsoft, like more than 20 minutes a G.

Q: I'm now worried about a problem, the number of transaction logs transferred between two servers , especially the index rebuild we need to perform every night. I hear the mirroring function sends the actual rebuild command, not the transaction log.

A: The database mirroring process is accomplished by sending the actual transaction log records from the principal database to the mirror server, which will be "replayed" in the mirrored database. Depending on the size of the index involved, this can mean generating a large number of transaction logs, resulting in large log files for the principal database, which you can treat as real-time log shipping. However, in a log shipping database scenario, the data is sent to a redundant database in the form of a log backup rather than a continuous stream. Therefore, the amount of information that needs to be sent to a redundant database is almost identical for index rebuilds in a mirrored database and a log shipping database. The actual difference is only in how the message is sent-whether it is sent continuously or in batches.

Q: If we're using the SQL 2000 version now, now that we need to upgrade to the SQL 2008 version because of data management, do we just have to pay for upgrades?

A: I don't remember that, but I'm sure that if you upgraded from SQL 2000, you would need to buy the new SQL 2008 product separately. In fact, the cost of SQL is still relatively high! While lagging behind rivals in the depth and breadth of performance, Microsoft has been able to catch up with a low price plus compatible integration with Windows and other Microsoft products.

Q: If in the Vista environment, which version of SQL do you recommend us to use? SQL 2000? SQL 2005? Or is it SQL 2008?

A: Now that you've restricted the use of your environment, you can choose to use SQL 2005 or SQL 2008 According to your business needs. Why do you say that? First Vista is the client's system, and if you have SQL 2000 installed, you can only install some special versions (Enterprise, standard, desktop). and SQL 2005 or SQL 2008 has a classic version, but the number of data, memory and storage changes, functions, statements, tables, libraries, those concepts are the same.

Q: If you are upgrading from SQL 2000 to SQL 2008, I will encounter some problems in it, then I can go to the help document, but my actual application, I encountered the problem may not be mentioned in the document, then in the use of the process, What do we need to be aware of? Like the change of sentence?

A: I don't think the sentence is very good. Purely by your personal preferences and your logical thinking. I can tell you that it will have a lot of new statements and syntax, and what kind of class. But Microsoft doesn't know your business, the only thing I can tell you, is that it has this technology, but how fast the technology can be achieved, you need to mix those statements, you need to select carefully, so that there is no need to pay attention to the place, the only thing to be aware of is not to call your statement too verbose.

Q: There is a phenomenon in the work that every table used by an application contains a large number of indexes. It seems that the previous DBAs liked to add indexes to individual table columns and some combinations after asking. I don't think all indexes are necessary, but how do I find the indexes that can be safely deleted? We are running SQL Server 2005.

A: Yes, a large number of indexes can be a major contributor to poor performance. Each time you insert, update, or delete rows in a table, you need to perform the appropriate action in each non-clustered index. This adds a lot of administrative overhead to I/O, CPU utilization, and transaction log generation. In SQL 2005, you can use the new dynamic management view, which tracks index usage. Take snapshots of the DMV output regularly, and then compare those snapshots. This is good for improving performance.