Marking posts to get faster attention from SSIS Team

Here is one practical initiative for improving the service SSIS team provides to this forum:

We asked our MVPs to mark posts that need attention from the SSIS team and built a system to fetch those messages and send them directly to our internal distribution list. The report will contain all currently marked messages in non-answered threads.That way, forum posts that MVPs target to us will be much easier for us to find, and the response time for them will be shorter.

The MVPs have accepted to help us with this, and we started extracting messages marked by selected users and sending daily reports to the team.

Please let us know what you think about this action and keep an eye on how we are doing with providing answers on marked threads.

Thank you,

Bob Bojanic, SSIS Team

Well done. I think this is a good idea. Is there any difference between this approach and the SSIS MSDN manged forum?|||

Thanks, Larry.

I am not sure what you are referring to as "MSDN managed forum".

|||http://msdn.microsoft.com/newsgroups/managed/default.aspx?dg=microsoft.public.sqlserver.dts|||

Pardon, I meant managed newsgroup.

http://msdn.microsoft.com/newsgroups/managed/default.aspx?dg=microsoft.public.sqlserver.dts

|||

Oh, I see.

This seems to be a web client to our newsgroup discussions. We kind of pre-oriented into using this new forum (forums.microsoft.com) in the course of the last couple of years. The newsgroups seem to be still pretty active but there is no as many MS answerers as you can find here. The groups appear to be self-sustained though, and if you prefer less traffic and more focused discussion you should keep visiting them.

This initiative of marking threads to be looked at by the SSIS team is going to be limited to this forum. We do not have access to the server where the newsgroup posts are kept.

Thanks.

|||

Sounds like a good idea, but how about getting the list more than once a day, maybe once an hour?

Gary

|||

Gary Watson wrote:

Sounds like a good idea, but how about getting the list more than once a day, maybe once an hour?

Gary

Well, likely because the Microsoft guys actually have work to do! Once a day is appropriate, I think. Microsoft employees are under no obligation to answer any question on this forum; certainly in no set time frame.|||

Phil is right; answering posts on this forum is not going to give us a good excuse for not finishing our daily tasks.

This initiative is an attempt to get the questions from here closer to potential answerers. Usually, when we (SSIS team members) read these threads we try to use our time efficiently; so if we do not know the answer or do not have time to do some follow up investigation we will just skip the question hoping somebody else would answer it. If a right person does not come across those hard yet important questions in a few days, they might be left unanswered.

Our tool will find such questions, if marked appropriately, and make them visible to the entire SSIS team. There is no time limit when we have to answer them. They are listed in our report until answered. Most of those questions get answered in 2-3 days (it depends on the time it gets into the report, time zones, weekends, etc). Some of them might even require more time for investigations.

It would not make sense to send the report every hour if we cannot commit to the turnaround time on the same scale. The most important aspect is to get them marked so they do not get lost under new piles of posts.

Thanks,

Bob

|||

Hi Bob,

I did not understand before the use of this forum, thanks for clearing that up for me.

I am grateful that you guys can help out whenever you can.

Regards

Gary

sql

Marking posts to get faster attention from SSIS Team

Here is one practical initiative for improving the service SSIS team provides to this forum:

We asked our MVPs to mark posts that need attention from the SSIS team and built a system to fetch those messages and send them directly to our internal distribution list. The report will contain all currently marked messages in non-answered threads.That way, forum posts that MVPs target to us will be much easier for us to find, and the response time for them will be shorter.

The MVPs have accepted to help us with this, and we started extracting messages marked by selected users and sending daily reports to the team.

Please let us know what you think about this action and keep an eye on how we are doing with providing answers on marked threads.

Thank you,

Bob Bojanic, SSIS Team

Well done. I think this is a good idea. Is there any difference between this approach and the SSIS MSDN manged forum?|||

Thanks, Larry.

I am not sure what you are referring to as "MSDN managed forum".

|||http://msdn.microsoft.com/newsgroups/managed/default.aspx?dg=microsoft.public.sqlserver.dts|||

Pardon, I meant managed newsgroup.

http://msdn.microsoft.com/newsgroups/managed/default.aspx?dg=microsoft.public.sqlserver.dts

|||

Oh, I see.

This seems to be a web client to our newsgroup discussions. We kind of pre-oriented into using this new forum (forums.microsoft.com) in the course of the last couple of years. The newsgroups seem to be still pretty active but there is no as many MS answerers as you can find here. The groups appear to be self-sustained though, and if you prefer less traffic and more focused discussion you should keep visiting them.

