Showing posts with label moving. Show all posts
Showing posts with label moving. Show all posts

Thursday, March 22, 2012

do I need a DBA for SQL Server?

We currently run an Oracle 8i db for Oracle Applications 10.7. We are
considering moving away from this whole infrastructure to Windows 2003
Server and SQL Server 2005 with a new ERP system.

Currently, we have an Oracle DBA under contract who performs all of the
maintenance required, plus does any and all fixes to the db when there
are problems.

What I have been asked, and couldn't comfortably answer, is do we need
the same sort of arrangement for SQL Server? We have plenty of Windows
server experience in house, but only minor SQL Server experience (I can
set up maintenance jobs, backups, user admin, etc.). If something bad
happens to the ERP system, and the ERP vendor determines that the
problem is not with their app but is with the db itself, how do I get
this resolved quickly? Should I have a contract with a 3rd party to
cover us should this scenario occur?

Thanks for any and all feedback.
Regards,
BrianIf you are in the UK then give me a call and we can sort out a support
contract.

Personally, I'd give a couple of your internal guys some training to bring
them up to a support level for SQL Server and then rely on experts on call
if things go wrong.

A full time DBA is probably going to be expensive if they aren't doing
anything else.

The role of a pure DBA within the SQL Server has reduced somewhat, they tend
to do development but a lot do Business Intelligence stuff now as well.

Hope that helps.

--
Tony Rogerson
SQL Server MVP
http://sqlserverfaq.com - free video tutorials

"Brian" <barmand@.amphenolpcd.com> wrote in message
news:1138807906.362534.91700@.g49g2000cwa.googlegro ups.com...
> We currently run an Oracle 8i db for Oracle Applications 10.7. We are
> considering moving away from this whole infrastructure to Windows 2003
> Server and SQL Server 2005 with a new ERP system.
> Currently, we have an Oracle DBA under contract who performs all of the
> maintenance required, plus does any and all fixes to the db when there
> are problems.
> What I have been asked, and couldn't comfortably answer, is do we need
> the same sort of arrangement for SQL Server? We have plenty of Windows
> server experience in house, but only minor SQL Server experience (I can
> set up maintenance jobs, backups, user admin, etc.). If something bad
> happens to the ERP system, and the ERP vendor determines that the
> problem is not with their app but is with the db itself, how do I get
> this resolved quickly? Should I have a contract with a 3rd party to
> cover us should this scenario occur?
> Thanks for any and all feedback.
> Regards,
> Brian

Monday, March 19, 2012

DMO restore problem

I have a C++ app that is using SQLDMO with SqlServer2000. I am Restoring a database using only the .bak file, moving the .mdf and .ldf files. The following is the code:

#ifdef USE_SQLDMO
try
{
if(m_cpServer == NULL)
return E_FAIL;

_RestorePtr cpRestore;
CheckError(cpRestore.CreateInstance(_T("SQLDMO.Restore")));
cpRestore->Action = SQLDMORestore_Database;
cpRestore->Database = _bstr_t(sDbName);
cpRestore->Files = _bstr_t(sBUFile);
cpRestore->LastRestore = false;
cpRestore->ReplaceDatabase = true;
cpRestore->PercentCompleteNotification= 10;
RestoreSinkPtr cpSinkPtr;
//get data path for current server
GetSQLDataPath(sDataPath);
QueryResultsPtr cpFileList;
cpFileList = cpRestore->ReadFileList( m_cpServer);
//get info to change for move from cpFileList and move items
for(int i = 1; i <= cpFileList->Rows; i++)
{
_bstr_t bstrLogicalName = cpFileList->GetColumnString(i,1);
sLogicalName = (LPCTSTR)bstrLogicalName;
sLogicalName.Trim();
_bstr_t bstrPhysicalName = cpFileList->GetColumnString(i,2);
sPhysicalName = (LPCTSTR)bstrPhysicalName;
sPhysicalName.MakeUpper();
if(sPhysicalName.Find(".MDF") > 0)
{
sPhysicalName = sDataPath + "\\" + sDbName;
sFiles.Format("%i",nDatafiles);
if(nDatafiles == 0)
sPhysicalName += ".mdf";
else
sPhysicalName += "_" + sFiles + ".mdf";

nDatafiles++;
}
else if(sPhysicalName.Find(".LDF") > 0)
{
sFiles.Format("%i",nLogFiles);
sPhysicalName = sDataPath + "\\" + sDbName;
if(nLogFiles == 0)
sPhysicalName += ".ldf";
else
sPhysicalName += "_" + sFiles + ".ldf";

nLogFiles++;
}
sNew += "[" + sLogicalName + "],[" + sPhysicalName + "],";
}
sNew = sNew.Left(sNew.GetLength()-1);
sPhysicalName = (LPCTSTR)bstrPhysicalName;

cpRestore->SQLRestore( m_cpServer);
cpRestore->SQLVerify(m_cpServer);
cpRestore = NULL;
bSuccess = true;
}
catch(_com_error& err)
{
PrintComError(err);
PrintProviderError(m_cpServer);
hr = err.Error();
}
#endif

