Consolidate SQL servers to single server

So processor is ruled out. That's good.
I suggest you look at the chapter we put in the SQL 2K HA
book which explains how memory works in depth. To access
8 GB of memory under 32-bit, you need to put /PAE in
boot.ini. There is no other way. With /3GB, you can get
up to 3 GB of usable memory (different space tho), and 1
GB is always reserved for the OS. Up to 16 GB, both can
technically play together, and some applications need it.
beyond 16 GB on 32-bit machines, you cannot combine /3GB
and /PAE.
So if you have 8 GB and use /PAE and /3GB, you have 7 GB
of usable memory, of which only 3 GB would be dynamic (so
one instance could potentially be set to dynamic). When
using PAE, it is best to set the AWE settings in SQL as
well as set max mem for the instance. You seem to know
what that is.
So you can run all three instances with separate memory
using /PAE only, and if you can, I'd recommend that
approach.
Thank you for your reply, though I am still a bit confused.
I understand that using /3GB and /PAE will give me 7GB of usable RAM.
However, you say "When using PAE, it is best to set the AWE settings
in SQL as well as set max mem for the instance. You seem to know what
that is.", and while this is what I have read elsewhere, I was under
the impression that AWE settings were not available on SQL 2000
Standard?
In the next paragraph you say "So you can run all three instances with
separate memory using /PAE only, and if you can, I'd recommend that
approach." I don't think I understand this sentence. Are you saying
I should run /PAE and not /3GB /PAE along with AWE settings in SQL?
Basically, I think I'm just looking to see if I can make SQL Standard
address memory above 4GB. I know you can with Enterprise using AWE, I
just thought AWE was not usable on Standard.
Thanks,
Kevin
"Allan Hirt" <anonymous@.discussions.microsoft.com> wrote in message news:<532201c47407$87fa08c0$a501280a@.phx.gbl>...
> So processor is ruled out. That's good.
> I suggest you look at the chapter we put in the SQL 2K HA
> book which explains how memory works in depth. To access
> 8 GB of memory under 32-bit, you need to put /PAE in
> boot.ini. There is no other way. With /3GB, you can get
> up to 3 GB of usable memory (different space tho), and 1
> GB is always reserved for the OS. Up to 16 GB, both can
> technically play together, and some applications need it.
> beyond 16 GB on 32-bit machines, you cannot combine /3GB
> and /PAE.
> So if you have 8 GB and use /PAE and /3GB, you have 7 GB
> of usable memory, of which only 3 GB would be dynamic (so
> one instance could potentially be set to dynamic). When
> using PAE, it is best to set the AWE settings in SQL as
> well as set max mem for the instance. You seem to know
> what that is.
> So you can run all three instances with separate memory
> using /PAE only, and if you can, I'd recommend that
> approach.
|||PMJI, but I'm 99.9% sure that SQL Standard will only ever use 2GB RAM
maximum. Doesn't matter what OS you use or what switches you have set.
Mike Kruchten
"Kevin" <kjarrard@.gmail.com> wrote in message
news:4f5b3722.0407281043.471e0365@.posting.google.c om...
> Thank you for your reply, though I am still a bit confused.
> I understand that using /3GB and /PAE will give me 7GB of usable RAM.
> However, you say "When using PAE, it is best to set the AWE settings
> in SQL as well as set max mem for the instance. You seem to know what
> that is.", and while this is what I have read elsewhere, I was under
> the impression that AWE settings were not available on SQL 2000
> Standard?
> In the next paragraph you say "So you can run all three instances with
> separate memory using /PAE only, and if you can, I'd recommend that
> approach." I don't think I understand this sentence. Are you saying
> I should run /PAE and not /3GB /PAE along with AWE settings in SQL?
> Basically, I think I'm just looking to see if I can make SQL Standard
> address memory above 4GB. I know you can with Enterprise using AWE, I
> just thought AWE was not usable on Standard.
> Thanks,
> Kevin
> "Allan Hirt" <anonymous@.discussions.microsoft.com> wrote in message
news:<532201c47407$87fa08c0$a501280a@.phx.gbl>...[vbcol=seagreen]

Consolidate SQL servers to single server

We have 3 SQL servers we would like to consolidate onto a single
server. While proccessor usage is not of concern (per perfmon
monitoring and stats on the new hardware), memory usage is.
The Plan:
Migrate three SQL Server 2000 Standard servers to a Dell 6650 (4 way),
each in their own instance. The Server is running Windows 2003
Advanced server.
The Question/Problem:
While I've read about the PAE, AWE and 3/4/gb tunings, I'm still
confused on just what options we have. Each of these DB's use up
around 1 - 1.75GB of memory on a normal basis. They never exceed
1.75GB of usage so we haven't seen the need to go to SQL 2000
Enterprise. Obviously, though, 1.75GB + 1.75GB + 1.75GB !< 4GB of RAM
typically installed on a server. I've used the /3GB tuning on Windows
2000 Advanced, but that doesn't allow for enough memory in this
instance. What are my options to get each of these SQL instances 2GB
of RAM working within the confines of OS the SQL memory management?
Can I simply run Windows in PAE mode and install each copy of SQL in
their own instance to have full run of the 8GB to be installed in this
server? Does the /4gb tuning work with PAE?
KevinSo processor is ruled out. That's good.
I suggest you look at the chapter we put in the SQL 2K HA
book which explains how memory works in depth. To access
8 GB of memory under 32-bit, you need to put /PAE in
boot.ini. There is no other way. With /3GB, you can get
up to 3 GB of usable memory (different space tho), and 1
GB is always reserved for the OS. Up to 16 GB, both can
technically play together, and some applications need it.
beyond 16 GB on 32-bit machines, you cannot combine /3GB
and /PAE.
So if you have 8 GB and use /PAE and /3GB, you have 7 GB
of usable memory, of which only 3 GB would be dynamic (so
one instance could potentially be set to dynamic). When
using PAE, it is best to set the AWE settings in SQL as
well as set max mem for the instance. You seem to know
what that is.
So you can run all three instances with separate memory
using /PAE only, and if you can, I'd recommend that
approach.|||Thank you for your reply, though I am still a bit confused.
I understand that using /3GB and /PAE will give me 7GB of usable RAM.
However, you say "When using PAE, it is best to set the AWE settings
in SQL as well as set max mem for the instance. You seem to know what
that is.", and while this is what I have read elsewhere, I was under
the impression that AWE settings were not available on SQL 2000
Standard?
In the next paragraph you say "So you can run all three instances with
separate memory using /PAE only, and if you can, I'd recommend that
approach." I don't think I understand this sentence. Are you saying
I should run /PAE and not /3GB /PAE along with AWE settings in SQL?
Basically, I think I'm just looking to see if I can make SQL Standard
address memory above 4GB. I know you can with Enterprise using AWE, I
just thought AWE was not usable on Standard.
Thanks,
Kevin
"Allan Hirt" <anonymous@.discussions.microsoft.com> wrote in message news:<532201c47407$87fa08c0$a501280a@.phx.gbl>...
> So processor is ruled out. That's good.
> I suggest you look at the chapter we put in the SQL 2K HA
> book which explains how memory works in depth. To access
> 8 GB of memory under 32-bit, you need to put /PAE in
> boot.ini. There is no other way. With /3GB, you can get
> up to 3 GB of usable memory (different space tho), and 1
> GB is always reserved for the OS. Up to 16 GB, both can
> technically play together, and some applications need it.
> beyond 16 GB on 32-bit machines, you cannot combine /3GB
> and /PAE.
> So if you have 8 GB and use /PAE and /3GB, you have 7 GB
> of usable memory, of which only 3 GB would be dynamic (so
> one instance could potentially be set to dynamic). When
> using PAE, it is best to set the AWE settings in SQL as
> well as set max mem for the instance. You seem to know
> what that is.
> So you can run all three instances with separate memory
> using /PAE only, and if you can, I'd recommend that
> approach.|||PMJI, but I'm 99.9% sure that SQL Standard will only ever use 2GB RAM
maximum. Doesn't matter what OS you use or what switches you have set.
Mike Kruchten
"Kevin" <kjarrard@.gmail.com> wrote in message
news:4f5b3722.0407281043.471e0365@.posting.google.com...
> Thank you for your reply, though I am still a bit confused.
> I understand that using /3GB and /PAE will give me 7GB of usable RAM.
> However, you say "When using PAE, it is best to set the AWE settings
> in SQL as well as set max mem for the instance. You seem to know what
> that is.", and while this is what I have read elsewhere, I was under
> the impression that AWE settings were not available on SQL 2000
> Standard?
> In the next paragraph you say "So you can run all three instances with
> separate memory using /PAE only, and if you can, I'd recommend that
> approach." I don't think I understand this sentence. Are you saying
> I should run /PAE and not /3GB /PAE along with AWE settings in SQL?
> Basically, I think I'm just looking to see if I can make SQL Standard
> address memory above 4GB. I know you can with Enterprise using AWE, I
> just thought AWE was not usable on Standard.
> Thanks,
> Kevin
> "Allan Hirt" <anonymous@.discussions.microsoft.com> wrote in message
news:<532201c47407$87fa08c0$a501280a@.phx.gbl>...
> > So processor is ruled out. That's good.
> >
> > I suggest you look at the chapter we put in the SQL 2K HA
> > book which explains how memory works in depth. To access
> > 8 GB of memory under 32-bit, you need to put /PAE in
> > boot.ini. There is no other way. With /3GB, you can get
> > up to 3 GB of usable memory (different space tho), and 1
> > GB is always reserved for the OS. Up to 16 GB, both can
> > technically play together, and some applications need it.
> > beyond 16 GB on 32-bit machines, you cannot combine /3GB
> > and /PAE.
> >
> > So if you have 8 GB and use /PAE and /3GB, you have 7 GB
> > of usable memory, of which only 3 GB would be dynamic (so
> > one instance could potentially be set to dynamic). When
> > using PAE, it is best to set the AWE settings in SQL as
> > well as set max mem for the instance. You seem to know
> > what that is.
> >
> > So you can run all three instances with separate memory
> > using /PAE only, and if you can, I'd recommend that
> > approach.