This initiative of marking threads to be looked at by the SSIS team is going to be limited to this forum. We do not have access to the server where the newsgroup posts are kept.

Thanks.

|||

Sounds like a good idea, but how about getting the list more than once a day, maybe once an hour?

Gary

|||

Gary Watson wrote:

Sounds like a good idea, but how about getting the list more than once a day, maybe once an hour?

Gary

Well, likely because the Microsoft guys actually have work to do! Once a day is appropriate, I think. Microsoft employees are under no obligation to answer any question on this forum; certainly in no set time frame.|||

Phil is right; answering posts on this forum is not going to give us a good excuse for not finishing our daily tasks.

This initiative is an attempt to get the questions from here closer to potential answerers. Usually, when we (SSIS team members) read these threads we try to use our time efficiently; so if we do not know the answer or do not have time to do some follow up investigation we will just skip the question hoping somebody else would answer it. If a right person does not come across those hard yet important questions in a few days, they might be left unanswered.

Our tool will find such questions, if marked appropriately, and make them visible to the entire SSIS team. There is no time limit when we have to answer them. They are listed in our report until answered. Most of those questions get answered in 2-3 days (it depends on the time it gets into the report, time zones, weekends, etc). Some of them might even require more time for investigations.

It would not make sense to send the report every hour if we cannot commit to the turnaround time on the same scale. The most important aspect is to get them marked so they do not get lost under new piles of posts.

Thanks,

Bob

|||

Hi Bob,

I did not understand before the use of this forum, thanks for clearing that up for me.

I am grateful that you guys can help out whenever you can.

Regards

Gary

Marking posts to get faster attention from SSIS Team

Here is one practical initiative for improving the service SSIS team provides to this forum:

We asked our MVPs to mark posts that need attention from the SSIS team and built a system to fetch those messages and send them directly to our internal distribution list. The report will contain all currently marked messages in non-answered threads.That way, forum posts that MVPs target to us will be much easier for us to find, and the response time for them will be shorter.

The MVPs have accepted to help us with this, and we started extracting messages marked by selected users and sending daily reports to the team.

Please let us know what you think about this action and keep an eye on how we are doing with providing answers on marked threads.

Thank you,

Bob Bojanic, SSIS Team

Well done. I think this is a good idea. Is there any difference between this approach and the SSIS MSDN manged forum?|||

Thanks, Larry.

I am not sure what you are referring to as "MSDN managed forum".

|||http://msdn.microsoft.com/newsgroups/managed/default.aspx?dg=microsoft.public.sqlserver.dts|||

Pardon, I meant managed newsgroup.

http://msdn.microsoft.com/newsgroups/managed/default.aspx?dg=microsoft.public.sqlserver.dts

|||

Oh, I see.

This seems to be a web client to our newsgroup discussions. We kind of pre-oriented into using this new forum (forums.microsoft.com) in the course of the last couple of years. The newsgroups seem to be still pretty active but there is no as many MS answerers as you can find here. The groups appear to be self-sustained though, and if you prefer less traffic and more focused discussion you should keep visiting them.

This initiative of marking threads to be looked at by the SSIS team is going to be limited to this forum. We do not have access to the server where the newsgroup posts are kept.

Thanks.

|||

Sounds like a good idea, but how about getting the list more than once a day, maybe once an hour?

Gary

|||

Gary Watson wrote:

Sounds like a good idea, but how about getting the list more than once a day, maybe once an hour?

Gary

Well, likely because the Microsoft guys actually have work to do! Once a day is appropriate, I think. Microsoft employees are under no obligation to answer any question on this forum; certainly in no set time frame.|||

Phil is right; answering posts on this forum is not going to give us a good excuse for not finishing our daily tasks.

This initiative is an attempt to get the questions from here closer to potential answerers. Usually, when we (SSIS team members) read these threads we try to use our time efficiently; so if we do not know the answer or do not have time to do some follow up investigation we will just skip the question hoping somebody else would answer it. If a right person does not come across those hard yet important questions in a few days, they might be left unanswered.

Our tool will find such questions, if marked appropriately, and make them visible to the entire SSIS team. There is no time limit when we have to answer them. They are listed in our report until answered. Most of those questions get answered in 2-3 days (it depends on the time it gets into the report, time zones, weekends, etc). Some of them might even require more time for investigations.