The problem is that the functions appears to work. The Restore command does not return and error and neither does the verify. When I open enterprise manager, the database created but is greyed out and shows a status of loading but never completes.
Any ideas/help would be greatly appreciated.

Sandy

I haven't tried your script, but I suspect that the LastRestore=false is the culprit, as this indicates that this is not the last backup on the restore chain and keeps the database in a loading state as it is expecting a final log backup will be applied.

DMO restore problem

I have a C++ app that is using SQLDMO with SqlServer2000. I am Restoring a database using only the .bak file, moving the .mdf and .ldf files. The following is the code:

#ifdef USE_SQLDMO
try
{
if(m_cpServer == NULL)
return E_FAIL;
_RestorePtr cpRestore;
CheckError(cpRestore.CreateInstance(_T("SQLDMO.Restore")));
cpRestore->Action = SQLDMORestore_Database;
cpRestore->Database = _bstr_t(sDbName);
cpRestore->Files = _bstr_t(sBUFile);
cpRestore->LastRestore = false;
cpRestore->ReplaceDatabase = true;
cpRestore->PercentCompleteNotification= 10;
RestoreSinkPtr cpSinkPtr;
//get data path for current server
GetSQLDataPath(sDataPath);
QueryResultsPtr cpFileList;
cpFileList = cpRestore->ReadFileList( m_cpServer);
//get info to change for move from cpFileList and move items
for(int i = 1; i <= cpFileList->Rows; i++)
{
_bstr_t bstrLogicalName = cpFileList->GetColumnString(i,1);
sLogicalName = (LPCTSTR)bstrLogicalName;
sLogicalName.Trim();
_bstr_t bstrPhysicalName = cpFileList->GetColumnString(i,2);
sPhysicalName = (LPCTSTR)bstrPhysicalName;
sPhysicalName.MakeUpper();
if(sPhysicalName.Find(".MDF") > 0)
{
sPhysicalName = sDataPath + "\\" + sDbName;
sFiles.Format("%i",nDatafiles);
if(nDatafiles == 0)
sPhysicalName += ".mdf";
else
sPhysicalName += "_" + sFiles + ".mdf";

nDatafiles++;
}
else if(sPhysicalName.Find(".LDF") > 0)
{
sFiles.Format("%i",nLogFiles);
sPhysicalName = sDataPath + "\\" + sDbName;
if(nLogFiles == 0)
sPhysicalName += ".ldf";
else
sPhysicalName += "_" + sFiles + ".ldf";

nLogFiles++;
}
sNew += "[" + sLogicalName + "],[" + sPhysicalName + "],";
}
sNew = sNew.Left(sNew.GetLength()-1);
sPhysicalName = (LPCTSTR)bstrPhysicalName;
cpRestore->SQLRestore( m_cpServer);
cpRestore->SQLVerify(m_cpServer);
cpRestore = NULL;
bSuccess = true;
}
catch(_com_error& err)
{
PrintComError(err);
PrintProviderError(m_cpServer);
hr = err.Error();
}
#endif

The problem is that the functions appears to work. The Restore command does not return and error and neither does the verify. When I open enterprise manager, the database created but is greyed out and shows a status of loading but never completes.
Any ideas/help would be greatly appreciated.

Sandy

I haven't tried your script, but I suspect that the LastRestore=false is the culprit, as this indicates that this is not the last backup on the restore chain and keeps the database in a loading state as it is expecting a final log backup will be applied.

Tuesday, February 14, 2012

distributed query runs indefinitely

Matt,
I never tire of queries I'm just very pressed for time
at the moment as we're in the middle of moving our
servers to a hosted environment and I'm managing the
database side of things. If possible, I'll take a look
late this afternoon (UK time) if nobody else has replied.
Rgds,
Paul Ibison (SQL Server MVP)
Paul,
Thanx, I greatly appreciate any time you can set aside whenever it is
Hope your transition goes smoothly,
Matt
|||Matt,
please try this type of approach:
CREATE TRIGGER ti_tst ON [dbo].[tst]
FOR INSERT
AS
set xact_abort on
insert into [dhsrvskh504\stst].dba_admin.dbo.tst (name)
select name from inserted
This works fine for me - hopefully for you as well.
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Matt,
if you still have problems, please look at these
troubleshooting guides:
http://www.kbalertz.com/Feedback.aspx?kbNumber=250367
http://support.microsoft.com/kb/306212
Rgds,
Paul Ibison SQL Server MVP, www.replicationanswers.com
(recommended sql server 2000 replication book:
http://www.nwsu.com/0974973602p.html)
|||Paul,
I greatly appreciate all help that you have provided. It appears that what
you have telling me the whole time was correct. After much looking,
searching, and cussing I found that it was a problem with windows 2003 and
the way it handles RPC requests. For any other here is a link to article to
work around.
http://support.microsoft.com/?kbid=555017
Once again thank you for all your help through this.
Matt