Consolidate SQL servers to single server

So processor is ruled out. That's good.
I suggest you look at the chapter we put in the SQL 2K HA
book which explains how memory works in depth. To access
8 GB of memory under 32-bit, you need to put /PAE in
boot.ini. There is no other way. With /3GB, you can get
up to 3 GB of usable memory (different space tho), and 1
GB is always reserved for the OS. Up to 16 GB, both can
technically play together, and some applications need it.
beyond 16 GB on 32-bit machines, you cannot combine /3GB
and /PAE.
So if you have 8 GB and use /PAE and /3GB, you have 7 GB
of usable memory, of which only 3 GB would be dynamic (so
one instance could potentially be set to dynamic). When
using PAE, it is best to set the AWE settings in SQL as
well as set max mem for the instance. You seem to know
what that is.
So you can run all three instances with separate memory
using /PAE only, and if you can, I'd recommend that
approach.Thank you for your reply, though I am still a bit confused.
I understand that using /3GB and /PAE will give me 7GB of usable RAM.
However, you say "When using PAE, it is best to set the AWE settings
in SQL as well as set max mem for the instance. You seem to know what
that is.", and while this is what I have read elsewhere, I was under
the impression that AWE settings were not available on SQL 2000
Standard?
In the next paragraph you say "So you can run all three instances with
separate memory using /PAE only, and if you can, I'd recommend that
approach." I don't think I understand this sentence. Are you saying
I should run /PAE and not /3GB /PAE along with AWE settings in SQL?
Basically, I think I'm just looking to see if I can make SQL Standard
address memory above 4GB. I know you can with Enterprise using AWE, I
just thought AWE was not usable on Standard.
Thanks,
Kevin
"Allan Hirt" <anonymous@.discussions.microsoft.com> wrote in message news:<532201c47407$87fa0
8c0$a501280a@.phx.gbl>...
> So processor is ruled out. That's good.
> I suggest you look at the chapter we put in the SQL 2K HA
> book which explains how memory works in depth. To access
> 8 GB of memory under 32-bit, you need to put /PAE in
> boot.ini. There is no other way. With /3GB, you can get
> up to 3 GB of usable memory (different space tho), and 1
> GB is always reserved for the OS. Up to 16 GB, both can
> technically play together, and some applications need it.
> beyond 16 GB on 32-bit machines, you cannot combine /3GB
> and /PAE.
> So if you have 8 GB and use /PAE and /3GB, you have 7 GB
> of usable memory, of which only 3 GB would be dynamic (so
> one instance could potentially be set to dynamic). When
> using PAE, it is best to set the AWE settings in SQL as
> well as set max mem for the instance. You seem to know
> what that is.
> So you can run all three instances with separate memory
> using /PAE only, and if you can, I'd recommend that
> approach.|||PMJI, but I'm 99.9% sure that SQL Standard will only ever use 2GB RAM
maximum. Doesn't matter what OS you use or what switches you have set.
Mike Kruchten
"Kevin" <kjarrard@.gmail.com> wrote in message
news:4f5b3722.0407281043.471e0365@.posting.google.com...
> Thank you for your reply, though I am still a bit confused.
> I understand that using /3GB and /PAE will give me 7GB of usable RAM.
> However, you say "When using PAE, it is best to set the AWE settings
> in SQL as well as set max mem for the instance. You seem to know what
> that is.", and while this is what I have read elsewhere, I was under
> the impression that AWE settings were not available on SQL 2000
> Standard?
> In the next paragraph you say "So you can run all three instances with
> separate memory using /PAE only, and if you can, I'd recommend that
> approach." I don't think I understand this sentence. Are you saying
> I should run /PAE and not /3GB /PAE along with AWE settings in SQL?
> Basically, I think I'm just looking to see if I can make SQL Standard
> address memory above 4GB. I know you can with Enterprise using AWE, I
> just thought AWE was not usable on Standard.
> Thanks,
> Kevin
> "Allan Hirt" <anonymous@.discussions.microsoft.com> wrote in message
news:<532201c47407$87fa08c0$a501280a@.phx.gbl>...[vbcol=seagreen]

Consistency of row when reading with READ UNCOMMITTED

Hello.
I have a question about the internal consistency of a single row during an
update statement when another connection is reading the data with a READ
UNCOMMITTED (also known as WITH(NOLOCK) ) isolation level.
Let me give a small example to illustrate my question.
Say I have a table T1 with some data in it:
CREATE TABLE [T1] (
[optLockVersion] rowversion NULL,
[Name] nvarchar(256) NULL,
[Note] nvarchar(256) NULL
)
INSERT INTO [T1] (Name, Note) values ("Bob", "Good guy")
With connection #1, we perform an update statement:
UPDATE [T1] set Note = "Decent guy" where [Name] = "Bob"
The above statement will update our row in two ways: it will update the
rowversion and the Note.
Now suppose a second connection tries to read in this row with an isolation
level of READ UNCOMMITTED/NOLOCK:
select * from [T1] WITH(NOLOCK)
Is it possible that the results returned from this select statement would
have updated Notes, but the rowversion would not have been updated in the
returned results? Or perhaps that the rowversion would be updated and the
new Notes would not have been updated yet?
What I'm trying to determine is if SQL server still maintains the
consistency of a single row when reading data in another connection with the
read uncommitted isolation level.
Thanks in advance for your time,
Eli Tucker
"Eli Tucker" <EliTucker@.discussions.microsoft.com> wrote in message
news:0C3A0C35-26D2-4578-9A8D-69B8353F29E4@.microsoft.com...
> Hello.
> I have a question about the internal consistency of a single row during an
> update statement when another connection is reading the data with a READ
> UNCOMMITTED (also known as WITH(NOLOCK) ) isolation level.
>
There is no guarantee about the internal consistency of a single row with
READ UNCOMMITTED/NOLOCK. None. Period.

> Let me give a small example to illustrate my question.
> Say I have a table T1 with some data in it:
> CREATE TABLE [T1] (
> [optLockVersion] rowversion NULL,
> [Name] nvarchar(256) NULL,
> [Note] nvarchar(256) NULL
> )
> INSERT INTO [T1] (Name, Note) values ("Bob", "Good guy")
> With connection #1, we perform an update statement:
> UPDATE [T1] set Note = "Decent guy" where [Name] = "Bob"
> The above statement will update our row in two ways: it will update the
> rowversion and the Note.
> Now suppose a second connection tries to read in this row with an
> isolation
> level of READ UNCOMMITTED/NOLOCK:
> select * from [T1] WITH(NOLOCK)
> Is it possible that the results returned from this select statement would
> have updated Notes, but the rowversion would not have been updated in the
> returned results? Or perhaps that the rowversion would be updated and the
> new Notes would not have been updated yet?
> What I'm trying to determine is if SQL server still maintains the
> consistency of a single row when reading data in another connection with
> the
> read uncommitted isolation level.>
Yes. It is possible. Why? Because there are no guarantees about the
correctness or consistency of results in READ UNCOMMITTED/NOLOCK. Whether
it actually happens depends on details of the algorithms used to update the
physical database pages, and on the details of the table structure.
It is very, very possible, for instance, for such a select query to do an
index seek on a nonclustered index followed by a bookmark lookup on the
clustered index. Some of the output columns will be read from the index and
others from the row data. Here there are two separate physical structures
used to construct one output row, and it will very often happen that a
NOLOCK query will return a row that never existed at any point in time.
Consider setting the database to READ COMMITTED SNAPSHOT ISOLATION to
provide non-blocking and correct query access to changing data.
David
sqlsql

Consistency of row when reading with READ UNCOMMITTED