It would not make sense to send the report every hour if we cannot commit to the turnaround time on the same scale. The most important aspect is to get them marked so they do not get lost under new piles of posts.

Thanks,

Bob

|||

Hi Bob,

I did not understand before the use of this forum, thanks for clearing that up for me.

I am grateful that you guys can help out whenever you can.

Regards

Gary

Manually Grow database files

I'm looking for a way to manually perform the same functionality that
the "auto grow" provides. I would like to be able to run a nightly
script that can determine the unallocated space in a file (eg.
sp_spaceused) and if it falls below a certain percent, say 15% then
have it grow the file by say 25GB. I want to prevent the files from
growing in the middle of the day because of performance and
fragmentation.
Any help would be great.
-Will
Will
ALTER DATABASE dbname
MODIFY FILE
(NAME = logical file name,
SIZE = 25GB)
GO
Note , it is going to take pretty long time, what is your SQL Server
version?
"Will" <WillCWirtz@.yahoo.com> wrote in message
news:8422a1b9-6c8a-4a8e-8c55-c163dba38b71@.i12g2000prf.googlegroups.com...
> I'm looking for a way to manually perform the same functionality that
> the "auto grow" provides. I would like to be able to run a nightly
> script that can determine the unallocated space in a file (eg.
> sp_spaceused) and if it falls below a certain percent, say 15% then
> have it grow the file by say 25GB. I want to prevent the files from
> growing in the middle of the day because of performance and
> fragmentation.
> Any help would be great.
> -Will
|||Uri, thanks for your help. We're using SQL 2005.
I was hoping to avoid the ALTER DATABASE command if possible. It just
seems a little risky, but I don't know why.
It looks like it doesn't exist, but I was hoping that SQL may provide
a API for doing that in a more controlled way like DBCC(mydb.mdf,
20GB) or something.
You mention that it will be slow. Slower than an Auto Grow of the
same size? If so, Why? This would back up my desire to call the same
code that runs when the "auto grow" is initiated.
Will
|||Will
It is considered a good practice to allocate ( get on target) the size for
db and manually gwoing it.
Please read up this article
http://www.sqlskills.com/blogs/kimberly/2007/03/04/InstantInitializationWhatWhyAndHow.aspx
"Will" <WillCWirtz@.yahoo.com> wrote in message
news:9277d876-a967-4907-bc4a-c424a4a1fcae@.s19g2000prg.googlegroups.com...
> Uri, thanks for your help. We're using SQL 2005.
> I was hoping to avoid the ALTER DATABASE command if possible. It just
> seems a little risky, but I don't know why.
> It looks like it doesn't exist, but I was hoping that SQL may provide
> a API for doing that in a more controlled way like DBCC(mydb.mdf,
> 20GB) or something.
> You mention that it will be slow. Slower than an Auto Grow of the
> same size? If so, Why? This would back up my desire to call the same
> code that runs when the "auto grow" is initiated.
> Will

Manually Grow database files

