We are running SQL Server 2000 w SP4 on a 2 node active/passive Windows 2003 w SP1 configuration. We are presented with 2 150GB LUNs and 1 600MB on particular SAN that does not belong to us. M: and N: drives are the datadrives and Q: is the quorum.
We now have our own SAN and we will be using it for the SQL cluster data storage. The SAN administrator stated that he will present me with 2 150GB LUNs and 1 600MB…pretty much the same configuration.
How will I be able to move all my data and configure the cluster to the new SAN?
I am in the process of moving databases from a SQL 2005 Standard version to a 2-node 2014 cluster.All of my 2005 databases back up successfully.They all restore without issue except for one database that has a full text catalog. I get this message
Msg 7610, Level 16, State 1, Line 2 Access is denied to "fileStoragedataMSSQLSERVERFullTextCatalog", or the path is invalid. Msg 3156, Level 16, State 50, Line 2 File 'sysft_FTCatalog' cannot be restored to 'fileStoragedataMSSQLSERVERFullTextCatalog'. Use WITH MOVE to identify a valid location for the file. Msg 3119, Level 16, State 1, Line 2 Problems were identified while planning for the RESTORE statement. Previous messages provide details. Msg 3013, Level 16, State 1, Line 2 RESTORE DATABASE is terminating abnormally.
[code]....
I went as far as giving the folder full access to everyone temporarily and received the same error.
I have Transfered my dts packages from sql 2000 to sql2005 by directly migrating the rows from Sysdtspackages table on sqlserver 2000 to Sysdtspackages table on Sqlserver 2005.Now im able to see all my DTS of sql2000 in sqlserver 2005 Management studio under MANAGMENT--->LEGACY--->Data transforamtion services and i have all the corresponding records in sysdtspackages table of MSDB database on SQLSERVER 2005.
Now i have to schedule a job for executing these dts packages. In the job schedule window, when i try to select my dts packages on the SSIS package store for the package source and go to SSIS --->MSDB, IM NOT ABLE TO FIND MY DTS PACKAGES? WHERE ARE MY DTS PACKAGES GONE. HOW CAN I SCHEDULE.
i can find another table by name 'sysdtspackages90' on msdb database.do i have to migrate the data from sysdtspackages to sysdtspacakges90 ?
I am in process of automating a cube migration from SSMS 2008 to SSMS 2012.
In this process iam deleting the existing cube databases and restoring them on a different location on the same server. When i try to execute the restore command or restore using UI i get a wierd error message like this below:
"TITLE: Microsoft SQL Server Management Studio ------------------------------ File system error: The following error occurred while opening the file 'DrivePath3F9D4D128D5E417FA6F2[CUBEDBNamepath].fact.map'. Server: The current operation was cancelled because another operation in the transaction failed. (Microsoft.AnalysisServices)
We have an existing OLD System in SQL Server 2000 DTS Packages. The Whole application runs on DTS. There are several Packages which are called from a Master Package. Each Child packages have their own Global Variables. Most of them are the File Location variables to have the Source Location of the Input Data, mainly from the Excel Files. Now, even if the Global Variables are there to change whenever they want to change the Locations of the Files, they have to goto each child package and change the variable themselves. To resolve this issue, they want a configuration File (INI) / Table which would store those Variables. My thought is to read from that File/Table and Update all the packages' global variables through an ActiveX Script as the First Step of the Master package. That would eliminate the need of changing anything in the existing System. But the Problem is the management (PM / DBAs / Team members) have different views to store the Configuration data. 1. Some wants it into a Different Database, having one table for this application so in future they can also add another table for some other application. 2. Some wants to store it in a Table in the Same Database of this Application. 3. Some wants to save it as a INI file.
As i'm the one who's going to really implement it, they have asked me to research for a best solution out there.
so I request to help me to decide which is a good solution and why.
If you enter "Create Database test", the database files (mdf file & log file) are created, by default, in:- C:Program FilesMicrosoft SQL ServerMSSQLData I want to change that to:- D:Database Files I sucessfully moved the model database to this location (using the instructions in BOL) assuming that all new databases would now get created in the same location, but they don't. They still get created in: C:Program FilesMicrosoft SQL ServerMSSQLData
So how do I change the default? (It's not satisfactory to have to move each database after it's created)
I am trying to create a proof of concept to show that we can have packages deployed on 3 different servers and all we need to do is tell the package, upon execution/scheduled task, where to go fetch it's configurations from.
The configurations are using SQL Server as the package configuration. This makes it easier for DBA's to maintain since DBA's are responsible for package executions and job scheduling.
For example, the configuration database and all package configurations would be found on server1, server2 and server3 The difference in values is that on Server1, the configuration for the source data and the destination data point to Server1DatabaseSource and Server1DatabaseDestination and on server2, the configs point the source to Server2DatabaseSource and Server2DatabaseDestination and for server 3, the same thing but pointing to server3.
There is also a connection for the SSIS_Config database we're getting the configurations from. In theory, if we specify a different server where this SSIS_Config database is found, it should override the settings in the package. No?
When I schedule OR execute the package, it's always getting it's configs from the config specified in the package independent of wether I specify it in the Connection Managers of the Execute Package Utility when I manually execute it OR in the data sources tab when I configure the package to be run as a job in SQL Server 2005.
I have installed my modell database onto c:mssql7data...
How do I now change the properties of this so that when someone creates a database, the path it will get created to is set to d: I thought that I could just move model, but it seems that this isn't possible.
When SQLserver2K was installed it placed master, model, msdb, tempdb data files in the installation location (i.e. C:Program Files....). This puts pressure on the C: drive, which also holds the page/swapfile. I want to move at least the tempdb location to the new 'Default data directory' and log directory we set after installation (i.e. E:MSSQLData).
How do I get tempdb to relocate to E: given that it gets recreated each time SQLserver starts?
changing master database location in sql server 2000
HELLO PLEASE HELP ME I AM TRYING TO CHANGE THE LOCATION OF MASTER DATABASE ( MDF AND LDF ) AND ERRORLOG FILES I HAVE TRIED EDITING STARTUP PARAMETERS IN ENTERPRISE MANAGER I FAILED ,I TRIED IN COMMAND PROMPT "SQLSERVR.EXE " I SUCCEEDED IN CHANGING THE DATA FILE AND ERROR LOG BUT UNABLE TO CHANGE THE LOG FILE PATH FROM DEFAULT LOCATION C:PROGRAM ............ TO D:DATA PLEASE GIVE ME THE PROCESS TO CHANGE DATA ,LOG AND ERROR LOG FILES of master database thanq in advance
When running the GUI client, I chose to install the SQL Server 2005 'Client Components' on F:Program FilesMicrosoft SQL Server, the installation put over 700MB of files on my C: drive, but there were less than 400MB of files in the location I specified. Only about 1/2 of the files I expected were put in the location I specified. Why? How can I redirect all of the 'shared' files and other misc. development pieces to install somewhere other than my boot drive? There is no way to specify this when using the GUI, can it be done with a command line install?
When adding a node to a SQL Server 2012 Standard edition cluster, how I do I identify the location for SQL server shared components and the rest of the SQL Server installation binaries?
When adding a node to a SQL Server 2012 Standard edition cluster all the binaries went to the C: drive default location. We put those files on a different drive when installing the first node. What needs to be done so both nodes have the binaries on the same drives and folders?
We will be moving our two cluster running SQL Server 2005 64-bit SP2 on Windows 2003 to the different datacenter. IP addressed of both nodes will be changed by DNS names remain the same. I was wondering if anyone had issues with this. Out thought is that we just need to update IPs in Cluster Manager.
I know it's not possible, I've read the KBs. But I don't understand why not - from my testing, it looks like the only things that break are the domain groups to which the service logins are added. The service logins can be changed, as can the IPs, and SQL starts up just fine. The only problem is the domain groups.
I saw this KB:
http://support.microsoft.com/?kbid=910708
which says this:
After you install a SQL Server 2005 failover cluster, you can change the service accounts, but you cannot change the domain groups. If you want to use different domain groups, you must uninstall and then reinstall SQL Server 2005.
But it doesn't elaborate, it just says that the groups cannot be changed. Why not? That seems silly to me - it's not just a line in a config file somewhere? Can someone please give me a good reason why the groups cannot be changed?
How to implement distinct storage tiers on SQL Remote BLOB Storage (RBS)?
I want to use this SQL Feature to move files(images, videos, pdf files) from a database to a distinct database dedicated to RBS. Then I want to have several storage tiers, where objects will be saved and moved according access frequency. Old data will be arquived in cheap storage, but it must be always accessible if needed.
Description: - 1st and main tier: new and frequently accessed objects stored in high performance storage; - 2nd tier: automatically move older or less accessed objects to an inexpensive and different storage tier; - in all cases, all objects must be accessible to all users, but accessing to archived objects(2nd tier) will be much slower;
I am a Windows developer for the IBM Tivoli Storage Manager Server (TSMS) product. Our product installation is built with InstallShield and uses the Windows Installer.
On a new installation of Windows 2003 x64 Storage Server R2, at a customer's site, the TSMS product fails to install. The install of the OS has version 3.01.400.3959 of the Windows Installer and I see no newer version that installs.
Part of our product is 32 bit (console) and another part is x64 (server). When installing I can see that the install's default is being redirected/reset to C:Program Files (x86)TivoliTSM after it is explicitly set by a custom action to ..Program Files.. . I further observe that our custom actions to write 64 bit registry entries are being refused.
REGSAM samMask = KEY_ALL_ACCESS; if ( regIsWow64Process () ) samMask = samMask | KEY_WOW64_64KEY; lStatus = RegCreateKeyEx( hLocalConnectKeyRoot, szSubkey, 0L, NULL, REG_OPTION_NON_VOLATILE, samMask, NULL, hKey, &dw ) ; The above fails to create the key.
We have tried four versions of our TSMS spanning many changes but the install acts the same. This does not happen on any other Windows OS we test on but we do not test on Windows 2003 Storage Server R2 being that it is an OEM product. We did test on Windows server 2003 R2 x64 and do not see this problem.
Do you have any suggestions on how to tackle this problem? I have full installation traces but can only see that the registry work is being refused. I can't see why.
During the installation of Adding node to a SQL Server failover cluster(On passive node) getting error like.. The MOF compiler could not connect with the WMI server. This is either because of a semantic error such as an incompatibility with the existing WMI repository or an actual error such as the failure of the WMI server to start.We run the below commands but didn’t get any resolution & got the same above error .
1<sup>st</sup> Method…
1. Open console command (Run->CMD with administrator privileges).
2. net stop winmgmt
3. Rename folder %windir%System32WbemRepository to other one, for backup purposes (for example _Repository).
Can I build a cluster by adding the cluster service, then the SQL instances, then add the other nodes and their passive SQL instances?I would lean to building the cluster first, the add the SQL instances.
I have following script which i am planning to run to drop all non-clustered primary keys on a database and then created as clustered. I am using someone else's script so don't know how to modify this. Some of primary key columns are used in references in other tables.
is there anyway i can drop the existing primary keys and using their original script then create again as clustered including restoring all foreign and reference keys and unique or no unique.
DECLARE @table NVARCHAR(512), @tablename NVARCHAR(512), @sql NVARCHAR(MAX), @sql2 NVARCHAR(MAX), @sql3 NVARCHAR(MAX), @column NVARCHAR(MAX); DECLARE @indexname NVARCHAR(512); SELECT name As 'Table'
We are planning to change all IPs of PRODUCTION Failover Cluster Setup. In my cluster setup ... we have 2 Physical Nodes with windows-2008, Roles are MSDTC and SQL-2008R2.
IP change for:
1. Both Nodes(Physical) 2. MSDTC 3. SQL Server 4. windows Cluster
So Almost... All IPs are going to change.
Im DBA here, I need to take care of SQL cluster and MSDTC. But I haven't performed this activity before.So I'm worrying about Impacts and consequences of this change. steps how should I perform this activity.
We have many tables which have cluster index on column with datatype 'Char(200)'. Does anyone have script to change cluster index to noncluster for all user tables which have clustered index on a column with 'char(200)' datatype.
I am trying to upgrade a SQL Server 6.5(Cluster) to SQL Serevr 7.0 (Cluster)..I already have an intsllation of 7.0(On a Cluster),so this means that 6.5 and sql 7 are on seperate cluster's ,if i try to upgrade from 6.5 Cluster to 7.0 Cluster is asks me to uncluster 6.5 and 7.0 is this correct ,assume i cannot break the cluster then what???.. what is the best way i can achieve this functinality.....
We are planning to upgrade the SQL Server in our production environment from SQL Server 2000 to SQL Server 2005. This is a 4 Node cluster environment with 3 Databases on 3 Virtual instances. The main requirement is to achieve this with no/minimal downtime.
Could you please suggest or direct me to any documentation for the best practices used to upgrade such an environment?
We have (had) an active/active cluster. 2 physical machines, each running their own instance, clustered together. Node1/Ins1 and Node2/Ins2.
Node2 failed and Ins2 failed over to Node1 as it should. Node2 required that we rebuild the server (rebuild = reinstall O/S). Now we need to get Node2 back into the cluster and get Ins2 failed back over to Node2.
Does anyone know, for certain, the correct steps to accomplish this? Obviously, we could backup everything and completely destroy Ins2 and recreate it on Node2 then rejoin the cluster. But I'm looking for something less destructive.
Is it possible to reinstall SQL, then rejoin the cluster, and then fail Node2 over? Or will there be registry conflictions?
Any help would be appreciated. Also, if you have any links to some official documentation, that would be great too.
We're upgrading a SQL Server 2000 cluster (Active/Passive) running on Windows 2000 Server to a SQL Server 2005 Cluster running on Windows Server 2003. We can't purchase new hardware and we have no spare hardware. We also need to move from Windows 2000 Server to Windows 2003 Server at the same time. We want to keep downtime to a bare minimum.
What we were thinking was the following steps... Anyone try this?
1. Break the link between the servers.
2. Install a fresh copy of windows 2003 server on one side along with SQL Server 2005. While this step is running, the active node would still be live on Windows 2000 Server and SQL Server 2000 serving our customers.
3. Restore a copy of a backup from the active production side to the node we're upgrading and at that point we would bring the active node down, switching the active node to be the newly upgraded server.
4. As a final step, the old active node would now have the link to it broken, we would install a fresh copy of windows 2003 server on it and sql server 2005. At this point we would bring it back into the cluster and the cluster would be complete again.