Hello.
I have a question about the internal consistency of a single row during an
update statement when another connection is reading the data with a READ
UNCOMMITTED (also known as WITH(NOLOCK) ) isolation level.
Let me give a small example to illustrate my question.
Say I have a table T1 with some data in it:
CREATE TABLE [T1] (
[optLockVersion] rowversion NULL,
[Name] nvarchar(256) NULL,
[Note] nvarchar(256) NULL
)
INSERT INTO [T1] (Name, Note) values ("Bob", "Good guy")
With connection #1, we perform an update statement:
UPDATE [T1] set Note = "Decent guy" where [Name] = "Bob"
The above statement will update our row in two ways: it will update the
rowversion and the Note.
Now suppose a second connection tries to read in this row with an isolation
level of READ UNCOMMITTED/NOLOCK:
select * from [T1] WITH(NOLOCK)
Is it possible that the results returned from this select statement would
have updated Notes, but the rowversion would not have been updated in the
returned results? Or perhaps that the rowversion would be updated and the
new Notes would not have been updated yet?
What I'm trying to determine is if SQL server still maintains the
consistency of a single row when reading data in another connection with the
read uncommitted isolation level.
Thanks in advance for your time,
--
Eli Tucker"Eli Tucker" <EliTucker@.discussions.microsoft.com> wrote in message
news:0C3A0C35-26D2-4578-9A8D-69B8353F29E4@.microsoft.com...
> Hello.
> I have a question about the internal consistency of a single row during an
> update statement when another connection is reading the data with a READ
> UNCOMMITTED (also known as WITH(NOLOCK) ) isolation level.
>
There is no guarantee about the internal consistency of a single row with
READ UNCOMMITTED/NOLOCK. None. Period.
> Let me give a small example to illustrate my question.
> Say I have a table T1 with some data in it:
> CREATE TABLE [T1] (
> [optLockVersion] rowversion NULL,
> [Name] nvarchar(256) NULL,
> [Note] nvarchar(256) NULL
> )
> INSERT INTO [T1] (Name, Note) values ("Bob", "Good guy")
> With connection #1, we perform an update statement:
> UPDATE [T1] set Note = "Decent guy" where [Name] = "Bob"
> The above statement will update our row in two ways: it will update the
> rowversion and the Note.
> Now suppose a second connection tries to read in this row with an
> isolation
> level of READ UNCOMMITTED/NOLOCK:
> select * from [T1] WITH(NOLOCK)
> Is it possible that the results returned from this select statement would
> have updated Notes, but the rowversion would not have been updated in the
> returned results? Or perhaps that the rowversion would be updated and the
> new Notes would not have been updated yet?
> What I'm trying to determine is if SQL server still maintains the
> consistency of a single row when reading data in another connection with
> the
> read uncommitted isolation level.>
Yes. It is possible. Why? Because there are no guarantees about the
correctness or consistency of results in READ UNCOMMITTED/NOLOCK. Whether
it actually happens depends on details of the algorithms used to update the
physical database pages, and on the details of the table structure.
It is very, very possible, for instance, for such a select query to do an
index seek on a nonclustered index followed by a bookmark lookup on the
clustered index. Some of the output columns will be read from the index and
others from the row data. Here there are two separate physical structures
used to construct one output row, and it will very often happen that a
NOLOCK query will return a row that never existed at any point in time.
Consider setting the database to READ COMMITTED SNAPSHOT ISOLATION to
provide non-blocking and correct query access to changing data.
David

Consistency of row when reading with READ UNCOMMITTED

Hello.
I have a question about the internal consistency of a single row during an
update statement when another connection is reading the data with a READ
UNCOMMITTED (also known as WITH(NOLOCK) ) isolation level.
Let me give a small example to illustrate my question.
Say I have a table T1 with some data in it:
CREATE TABLE [T1] (
[optLockVersion] rowversion NULL,
[Name] nvarchar(256) NULL,
[Note] nvarchar(256) NULL
)
INSERT INTO [T1] (Name, Note) values ("Bob", "Good guy")
With connection #1, we perform an update statement:
UPDATE [T1] set Note = "Decent guy" where [Name] = "Bob"
The above statement will update our row in two ways: it will update the
rowversion and the Note.
Now suppose a second connection tries to read in this row with an isolation
level of READ UNCOMMITTED/NOLOCK:
select * from [T1] WITH(NOLOCK)
Is it possible that the results returned from this select statement would
have updated Notes, but the rowversion would not have been updated in the
returned results? Or perhaps that the rowversion would be updated and the
new Notes would not have been updated yet?
What I'm trying to determine is if SQL server still maintains the
consistency of a single row when reading data in another connection with the
read uncommitted isolation level.
Thanks in advance for your time,
Eli Tucker"Eli Tucker" <EliTucker@.discussions.microsoft.com> wrote in message
news:0C3A0C35-26D2-4578-9A8D-69B8353F29E4@.microsoft.com...
> Hello.
> I have a question about the internal consistency of a single row during an
> update statement when another connection is reading the data with a READ
> UNCOMMITTED (also known as WITH(NOLOCK) ) isolation level.
>
There is no guarantee about the internal consistency of a single row with
READ UNCOMMITTED/NOLOCK. None. Period.

> Let me give a small example to illustrate my question.
> Say I have a table T1 with some data in it:
> CREATE TABLE [T1] (
> [optLockVersion] rowversion NULL,
> [Name] nvarchar(256) NULL,
> [Note] nvarchar(256) NULL
> )
> INSERT INTO [T1] (Name, Note) values ("Bob", "Good guy")
> With connection #1, we perform an update statement:
> UPDATE [T1] set Note = "Decent guy" where [Name] = "Bob"
> The above statement will update our row in two ways: it will update the
> rowversion and the Note.
> Now suppose a second connection tries to read in this row with an
> isolation
> level of READ UNCOMMITTED/NOLOCK:
> select * from [T1] WITH(NOLOCK)
> Is it possible that the results returned from this select statement would
> have updated Notes, but the rowversion would not have been updated in the
> returned results? Or perhaps that the rowversion would be updated and the
> new Notes would not have been updated yet?
> What I'm trying to determine is if SQL server still maintains the
> consistency of a single row when reading data in another connection with
> the
> read uncommitted isolation level.>
Yes. It is possible. Why? Because there are no guarantees about the
correctness or consistency of results in READ UNCOMMITTED/NOLOCK. Whether
it actually happens depends on details of the algorithms used to update the
physical database pages, and on the details of the table structure.
It is very, very possible, for instance, for such a select query to do an
index seek on a nonclustered index followed by a bookmark lookup on the
clustered index. Some of the output columns will be read from the index and
others from the row data. Here there are two separate physical structures
used to construct one output row, and it will very often happen that a
NOLOCK query will return a row that never existed at any point in time.
Consider setting the database to READ COMMITTED SNAPSHOT ISOLATION to
provide non-blocking and correct query access to changing data.
David

consistency errors not associated with any single object