I'm looking for a way to manually perform the same functionality that
the "auto grow" provides. I would like to be able to run a nightly
script that can determine the unallocated space in a file (eg.
sp_spaceused) and if it falls below a certain percent, say 15% then
have it grow the file by say 25GB. I want to prevent the files from
growing in the middle of the day because of performance and
fragmentation.
Any help would be great.
-WillWill
ALTER DATABASE dbname
MODIFY FILE
(NAME = logical file name,
SIZE = 25GB)
GO
Note , it is going to take pretty long time, what is your SQL Server
version?
"Will" <WillCWirtz@.yahoo.com> wrote in message
news:8422a1b9-6c8a-4a8e-8c55-c163dba38b71@.i12g2000prf.googlegroups.com...
> I'm looking for a way to manually perform the same functionality that
> the "auto grow" provides. I would like to be able to run a nightly
> script that can determine the unallocated space in a file (eg.
> sp_spaceused) and if it falls below a certain percent, say 15% then
> have it grow the file by say 25GB. I want to prevent the files from
> growing in the middle of the day because of performance and
> fragmentation.
> Any help would be great.
> -Will|||Uri, thanks for your help. We're using SQL 2005.
I was hoping to avoid the ALTER DATABASE command if possible. It just
seems a little risky, but I don't know why.
It looks like it doesn't exist, but I was hoping that SQL may provide
a API for doing that in a more controlled way like DBCC(mydb.mdf,
20GB) or something.
You mention that it will be slow. Slower than an Auto Grow of the
same size? If so, Why? This would back up my desire to call the same
code that runs when the "auto grow" is initiated.
Will|||Will
It is considered a good practice to allocate ( get on target) the size for
db and manually gwoing it.
Please read up this article
http://www.sqlskills.com/blogs/kimberly/2007/03/04/InstantInitializationWhatWhyAndHow.aspx
"Will" <WillCWirtz@.yahoo.com> wrote in message
news:9277d876-a967-4907-bc4a-c424a4a1fcae@.s19g2000prg.googlegroups.com...
> Uri, thanks for your help. We're using SQL 2005.
> I was hoping to avoid the ALTER DATABASE command if possible. It just
> seems a little risky, but I don't know why.
> It looks like it doesn't exist, but I was hoping that SQL may provide
> a API for doing that in a more controlled way like DBCC(mydb.mdf,
> 20GB) or something.
> You mention that it will be slow. Slower than an Auto Grow of the
> same size? If so, Why? This would back up my desire to call the same
> code that runs when the "auto grow" is initiated.
> Will|||> I was hoping to avoid the ALTER DATABASE command if possible. It just
> seems a little risky, but I don't know why.
There's noting inherently "risky" with ALTER DATABASE.
> It looks like it doesn't exist, but I was hoping that SQL may provide
> a API for doing that in a more controlled way like DBCC(mydb.mdf,
> 20GB) or something.
Imagine you are working in the SQL Server dev team for MS. You have implemented code that expend the
size of a database file. You now have to determine the TSQL command which will invoke your command.
Should it be some DBCC command? Or some ALTER DATABASE? What I'm trying to say is that the command
is just an interface to the functionality within SQL Server. MS are in fact moving away from DBCC
and system stored procedures in favor of DDL.
> You mention that it will be slow. Slower than an Auto Grow of the
> same size?
No, it is the same functionality in the engine in the end. It will actually be perceieved quicker
because you don't have one or several persons waiting for the grow (because you grow before it is
full).
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Will" <WillCWirtz@.yahoo.com> wrote in message
news:9277d876-a967-4907-bc4a-c424a4a1fcae@.s19g2000prg.googlegroups.com...
> Uri, thanks for your help. We're using SQL 2005.
> I was hoping to avoid the ALTER DATABASE command if possible. It just
> seems a little risky, but I don't know why.
> It looks like it doesn't exist, but I was hoping that SQL may provide
> a API for doing that in a more controlled way like DBCC(mydb.mdf,
> 20GB) or something.
> You mention that it will be slow. Slower than an Auto Grow of the
> same size? If so, Why? This would back up my desire to call the same
> code that runs when the "auto grow" is initiated.
> Will|||> have it grow the file by say 25GB. I want to prevent the files from
> growing in the middle of the day because of performance and
> fragmentation.
If you are using sql 2005 on a windows server 2003, then you should read up
on Windows Instant File Initialization. Basically it means, that sql server
data files can be created instantly, without zeroing out all bytes in the
file. The account under which the sql server service runs, needs to be added
to the "Perform Volume Maintenance Tasks" security policy in windows. It
should be easy to find blog postings about this subject.
If you ARE running sql 2005 on a windows 2k3 server, and if you have set up
the user account for the "perform volume maintenance tasks", then you should
not worry about the performance hit when creating new data files og growing
them, since the growth happens instantly.
BUT! This only applies to data files. The log files will still need to zero
out all bytes on creation or growth, and that will have some performance
impact.
/Sjang|||> have it grow the file by say 25GB. I want to prevent the files from
> growing in the middle of the day because of performance and
> fragmentation.
If you are using sql 2005 on a windows server 2003, then you should read up
on Windows Instant File Initialization. Basically it means, that sql server
data files can be created instantly, without zeroing out all bytes in the
file. The account under which the sql server service runs, needs to be added
to the "Perform Volume Maintenance Tasks" security policy in windows. It
should be easy to find blog postings about this subject.
If you ARE running sql 2005 on a windows 2k3 server, and if you have set up
the user account for the "perform volume maintenance tasks", then you should
not worry about the performance hit when creating new data files og growing
them, since the growth happens instantly.
BUT! This only applies to data files. The log files will still need to zero
out all bytes on creation or growth, and that will have some performance
impact.
/Sjang