Citagus is a leading-edge IT solutions and services company established with a specific mission of providing comprehensive, top of the line solutions around PeopleSoft, SQL server & Oracle .The word ‘Citagus’ is derived out of ‘citos’ and ‘ageos’ which in latin means ‘Act Fast’. At Citagus, we ‘Act Fast’ to resolve our customer problems and meet and exceed their expectations. The consolidation of expertise in industry, software and IT solutions gives rise to new, one-stop solutions from Citagus. The global best business practices help you increase efficiency, improve productivity and achieve operational excellence.
Citagus Software ( USA ) Inc.
3235, Satellite Boulevard
Building 400, Suite 300
Duluth, GA. 30096
Citagus Software Private Limited
No.623, Balaji Arcade
80 Feet Road, 4th Block, Koramangala
Bangalore – 560 034
Tel : +91 080 67130300/01 Fax : +91 080 67130302
For Sales Inquiries contact – email@example.com
For General Inquiries contact – firstname.lastname@example.org
For Alliances Contact – email@example.com
Performance Dashboard was designed as a set of custom reports to be hosted within SQL Server Management Studio. The reports were written to deliver information from a consistent and familiar tool already used by database administrators. According to the documentation, there were several key design goals for this effort:
- Zero system impact when the dashboard is not being used. The dashboard uses no background agents or jobs, and the only time there is any system impact is when a user actually runs a report (at which time Management Studio runs the queries specified in the report definition as required to render the report);
- Read-only access to the server. The dashboard reports never perform any system modifications;
- No requirement to install any binaries (extended stored procedures, CLR assemblies) on the server;
- No requirement to create any special database/tables to store trending or historical information. The reports do require a one-time installation of some procedures and functions in the msdb database, with which we got hands-on practice in the installation we undertook in Performance Dashboard for Microsoft SQL Server, Part I;
- The efficient display of information necessary to identify the most frequently observed performance problems;
- Assisting administrators and other consumers in increasing their familiarity with the wealth of information available in the SQL Server 2005 dynamic management views (“DMVs”).
In help of the article SQL Server Login Transfer by: Tibor Karaszi I have made the document which can be very useful to our environment and might be somebody already has fair knowledge about the article then please ignores it.
As part of the normal work, a Database Administrator (DBA) will be required to migrate databases between servers. One of the reasons for a migration might be that we are moving an application from a quality assurance (QA) environment to a production environment.
There are a number of different ways to migrate SQL Server logins. We can manually re-enter the entire existing login on the new server. We can use DTS to transfer logins. There are probably a number of other ways to transfer logins. This article will discuss one of those other ways to streamline the migration of SQL Server logins,
SQL Server 2005 Data Transformation Services (DTS) includes a Transfer Logins task, but this task doesn’t cover all situations. The Transfer Logins task requires a network connection between SQL Server machines, which—for security reasons—isn’t always possible. Also, the task can transfer only from SQL Server 7.0 or 2000 to SQL Server 2000; it can’t transfer to pre-SQL Server 2000 releases.
Transfer logins between her SQL Server machines.
The following code shows how to script the sp_addlogin calls for the SQL Server logins:
SET NOCOUNT ON
SELECT ‘EXEC sp_addlogin @loginame = ”’ + loginname + ””
,’, @defdb = ”’ + dbname + ””
,’, @deflanguage = ”’ + language + ””
,’, @encryptopt = ”skip_encryption”’
,’, @passwd =’
, cast(password AS varbinary(256))
,’, @sid =’
WHERE name NOT IN (‘sa’)
AND isntname = 0
Each row in the column list is a column in the result. The script uses the isntname column to ascertain whether a login is a SQL Server login or an NT login. Executing the above code in a Query Analyzer grid shows that the binary data (and other parameters) are in separate columns. Also, because the password column is in Unicode (and encrypted), the code converts the password column into VARBINARY (256), so that you don’t lose characters.
The following code could use the following code to script the NT logins:
SELECT ‘EXEC sp_grantlogin @loginame = ”’ + loginname + ””
,’ EXEC sp_defaultdb @loginame = ”’ + loginname + ””
,’, @defdb = ”’ + dbname + ””
WHERE loginname NOT IN (‘BUILTIN\Administrators’)
AND isntname = 1
Save the output as a file and execute that file in the destination server.
You could get an error message if a login already exists. If you didn’t want to get the error messages, you could script an IF NOT EXISTS and a check against the login name column in the destination server for each call to sp_addlogin and sp_grantlogin.