I have a dbcc checkdb returning that I have two consistency errors. One
is directly attributal to a table. The second is not attributable to
any single objects. It is my understanding that this second consistency
error is related to an extent that is shared. Is there anyway to see
which objects share this unknown extnet? If I issue a dbcc checkdb
along with a repair allow data loss is there anyway to see what data it
will remove before it does so?
Thanks ahead of time.Please post the exact output from CHECKDB.
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"sfibich" <sfibich@.pfgc.com> wrote in message
news:uZDCRS3YEHA.644@.tk2msftngp13.phx.gbl...
> I have a dbcc checkdb returning that I have two consistency errors. One
> is directly attributal to a table. The second is not attributable to
> any single objects. It is my understanding that this second consistency
> error is related to an extent that is shared. Is there anyway to see
> which objects share this unknown extnet? If I issue a dbcc checkdb
> along with a repair allow data loss is there anyway to see what data it
> will remove before it does so?
> Thanks ahead of time.|||Paul S Randal [MS] wrote:
> Please post the exact output from CHECKDB.
>
There is an error at the very top, this is the one I am refereing to.
The error in the middle relates to a particular table that I can deal with.
Job 'DBCC_checkdb' : Step 7, 'dbcc checkdb stage' : Began Executing
2004-07-06 09:12:59
Msg 8909, Sev 16: Table error: Object ID 0, index ID 0, page ID
(3:391967). The PageId in the page header = (0:24). [SQLSTATE 42000]
Msg 2536, Sev 16: DBCC results for 'stage'. [SQLSTATE 01000]
Msg 8954, Sev 16: CHECKDB found 0 allocation errors and 1 consistency
errors not associated with any single object. [SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'sysobjects'. [SQLSTATE 01000]
Msg 2593, Sev 16: There are 329 rows in 7 pages for object 'sysobjects'.
[SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'sysindexes'. [SQLSTATE 01000]
Msg 2593, Sev 16: There are 666 rows in 37 pages for object
'sysindexes'. [SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'syscolumns'. [SQLSTATE 01000]
Msg 2593, Sev 16: There are 3400 rows in 78 pages for object
'syscolumns'. [SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'systypes'. [SQLSTATE 01000]
Msg 2593, Sev 16: There are 26 rows in 1 pages for object 'systypes'.
[SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'syscomments'. [SQLSTATE 01000]
Msg 2593, Sev 16: There are 296 rows in 81 pages for object
'syscomments'. [SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'sysfiles1'. [SQLSTATE 01000]
Msg 2593, Sev 16: There are 7 rows in 1 pages for object 'sysfiles1'.
[SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'syspermissions'. [SQLSTATE 01000]
Msg 2593, Sev 16: There are 52 rows in 1 pages for object
'syspermissions'. [SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'sysusers'. [SQLSTATE 01000]
Msg 2593, Sev 16: There are 18 rows in 1 pages for object 'sysusers'.
[SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'sysproperties'. [SQLSTATE 01000]
Msg 2593, Sev 16: There are 0 rows in 0 pages for object
'sysproperties'. [SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'sysdepends'. [SQLSTATE 01000]
Msg 2593, Sev 16: There are 2423 rows in 15 pages for object
'sysdepends'. [SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'sysreferences'. [SQLSTATE 01000]
Msg 2593, Sev 16: There are 3 rows in 1 pages for object
'sysreferences'. [SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'sysfulltextcatalogs'. [SQLSTATE 01000]
Msg 2593, Sev 16: There are 0 rows in 0 pages for object
'sysfulltextcatalogs'. [SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'sysfulltextnotify'. [SQLSTATE 01000]
Msg 2593, Sev 16: There are 0 rows in 0 pages for object
'sysfulltextnotify'. [SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'sysfilegroups'. [SQLSTATE 01000]
Msg 2593, Sev 16: There are 6 rows in 1 pages for object
'sysfilegroups'. [SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'meta_control_missing_day_ends_tbl'.
[SQLSTATE 01000]
There are 0 rows in 0 pages for object
'meta_control_missing_day_ends_tbl'. [SQLSTATE 01000]
DBCC results for 'import_opco_AFSLHF'. [SQLSTATE 01000]
There are 6442240 rows in 715814 pages for object 'import_opco_AFSLHF'.
[SQLSTATE 01000]
DBCC results for 'import_opco_AGPODF'. [SQLSTATE 01000]
There are 4601233 rows in 678964 pages for object 'import_opco_AGPODF'.
[SQLSTATE 01000]
DBCC results for 'BRBRDF'. [SQLSTATE 01000]
There are 0 rows in 0 pages for object 'BRBRDF'. [SQLSTATE 01000]
DBCC results for 'import_opco_AHPOHF'. [SQLSTATE 01000]
There are 592812 rows in 98813 pages for object 'import_opco_AHPOHF'.
[SQLSTATE 01000]
DBCC results for 'CR01F'. [SQLSTATE 01000]
There are 1570 rows in 11 pages for object 'CR01F'. [SQLSTATE 01000]
DBCC results for 'XXX_import_pfg_CMOTYPF'. [SQLSTATE 01000]
There are 65576 rows in 227 pages for object 'XXX_import_pfg_CMOTYPF'.
[SQLSTATE 01000]
DBCC results for 'XXX_import_pfg_CMPTYPF'. [SQLSTATE 01000]
There are 5415 rows in 33 pages for object 'XXX_import_pfg_CMPTYPF'.
[SQLSTATE 01000]
DBCC results for 'TYTYPF'. [SQLSTATE 01000]
There are 20800 rows in 138 pages for object 'TYTYPF'. [SQLSTATE 01000]
DBCC results for 'XXX_import_pfg_CTOTYPF'. [SQLSTATE 01000]
There are 340193 rows in 1516 pages for object 'XXX_import_pfg_CTOTYPF'.
[SQLSTATE 01000]
DBCC results for 'meta_AJFFCTLF_Status_tbl'. [SQLSTATE 01000]
There are 5 rows in 1 pages for object 'meta_AJFFCTLF_Status_tbl'.
[SQLSTATE 01000]
DBCC results for 'AESLDF_tbl'. [SQLSTATE 01000]
There are 14807362 rows in 227806 pages for object 'AESLDF_tbl'.
[SQLSTATE 01000]
DBCC results for 'XXX_import_pfg_CTPTYPF'. [SQLSTATE 01000]
There are 35448 rows in 229 pages for object 'XXX_import_pfg_CTPTYPF'.
[SQLSTATE 01000]
DBCC results for 'AFSLHF_tbl'. [SQLSTATE 01000]
There are 751636 rows in 11219 pages for object 'AFSLHF_tbl'. [SQLSTATE
01000]
DBCC results for 'meta_MetaControlAs400Trans_Status_tbl'. [SQLSTATE 01000]
There are 7 rows in 1 pages for object
'meta_MetaControlAs400Trans_Status_tbl'. [SQLSTATE 01000]
DBCC results for 'AGPODF_tbl'. [SQLSTATE 01000]
There are 531337 rows in 6561 pages for object 'AGPODF_tbl'. [SQLSTATE
01000]
DBCC results for 'import_pfg_LOCDMAST'. [SQLSTATE 01000]
There are 3300 rows in 27 pages for object 'import_pfg_LOCDMAST'.
[SQLSTATE 01000]
DBCC results for 'AHPOHF_tbl'. [SQLSTATE 01000]
There are 68367 rows in 732 pages for object 'AHPOHF_tbl'. [SQLSTATE 01000]
DBCC results for 'import_pfg_LOCMAST'. [SQLSTATE 01000]
There are 42331 rows in 321 pages for object 'import_pfg_LOCMAST'.
[SQLSTATE 01000]
DBCC results for 'ajffctlf_tbl'. [SQLSTATE 01000]
There are 16194 rows in 443 pages for object 'ajffctlf_tbl'. [SQLSTATE
01000]
DBCC results for 'import_pfg_LOCRMAST'. [SQLSTATE 01000]
There are 3210 rows in 26 pages for object 'import_pfg_LOCRMAST'.
[SQLSTATE 01000]
DBCC results for 'FM03MJF'. [SQLSTATE 01000]
There are 3505 rows in 23 pages for object 'FM03MJF'. [SQLSTATE 01000]
DBCC results for 'meta_control_AS400_trans'. [SQLSTATE 01000]
There are 112799 rows in 1849 pages for object
'meta_control_AS400_trans'. [SQLSTATE 01000]
DBCC results for 'meta_logging_AS400_trans'. [SQLSTATE 01000]
There are 18121 rows in 154 pages for object 'meta_logging_AS400_trans'.
[SQLSTATE 01000]
DBCC results for 'sys_time'. [SQLSTATE 01000]
There are 0 rows in 0 pages for object 'sys_time'. [SQLSTATE 01000]
DBCC results for 'sys_time_fiscal'. [SQLSTATE 01000]
There are 0 rows in 0 pages for object 'sys_time_fiscal'. [SQLSTATE 01000]
DBCC results for 'meta_certification_history'. [SQLSTATE 01000]
There are 49337 rows in 537 pages for object
'meta_certification_history'. [SQLSTATE 01000]
DBCC results for 'meta_certification_current'. [SQLSTATE 01000]
There are 400 rows in 17 pages for object 'meta_certification_current'.
[SQLSTATE 01000]
DBCC results for 'meta_table_types_tbl'. [SQLSTATE 01000]
There are 4 rows in 1 pages for object 'meta_table_types_tbl'. [SQLSTATE
01000]
DBCC results for 'dtproperties'. [SQLSTATE 01000]
There are 28 rows in 1 pages for object 'dtproperties'. [SQLSTATE 01000]
DBCC results for 'meta_control_AJ_import_tbl'. [SQLSTATE 01000]
There are 8 rows in 4 pages for object 'meta_control_AJ_import_tbl'.
[SQLSTATE 01000]
Msg 8928, Sev 16: Object ID 880722190, index ID 0: Page (3:391967) could
not be processed. See other errors for details. [SQLSTATE 42000]
Msg 2536, Sev 16: DBCC results for 'import_opco_AESLDF_2001'. [SQLSTATE
01000]
Msg 2593, Sev 16: There are 18047893 rows in 2255990 pages for object
'import_opco_AESLDF_2001'. [SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'maxdayend'. [SQLSTATE 01000]
Msg 2593, Sev 16: There are 1739 rows in 6 pages for object 'maxdayend'.
[SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'import_opco_AESLDF_2002'. [SQLSTATE
01000]
Msg 2593, Sev 16: There are 39724816 rows in 5062006 pages for object
'import_opco_AESLDF_2002'. [SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'import_opco_AESLDF_2003'. [SQLSTATE
01000]
Msg 2593, Sev 16: There are 51367587 rows in 7716283 pages for object
'import_opco_AESLDF_2003'. [SQLSTATE 01000]
Msg 8990, Sev 16: CHECKDB found 0 allocation errors and 1 consistency
errors in table 'import_opco_AESLDF_2003' (object ID 880722190).
[SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'import_opco_AESLDF_default'.
[SQLSTATE 01000]
Msg 2593, Sev 16: There are 178 rows in 23 pages for object
'import_opco_AESLDF_default'. [SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'sf_opco_item_temp'. [SQLSTATE 01000]
Msg 2593, Sev 16: There are 18025657 rows in 559636 pages for object
'sf_opco_item_temp'. [SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'meta_operation'. [SQLSTATE 01000]
Msg 2593, Sev 16: There are 7 rows in 1 pages for object
'meta_operation'. [SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'meta_control_as400_trans_02'.
[SQLSTATE 01000]
Msg 2593, Sev 16: There are 404306 rows in 2230 pages for object
'meta_control_as400_trans_02'. [SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'CLCLSF'. [SQLSTATE 01000]
Msg 2593, Sev 16: There are 18710 rows in 135 pages for object 'CLCLSF'.
[SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'CSCHNF'. [SQLSTATE 01000]
Msg 2593, Sev 16: There are 67202 rows in 505 pages for object 'CSCHNF'.
[SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'CSFRCF'. [SQLSTATE 01000]
Msg 2593, Sev 16: There are 619 rows in 9 pages for object 'CSFRCF'.
[SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'CSGROUPD'. [SQLSTATE 01000]
Msg 2593, Sev 16: There are 357624 rows in 2430 pages for object
'CSGROUPD'. [SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'CSGROUPH'. [SQLSTATE 01000]
Msg 2593, Sev 16: There are 167472 rows in 1173 pages for object
'CSGROUPH'. [SQLSTATE 01000]
Msg 2536, Sev 16: DBCC results for 'ITITMF'. [SQLSTATE 01000]
Msg 2593, Sev 16: There are 29342780 rows in 846483 pages for object
'ITITMF'. [SQLSTATE 01000]
DBCC results for 'MIT01F'. [SQLSTATE 01000]
There are 2158317 rows in 8969 pages for object 'MIT01F'. [SQLSTATE 01000]
DBCC results for 'PBPBHF'. [SQLSTATE 01000]
There are 207741 rows in 1472 pages for object 'PBPBHF'. [SQLSTATE 01000]
DBCC results for 'SLSLSF'. [SQLSTATE 01000]
There are 299042 rows in 2253 pages for object 'SLSLSF'. [SQLSTATE 01000]
DBCC results for 'VNVNDF'. [SQLSTATE 01000]
There are 2085401 rows in 15823 pages for object 'VNVNDF'. [SQLSTATE 01000]
DBCC results for 'CSCSTF2'. [SQLSTATE 01000]
There are 1731565 rows in 6578 pages for object 'CSCSTF2'. [SQLSTATE 01000]
DBCC results for 'INVREGF'. [SQLSTATE 01000]
There are 386374 rows in 3488 pages for object 'INVREGF'. [SQLSTATE 01000]
DBCC results for 'OCOSCF'. [SQLSTATE 01000]
There are 0 rows in 0 pages for object 'OCOSCF'. [SQLSTATE 01000]
DBCC results for 'RMRTMF'. [SQLSTATE 01000]
There are 0 rows in 0 pages for object 'RMRTMF'. [SQLSTATE 01000]
DBCC results for 'ITBAAF'. [SQLSTATE 01000]
There are 70680533 rows in 627912 pages for object 'ITBAAF'. [SQLSTATE
01000]
DBCC results for 'STPCNTF'. [SQLSTATE 01000]
There are 7217728 rows in 44833 pages for object 'STPCNTF'. [SQLSTATE 01000]
DBCC results for 'meta_control_opco_info'. [SQLSTATE 01000]
There are 18 rows in 1 pages for object 'meta_control_opco_info'.
[SQLSTATE 01000]
DBCC results for 'AIDEHF_backup'. [SQLSTATE 01000]
There are 5553 rows in 206 pages for object 'AIDEHF_backup'. [SQLSTATE
01000]
DBCC results for 'MostCurrentVersionDayEnd'. [SQLSTATE 01000]
There are 1 rows in 1 pages for object 'MostCurrentVersionDayEnd'.
[SQLSTATE 01000]
DBCC results for 'RecordsMostCurrentLastSoldDate'. [SQLSTATE 01000]
There are 18863 rows in 177 pages for object
'RecordsMostCurrentLastSoldDate'. [SQLSTATE 01000]
DBCC results for 'meta_control_table_info'. [SQLSTATE 01000]
There are 18 rows in 1 pages for object 'meta_control_table_info'.
[SQLSTATE 01000]
DBCC results for 'cd_attribute'. [SQLSTATE 01000]
There are 0 rows in 0 pages for object 'cd_attribute'. [SQLSTATE 01000]
DBCC results for 'cd_attribute_item_xref'. [SQLSTATE 01000]
There are 0 rows in 0 pages for object 'cd_attribute_item_xref'.
[SQLSTATE 01000]
DBCC results for 'RCTYPF'. [SQLSTATE 01000]
There are 4 rows in 1 pages for object 'RCTYPF'. [SQLSTATE 01000]
DBCC results for 'cd_attribute_type'. [SQLSTATE 01000]
There are 51 rows in 1 pages for object 'cd_attribute_type'. [SQLSTATE
01000]
DBCC results for 'cd_attribute_type_xref'. [SQLSTATE 01000]
There are 2 rows in 1 pages for object 'cd_attribute_type_xref'.
[SQLSTATE 01000]
DBCC results for 'CSRECAP'. [SQLSTATE 01000]
There are 6500447 rows in 73039 pages for object 'CSRECAP'. [SQLSTATE 01000]
DBCC results for 'cd_base_item'. [SQLSTATE 01000]
There are 5492062 rows in 458052 pages for object 'cd_base_item'.
[SQLSTATE 01000]
DBCC results for 'MasterDeliveryInfo'. [SQLSTATE 01000]
There are 275 rows in 2 pages for object 'MasterDeliveryInfo'. [SQLSTATE
01000]
DBCC results for 'CSCSTF'. [SQLSTATE 01000]
There are 15585869 rows in 833613 pages for object 'CSCSTF'. [SQLSTATE
01000]
DBCC results for 'cd_brand'. [SQLSTATE 01000]
There are 220167 rows in 2489 pages for object 'cd_brand'. [SQLSTATE 01000]
DBCC results for 'FinalDeliveryInfo'. [SQLSTATE 01000]
There are 275 rows in 2 pages for object 'FinalDeliveryInfo'. [SQLSTATE
01000]
DBCC results for 'RCRECF'. [SQLSTATE 01000]
There are 19468099 rows in 150916 pages for object 'RCRECF'. [SQLSTATE
01000]
DBCC results for 'cd_brand_type'. [SQLSTATE 01000]
There are 328 rows in 5 pages for object 'cd_brand_type'. [SQLSTATE 01000]
DBCC results for 'DECTL02F'. [SQLSTATE 01000]
There are 1252068 rows in 24082 pages for object 'DECTL02F'. [SQLSTATE
01000]
DBCC results for 'cd_category'. [SQLSTATE 01000]
There are 1961 rows in 23 pages for object 'cd_category'. [SQLSTATE 01000]
DBCC results for 'cd_cop'. [SQLSTATE 01000]
There are 347 rows in 6 pages for object 'cd_cop'. [SQLSTATE 01000]
DBCC results for 'cd_item'. [SQLSTATE 01000]
There are 2878151 rows in 33269 pages for object 'cd_item'. [SQLSTATE 01000]
DBCC results for 'cd_item_xref'. [SQLSTATE 01000]
There are 32862699 rows in 119501 pages for object 'cd_item_xref'.
[SQLSTATE 01000]
DBCC results for 'cd_packer_item'. [SQLSTATE 01000]
There are 2875655 rows in 45046 pages for object 'cd_packer_item'.
[SQLSTATE 01000]
DBCC results for 'import_opco_AESLDF_2004'. [SQLSTATE 01000]
There are 12815617 rows in 2110584 pages for object
'import_opco_AESLDF_2004'. [SQLSTATE 01000]
DBCC results for 'cd_size'. [SQLSTATE 01000]
There are 1678 rows in 10 pages for object 'cd_size'. [SQLSTATE 01000]
DBCC results for 'cd_subcategory'. [SQLSTATE 01000]
There are 5449 rows in 63 pages for object 'cd_subcategory'. [SQLSTATE
01000]
DBCC results for 'cd_supplier'. [SQLSTATE 01000]
There are 274329 rows in 2633 pages for object 'cd_supplier'. [SQLSTATE
01000]
DBCC results for 'TETRTF'. [SQLSTATE 01000]
There are 4302 rows in 29 pages for object 'TETRTF'. [SQLSTATE 01000]
DBCC results for 'cd_synonym'. [SQLSTATE 01000]
There are 0 rows in 0 pages for object 'cd_synonym'. [SQLSTATE 01000]
DBCC results for 'SGSMGF'. [SQLSTATE 01000]
There are 5021 rows in 35 pages for object 'SGSMGF'. [SQLSTATE 01000]
DBCC results for 'meta_control_AI_import_tbl'. [SQLSTATE 01000]
There are 0 rows in 4 pages for object 'meta_control_AI_import_tbl'.
[SQLSTATE 01000]
DBCC results for 'cd_temp_zone'. [SQLSTATE 01000]
There are 204 rows in 2 pages for object 'cd_temp_zone'. [SQLSTATE 01000]
DBCC results for 'ajffctlf_holding_tbl'. [SQLSTATE 01000]
There are 0 rows in 1 pages for object 'ajffctlf_holding_tbl'. [SQLSTATE
01000]
DBCC results for 'cd_vendor_xref'. [SQLSTATE 01000]
There are 739871 rows in 3866 pages for object 'cd_vendor_xref'.
[SQLSTATE 01000]
DBCC results for 'cd_word'. [SQLSTATE 01000]
There are 0 rows in 0 pages for object 'cd_word'. [SQLSTATE 01000]
DBCC results for 'meta_logging_stage_errors'. [SQLSTATE 01000]
There are 0 rows in 0 pages for object 'meta_logging_stage_errors'.
[SQLSTATE 01000]
DBCC results for 'AIDEHF_tbl'. [SQLSTATE 01000]
There are 1060 rows in 70 pages for object 'AIDEHF_tbl'. [SQLSTATE 01000]
DBCC results for 'AKDFCTLF'. [SQLSTATE 01000]
There are 61 rows in 1 pages for object 'AKDFCTLF'. [SQLSTATE 01000]
DBCC results for 'AIDEHF_holding_tbl'. [SQLSTATE 01000]
There are 0 rows in 1 pages for object 'AIDEHF_holding_tbl'. [SQLSTATE
01000]
DBCC results for 'meta_control_AIDEHF_errors_tbl'. [SQLSTATE 01000]
There are 0 rows in 0 pages for object 'meta_control_AIDEHF_errors_tbl'.
[SQLSTATE 01000]
CHECKDB found 0 allocation errors and 2 consistency errors in database
'stage'. [SQLSTATE 01000]
repair_allow_data_loss is the minimum repair level for the errors found
by DBCC CHECKDB (stage ). [SQLSTATE 01000]
DBCC execution completed. If DBCC printed error messages, contact your
system administrator. [SQLSTATE 01000]|||The page is corrupt (bad page id) and won't be processed. Depending on how
corrupt the page header is you may or may not be able to work out which
object/index it's from, but that's beyond the scope of this forum. I suspect
its a data page in a heap as there are no b-tree linkage errors and no
errors that would suggest its an IAM page. That being the case, the repair
is to delete the page (and hence all the data on the page) - that's why the
repair option is called REPAIR_ALLOW_DATA_LOSS. Given that it's probably a
heap data page, there's no easy way to work out what data will be deleted.
Your best course of action is to restore from your most recent backup and
then restore your log backups to the point of failure. Failing that, you'll
have to run repair. I suggest you do root-cause analysis to find out how
this happened - look in your NT event logs and the SQL errorlog for IO
subsystem errors.
I'd further suggest that you call Product Support to help you with this if
you're uncomfortable with any of the above.
Regards.
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"sfibich" <sfibich@.pfgc.com> wrote in message
news:eQT7#l5YEHA.1656@.TK2MSFTNGP09.phx.gbl...
> Paul S Randal [MS] wrote:
> > Please post the exact output from CHECKDB.
> >
> There is an error at the very top, this is the one I am refereing to.
> The error in the middle relates to a particular table that I can deal
with.
> Job 'DBCC_checkdb' : Step 7, 'dbcc checkdb stage' : Began Executing
> 2004-07-06 09:12:59
> Msg 8909, Sev 16: Table error: Object ID 0, index ID 0, page ID
> (3:391967). The PageId in the page header = (0:24). [SQLSTATE 42000]
> Msg 2536, Sev 16: DBCC results for 'stage'. [SQLSTATE 01000]
> Msg 8954, Sev 16: CHECKDB found 0 allocation errors and 1 consistency
> errors not associated with any single object. [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'sysobjects'. [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 329 rows in 7 pages for object 'sysobjects'.
> [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'sysindexes'. [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 666 rows in 37 pages for object
> 'sysindexes'. [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'syscolumns'. [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 3400 rows in 78 pages for object
> 'syscolumns'. [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'systypes'. [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 26 rows in 1 pages for object 'systypes'.
> [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'syscomments'. [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 296 rows in 81 pages for object
> 'syscomments'. [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'sysfiles1'. [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 7 rows in 1 pages for object 'sysfiles1'.
> [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'syspermissions'. [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 52 rows in 1 pages for object
> 'syspermissions'. [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'sysusers'. [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 18 rows in 1 pages for object 'sysusers'.
> [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'sysproperties'. [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 0 rows in 0 pages for object
> 'sysproperties'. [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'sysdepends'. [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 2423 rows in 15 pages for object
> 'sysdepends'. [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'sysreferences'. [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 3 rows in 1 pages for object
> 'sysreferences'. [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'sysfulltextcatalogs'. [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 0 rows in 0 pages for object
> 'sysfulltextcatalogs'. [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'sysfulltextnotify'. [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 0 rows in 0 pages for object
> 'sysfulltextnotify'. [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'sysfilegroups'. [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 6 rows in 1 pages for object
> 'sysfilegroups'. [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'meta_control_missing_day_ends_tbl'.
> [SQLSTATE 01000]
> There are 0 rows in 0 pages for object
> 'meta_control_missing_day_ends_tbl'. [SQLSTATE 01000]
> DBCC results for 'import_opco_AFSLHF'. [SQLSTATE 01000]
> There are 6442240 rows in 715814 pages for object 'import_opco_AFSLHF'.
> [SQLSTATE 01000]
> DBCC results for 'import_opco_AGPODF'. [SQLSTATE 01000]
> There are 4601233 rows in 678964 pages for object 'import_opco_AGPODF'.
> [SQLSTATE 01000]
> DBCC results for 'BRBRDF'. [SQLSTATE 01000]
> There are 0 rows in 0 pages for object 'BRBRDF'. [SQLSTATE 01000]
> DBCC results for 'import_opco_AHPOHF'. [SQLSTATE 01000]
> There are 592812 rows in 98813 pages for object 'import_opco_AHPOHF'.
> [SQLSTATE 01000]
> DBCC results for 'CR01F'. [SQLSTATE 01000]
> There are 1570 rows in 11 pages for object 'CR01F'. [SQLSTATE 01000]
> DBCC results for 'XXX_import_pfg_CMOTYPF'. [SQLSTATE 01000]
> There are 65576 rows in 227 pages for object 'XXX_import_pfg_CMOTYPF'.
> [SQLSTATE 01000]
> DBCC results for 'XXX_import_pfg_CMPTYPF'. [SQLSTATE 01000]
> There are 5415 rows in 33 pages for object 'XXX_import_pfg_CMPTYPF'.
> [SQLSTATE 01000]
> DBCC results for 'TYTYPF'. [SQLSTATE 01000]
> There are 20800 rows in 138 pages for object 'TYTYPF'. [SQLSTATE 01000]
> DBCC results for 'XXX_import_pfg_CTOTYPF'. [SQLSTATE 01000]
> There are 340193 rows in 1516 pages for object 'XXX_import_pfg_CTOTYPF'.
> [SQLSTATE 01000]
> DBCC results for 'meta_AJFFCTLF_Status_tbl'. [SQLSTATE 01000]
> There are 5 rows in 1 pages for object 'meta_AJFFCTLF_Status_tbl'.
> [SQLSTATE 01000]
> DBCC results for 'AESLDF_tbl'. [SQLSTATE 01000]
> There are 14807362 rows in 227806 pages for object 'AESLDF_tbl'.
> [SQLSTATE 01000]
> DBCC results for 'XXX_import_pfg_CTPTYPF'. [SQLSTATE 01000]
> There are 35448 rows in 229 pages for object 'XXX_import_pfg_CTPTYPF'.
> [SQLSTATE 01000]
> DBCC results for 'AFSLHF_tbl'. [SQLSTATE 01000]
> There are 751636 rows in 11219 pages for object 'AFSLHF_tbl'. [SQLSTATE
> 01000]
> DBCC results for 'meta_MetaControlAs400Trans_Status_tbl'. [SQLSTATE 01000]
> There are 7 rows in 1 pages for object
> 'meta_MetaControlAs400Trans_Status_tbl'. [SQLSTATE 01000]
> DBCC results for 'AGPODF_tbl'. [SQLSTATE 01000]
> There are 531337 rows in 6561 pages for object 'AGPODF_tbl'. [SQLSTATE
> 01000]
> DBCC results for 'import_pfg_LOCDMAST'. [SQLSTATE 01000]
> There are 3300 rows in 27 pages for object 'import_pfg_LOCDMAST'.
> [SQLSTATE 01000]
> DBCC results for 'AHPOHF_tbl'. [SQLSTATE 01000]
> There are 68367 rows in 732 pages for object 'AHPOHF_tbl'. [SQLSTATE
01000]
> DBCC results for 'import_pfg_LOCMAST'. [SQLSTATE 01000]
> There are 42331 rows in 321 pages for object 'import_pfg_LOCMAST'.
> [SQLSTATE 01000]
> DBCC results for 'ajffctlf_tbl'. [SQLSTATE 01000]
> There are 16194 rows in 443 pages for object 'ajffctlf_tbl'. [SQLSTATE
> 01000]
> DBCC results for 'import_pfg_LOCRMAST'. [SQLSTATE 01000]
> There are 3210 rows in 26 pages for object 'import_pfg_LOCRMAST'.
> [SQLSTATE 01000]
> DBCC results for 'FM03MJF'. [SQLSTATE 01000]
> There are 3505 rows in 23 pages for object 'FM03MJF'. [SQLSTATE 01000]
> DBCC results for 'meta_control_AS400_trans'. [SQLSTATE 01000]
> There are 112799 rows in 1849 pages for object
> 'meta_control_AS400_trans'. [SQLSTATE 01000]
> DBCC results for 'meta_logging_AS400_trans'. [SQLSTATE 01000]
> There are 18121 rows in 154 pages for object 'meta_logging_AS400_trans'.
> [SQLSTATE 01000]
> DBCC results for 'sys_time'. [SQLSTATE 01000]
> There are 0 rows in 0 pages for object 'sys_time'. [SQLSTATE 01000]
> DBCC results for 'sys_time_fiscal'. [SQLSTATE 01000]
> There are 0 rows in 0 pages for object 'sys_time_fiscal'. [SQLSTATE 01000]
> DBCC results for 'meta_certification_history'. [SQLSTATE 01000]
> There are 49337 rows in 537 pages for object
> 'meta_certification_history'. [SQLSTATE 01000]
> DBCC results for 'meta_certification_current'. [SQLSTATE 01000]
> There are 400 rows in 17 pages for object 'meta_certification_current'.
> [SQLSTATE 01000]
> DBCC results for 'meta_table_types_tbl'. [SQLSTATE 01000]
> There are 4 rows in 1 pages for object 'meta_table_types_tbl'. [SQLSTATE
> 01000]
> DBCC results for 'dtproperties'. [SQLSTATE 01000]
> There are 28 rows in 1 pages for object 'dtproperties'. [SQLSTATE 01000]
> DBCC results for 'meta_control_AJ_import_tbl'. [SQLSTATE 01000]
> There are 8 rows in 4 pages for object 'meta_control_AJ_import_tbl'.
> [SQLSTATE 01000]
> Msg 8928, Sev 16: Object ID 880722190, index ID 0: Page (3:391967) could
> not be processed. See other errors for details. [SQLSTATE 42000]
> Msg 2536, Sev 16: DBCC results for 'import_opco_AESLDF_2001'. [SQLSTATE
> 01000]
> Msg 2593, Sev 16: There are 18047893 rows in 2255990 pages for object
> 'import_opco_AESLDF_2001'. [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'maxdayend'. [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 1739 rows in 6 pages for object 'maxdayend'.
> [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'import_opco_AESLDF_2002'. [SQLSTATE
> 01000]
> Msg 2593, Sev 16: There are 39724816 rows in 5062006 pages for object
> 'import_opco_AESLDF_2002'. [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'import_opco_AESLDF_2003'. [SQLSTATE
> 01000]
> Msg 2593, Sev 16: There are 51367587 rows in 7716283 pages for object
> 'import_opco_AESLDF_2003'. [SQLSTATE 01000]
> Msg 8990, Sev 16: CHECKDB found 0 allocation errors and 1 consistency
> errors in table 'import_opco_AESLDF_2003' (object ID 880722190).
> [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'import_opco_AESLDF_default'.
> [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 178 rows in 23 pages for object
> 'import_opco_AESLDF_default'. [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'sf_opco_item_temp'. [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 18025657 rows in 559636 pages for object
> 'sf_opco_item_temp'. [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'meta_operation'. [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 7 rows in 1 pages for object
> 'meta_operation'. [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'meta_control_as400_trans_02'.
> [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 404306 rows in 2230 pages for object
> 'meta_control_as400_trans_02'. [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'CLCLSF'. [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 18710 rows in 135 pages for object 'CLCLSF'.
> [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'CSCHNF'. [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 67202 rows in 505 pages for object 'CSCHNF'.
> [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'CSFRCF'. [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 619 rows in 9 pages for object 'CSFRCF'.
> [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'CSGROUPD'. [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 357624 rows in 2430 pages for object
> 'CSGROUPD'. [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'CSGROUPH'. [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 167472 rows in 1173 pages for object
> 'CSGROUPH'. [SQLSTATE 01000]
> Msg 2536, Sev 16: DBCC results for 'ITITMF'. [SQLSTATE 01000]
> Msg 2593, Sev 16: There are 29342780 rows in 846483 pages for object
> 'ITITMF'. [SQLSTATE 01000]
> DBCC results for 'MIT01F'. [SQLSTATE 01000]
> There are 2158317 rows in 8969 pages for object 'MIT01F'. [SQLSTATE 01000]
> DBCC results for 'PBPBHF'. [SQLSTATE 01000]
> There are 207741 rows in 1472 pages for object 'PBPBHF'. [SQLSTATE 01000]
> DBCC results for 'SLSLSF'. [SQLSTATE 01000]
> There are 299042 rows in 2253 pages for object 'SLSLSF'. [SQLSTATE 01000]
> DBCC results for 'VNVNDF'. [SQLSTATE 01000]
> There are 2085401 rows in 15823 pages for object 'VNVNDF'. [SQLSTATE
01000]
> DBCC results for 'CSCSTF2'. [SQLSTATE 01000]
> There are 1731565 rows in 6578 pages for object 'CSCSTF2'. [SQLSTATE
01000]
> DBCC results for 'INVREGF'. [SQLSTATE 01000]
> There are 386374 rows in 3488 pages for object 'INVREGF'. [SQLSTATE 01000]
> DBCC results for 'OCOSCF'. [SQLSTATE 01000]
> There are 0 rows in 0 pages for object 'OCOSCF'. [SQLSTATE 01000]
> DBCC results for 'RMRTMF'. [SQLSTATE 01000]
> There are 0 rows in 0 pages for object 'RMRTMF'. [SQLSTATE 01000]
> DBCC results for 'ITBAAF'. [SQLSTATE 01000]
> There are 70680533 rows in 627912 pages for object 'ITBAAF'. [SQLSTATE
> 01000]
> DBCC results for 'STPCNTF'. [SQLSTATE 01000]
> There are 7217728 rows in 44833 pages for object 'STPCNTF'. [SQLSTATE
01000]
> DBCC results for 'meta_control_opco_info'. [SQLSTATE 01000]
> There are 18 rows in 1 pages for object 'meta_control_opco_info'.
> [SQLSTATE 01000]
> DBCC results for 'AIDEHF_backup'. [SQLSTATE 01000]
> There are 5553 rows in 206 pages for object 'AIDEHF_backup'. [SQLSTATE
> 01000]
> DBCC results for 'MostCurrentVersionDayEnd'. [SQLSTATE 01000]
> There are 1 rows in 1 pages for object 'MostCurrentVersionDayEnd'.
> [SQLSTATE 01000]
> DBCC results for 'RecordsMostCurrentLastSoldDate'. [SQLSTATE 01000]
> There are 18863 rows in 177 pages for object
> 'RecordsMostCurrentLastSoldDate'. [SQLSTATE 01000]
> DBCC results for 'meta_control_table_info'. [SQLSTATE 01000]
> There are 18 rows in 1 pages for object 'meta_control_table_info'.
> [SQLSTATE 01000]
> DBCC results for 'cd_attribute'. [SQLSTATE 01000]
> There are 0 rows in 0 pages for object 'cd_attribute'. [SQLSTATE 01000]
> DBCC results for 'cd_attribute_item_xref'. [SQLSTATE 01000]
> There are 0 rows in 0 pages for object 'cd_attribute_item_xref'.
> [SQLSTATE 01000]
> DBCC results for 'RCTYPF'. [SQLSTATE 01000]
> There are 4 rows in 1 pages for object 'RCTYPF'. [SQLSTATE 01000]
> DBCC results for 'cd_attribute_type'. [SQLSTATE 01000]
> There are 51 rows in 1 pages for object 'cd_attribute_type'. [SQLSTATE
> 01000]
> DBCC results for 'cd_attribute_type_xref'. [SQLSTATE 01000]
> There are 2 rows in 1 pages for object 'cd_attribute_type_xref'.
> [SQLSTATE 01000]
> DBCC results for 'CSRECAP'. [SQLSTATE 01000]
> There are 6500447 rows in 73039 pages for object 'CSRECAP'. [SQLSTATE
01000]
> DBCC results for 'cd_base_item'. [SQLSTATE 01000]
> There are 5492062 rows in 458052 pages for object 'cd_base_item'.
> [SQLSTATE 01000]
> DBCC results for 'MasterDeliveryInfo'. [SQLSTATE 01000]
> There are 275 rows in 2 pages for object 'MasterDeliveryInfo'. [SQLSTATE
> 01000]
> DBCC results for 'CSCSTF'. [SQLSTATE 01000]
> There are 15585869 rows in 833613 pages for object 'CSCSTF'. [SQLSTATE
> 01000]
> DBCC results for 'cd_brand'. [SQLSTATE 01000]
> There are 220167 rows in 2489 pages for object 'cd_brand'. [SQLSTATE
01000]
> DBCC results for 'FinalDeliveryInfo'. [SQLSTATE 01000]
> There are 275 rows in 2 pages for object 'FinalDeliveryInfo'. [SQLSTATE
> 01000]
> DBCC results for 'RCRECF'. [SQLSTATE 01000]
> There are 19468099 rows in 150916 pages for object 'RCRECF'. [SQLSTATE
> 01000]
> DBCC results for 'cd_brand_type'. [SQLSTATE 01000]
> There are 328 rows in 5 pages for object 'cd_brand_type'. [SQLSTATE 01000]
> DBCC results for 'DECTL02F'. [SQLSTATE 01000]
> There are 1252068 rows in 24082 pages for object 'DECTL02F'. [SQLSTATE
> 01000]
> DBCC results for 'cd_category'. [SQLSTATE 01000]
> There are 1961 rows in 23 pages for object 'cd_category'. [SQLSTATE 01000]
> DBCC results for 'cd_cop'. [SQLSTATE 01000]
> There are 347 rows in 6 pages for object 'cd_cop'. [SQLSTATE 01000]
> DBCC results for 'cd_item'. [SQLSTATE 01000]
> There are 2878151 rows in 33269 pages for object 'cd_item'. [SQLSTATE
01000]
> DBCC results for 'cd_item_xref'. [SQLSTATE 01000]
> There are 32862699 rows in 119501 pages for object 'cd_item_xref'.
> [SQLSTATE 01000]
> DBCC results for 'cd_packer_item'. [SQLSTATE 01000]
> There are 2875655 rows in 45046 pages for object 'cd_packer_item'.
> [SQLSTATE 01000]
> DBCC results for 'import_opco_AESLDF_2004'. [SQLSTATE 01000]
> There are 12815617 rows in 2110584 pages for object
> 'import_opco_AESLDF_2004'. [SQLSTATE 01000]
> DBCC results for 'cd_size'. [SQLSTATE 01000]
> There are 1678 rows in 10 pages for object 'cd_size'. [SQLSTATE 01000]
> DBCC results for 'cd_subcategory'. [SQLSTATE 01000]
> There are 5449 rows in 63 pages for object 'cd_subcategory'. [SQLSTATE
> 01000]
> DBCC results for 'cd_supplier'. [SQLSTATE 01000]
> There are 274329 rows in 2633 pages for object 'cd_supplier'. [SQLSTATE
> 01000]
> DBCC results for 'TETRTF'. [SQLSTATE 01000]
> There are 4302 rows in 29 pages for object 'TETRTF'. [SQLSTATE 01000]
> DBCC results for 'cd_synonym'. [SQLSTATE 01000]
> There are 0 rows in 0 pages for object 'cd_synonym'. [SQLSTATE 01000]
> DBCC results for 'SGSMGF'. [SQLSTATE 01000]
> There are 5021 rows in 35 pages for object 'SGSMGF'. [SQLSTATE 01000]
> DBCC results for 'meta_control_AI_import_tbl'. [SQLSTATE 01000]
> There are 0 rows in 4 pages for object 'meta_control_AI_import_tbl'.
> [SQLSTATE 01000]
> DBCC results for 'cd_temp_zone'. [SQLSTATE 01000]
> There are 204 rows in 2 pages for object 'cd_temp_zone'. [SQLSTATE 01000]
> DBCC results for 'ajffctlf_holding_tbl'. [SQLSTATE 01000]
> There are 0 rows in 1 pages for object 'ajffctlf_holding_tbl'. [SQLSTATE
> 01000]
> DBCC results for 'cd_vendor_xref'. [SQLSTATE 01000]
> There are 739871 rows in 3866 pages for object 'cd_vendor_xref'.
> [SQLSTATE 01000]
> DBCC results for 'cd_word'. [SQLSTATE 01000]
> There are 0 rows in 0 pages for object 'cd_word'. [SQLSTATE 01000]
> DBCC results for 'meta_logging_stage_errors'. [SQLSTATE 01000]
> There are 0 rows in 0 pages for object 'meta_logging_stage_errors'.
> [SQLSTATE 01000]
> DBCC results for 'AIDEHF_tbl'. [SQLSTATE 01000]
> There are 1060 rows in 70 pages for object 'AIDEHF_tbl'. [SQLSTATE 01000]
> DBCC results for 'AKDFCTLF'. [SQLSTATE 01000]
> There are 61 rows in 1 pages for object 'AKDFCTLF'. [SQLSTATE 01000]
> DBCC results for 'AIDEHF_holding_tbl'. [SQLSTATE 01000]
> There are 0 rows in 1 pages for object 'AIDEHF_holding_tbl'. [SQLSTATE
> 01000]
> DBCC results for 'meta_control_AIDEHF_errors_tbl'. [SQLSTATE 01000]
> There are 0 rows in 0 pages for object 'meta_control_AIDEHF_errors_tbl'.
> [SQLSTATE 01000]
> CHECKDB found 0 allocation errors and 2 consistency errors in database
> 'stage'. [SQLSTATE 01000]
> repair_allow_data_loss is the minimum repair level for the errors found
> by DBCC CHECKDB (stage ). [SQLSTATE 01000]
> DBCC execution completed. If DBCC printed error messages, contact your
> system administrator. [SQLSTATE 01000]

Connectivity Portal (WIKI)

Hi All,

Wouldn’t it be nice to have a single portal to check the list of data sources SSIS can connect to? Like, if and how SSIS can connect to SAP/Oracle/DB2/SQL Server/etc? along with what to expect from that connection, such as 64-bit support, fast data load option, scalability, etc?

The know-how around connectivity in SSIS has particularly been challenging to structure in terms of gathering and reaching all sorts of connectors and data sources out there.

The challenge is due to two main reasons:

Microsoft does not have central command/control on connector developers, and the connectivity story for SSIS has mainly been the support around ADO.NET, Ole DB and ODBC libraries. Since we don’t have a certification process, it’s up to the customer to evaluate a specific third party connector before making a decision on using it.

The extensibility story offered by SSIS inherently promotes development of new/specialized connectors to new/existing data sources. Since any application can talk to any other application given the right connector, the pool of supported connectors keep growing over time.

We are working to make this story better, but in the mean time, because of this ever growing nature of connectors and their features, I thought a WIKI portal can help this community in terms of formalizing/structuring/sharing information.

And thus, I am launching a new wiki site on connectivity. Well…Blogs are kind of not as cool these days anyways J MSDN has a recent wiki initiative, but it is not quite involving the community as I’d like to have in this one.

We have a great talent pool and a huge base of know-how around connectivity in this forum. Let’s channel that into sorting out connectivity!

I created the initial site framework and provided simple samples here : http://ssis.wik.is/Home

I’ll add more stuff to it in the coming days as well, but I really want this forum to be actively editing/providing content in there.

Please take a look at it, and start growing/editing it. -> http://ssis.wik.is/Home

Ideas/questions/feedback are all welcome, you can also e-mail me directly at denizerkan@.yahoo.com

Thanks,

Deniz Erkan

PS: this is not in conflict or competition with the forum. Forum interface does not have a way to structure data to build a know-how, and the scope of this initiative is SSIS connectivity-only.

Hi Deniz,

This is commendable but are you aware of: http://wiki.sqlis.com/default.aspx/SQLISWiki/HomePage.html

-Jamie

|||

Yes, and I think it's full of very useful components, ideas and tips&tricks to get the best out of SSIS.

Connectivity is a slightly different and challenging area within SSIS that involves growing third party connectors, partner participation and new data sources, along with connectivity libraries (ADO.NET, OLE DB, ODBC) SSIS interfaces with, which makes it mostly an organic aspect of SSIS.

The connectivity wiki has by no means the goal of replacing other information portals, but to support and complement them. I'll see how the connectivity wiki initiative goes, and perhaps later we can consolidate SSIS wikis.

|||

Deniz Erkan - msft wrote:

Yes, and I think it's full of very useful components, ideas and tips&tricks to get the best out of SSIS.

Connectivity is a slightly different and challenging area within SSIS that involves growing third party connectors, partner participation and new data sources, along with connectivity libraries (ADO.NET, OLE DB, ODBC) SSIS interfaces with, which makes it mostly an organic aspect of SSIS.

The connectivity wiki has by no means the goal of replacing other information portals, but to support and complement them. I'll see how the connectivity wiki initiative goes, and perhaps later we can consolidate SSIS wikis.

OK Deniz, sounds good.

The first thing you should get up there is a webcast (or a link to one) that has exactly the same content that Jeff Bernhardt presented at PASS yesterday. It was a great session and would help to answer lots of the questions that people ask on this forum.

-Jamie