2012年3月27日星期二
anyone knows what happen?
However, my SQL server still attach others' 1433 port
any one know what happen it is and how to solve it?
thxYour question doesn's make any sense to me. What does "still attach others
1433 port" mean?
> I am currently using SQL server 2000 with SP3a
> However, my SQL server still attach others' 1433 port
> any one know what happen it is and how to solve it?
> thx
>
Neil Pike MVP/MCSE. Protech Computing Ltd
Reply here - no email
SQL FAQ (484 entries) see
http://forumsb.compuserve.com/gvfor...p?SRV=MSDevApps
(faqxxx.zip in lib 7)
or www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
or www.sqlserverfaq.com
or www.mssqlserver.com/faq|||sorry...let me explain to you
I have installed SP3a for my SQL server 2000
why I install SP3, since my server is attacks others server's 1433 port
so, I thought my server was infected by slammer, so I install the SP3a
however, after the installation of SP3a, my server still attacked other
server's 1433 port.
So..any solution'
thanks
"Neil Pike" <neilpike@.compuserve.com> wrote in message
news:VA.000061e6.0ddcb352@.compuserve.com...
> Your question doesn's make any sense to me. What does "still attach
others
> 1433 port" mean?
>
> Neil Pike MVP/MCSE. Protech Computing Ltd
> Reply here - no email
> SQL FAQ (484 entries) see
> http://forumsb.compuserve.com/gvfor...p?SRV=MSDevApps
> (faqxxx.zip in lib 7)
> or www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
> or www.sqlserverfaq.com
> or www.mssqlserver.com/faq
>|||Did you update ALL instances of SQL Server on that machine?
Andrew J. Kelly SQL MVP
"Utada P.W. SIU" <wing0508@.hotmail.com> wrote in message
news:eQS$B6yKEHA.3076@.TK2MSFTNGP10.phx.gbl...
> sorry...let me explain to you
> I have installed SP3a for my SQL server 2000
> why I install SP3, since my server is attacks others server's 1433 port
> so, I thought my server was infected by slammer, so I install the SP3a
> however, after the installation of SP3a, my server still attacked other
> server's 1433 port.
> So..any solution'
> thanks
> "Neil Pike" <neilpike@.compuserve.com> wrote in message
> news:VA.000061e6.0ddcb352@.compuserve.com...
> others
>|||Utada - did you definitely INSTALL SP3a, or did you just "unpack" it. When
you run it after download that just unpacks it onto the hard-drive. You the
n
need to run the actual setup routine that it creates...
> sorry...let me explain to you
> I have installed SP3a for my SQL server 2000
> why I install SP3, since my server is attacks others server's 1433 port
> so, I thought my server was infected by slammer, so I install the SP3a
> however, after the installation of SP3a, my server still attacked other
> server's 1433 port.
Neil Pike MVP/MCSE. Protech Computing Ltd
Reply here - no email
SQL FAQ (484 entries) see
http://forumsb.compuserve.com/gvfor...p?SRV=MSDevApps
(faqxxx.zip in lib 7)
or www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
or www.sqlserverfaq.com
or www.mssqlserver.com/faq|||Nah Utada's definately on to something. I just noticed this morning my sql
server is doing the same thing.
I woke up to find my network going crazy, a simple "netstat -an" shows a
whole heap of 1433 connections. Enterprise manager indicates SP3 is
installed and I downloaded and ran the SQL Server 2000 security tools
(http://www.microsoft.com/downloads/...en&FamilyID=955
2d43b-04eb-4af9-9e24-6cde4d933600#filelist) and it reports that nothing
needs patched. No other sql server instances or MSDE installed.
Futher more, if you run sqlscan:
C:\SQLCritUpdPkg\SQLScan>sqlscan -m 127.0.0.1
No need to run the SQL Critical Update utility for this instance at this
time.
server=127.0.0.1 instance=MSSQLSERVER version=SP3 language=1033
MSDEProd
uctCode=N/A MSDEPackageName=N/A platform=NT os=5.2
There's definately something similar to slammer or some variant going
around. Either that or I've missed a patch somewhere along the line?
- Simon
"Neil Pike" <neilpike@.compuserve.com> wrote in message
news:VA.000061e9.01dc39ef@.compuserve.com...
> Utada - did you definitely INSTALL SP3a, or did you just "unpack" it.
When
> you run it after download that just unpacks it onto the hard-drive. You
then
> need to run the actual setup routine that it creates...
>
> Neil Pike MVP/MCSE. Protech Computing Ltd
> Reply here - no email
> SQL FAQ (484 entries) see
> http://forumsb.compuserve.com/gvfor...p?SRV=MSDevApps
> (faqxxx.zip in lib 7)
> or www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
> or www.sqlserverfaq.com
> or www.mssqlserver.com/faq
>|||I reviewed someone SQL Server yesterday and since they had it exposed with
a public IP on the internet, and because 1433 is one of the highest scanned
ports, someone had repeated tried guessing their 'sa' password.
My advice to you:
1. Firewall. Get one if you don't have one.
2. If you don't need external machines connecting to your MSDE/SQL, have it
listen only on Shared Memory.
3. Use SQL Integrated Security. This eliminates hackers from attempting to
guess you 'sa' password.
4. Read our Best Practices.
http://www.microsoft.com/technet/pr...n/sp3sec00.mspx
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||Get a network trace of it and call it in to MS PSS. I'd never directly
connect a SQL Server box to the internet myself though anyway...
> There's definately something similar to slammer or some variant going
> around. Either that or I've missed a patch somewhere along the line?
Neil Pike MVP/MCSE. Protech Computing Ltd
Reply here - no email
SQL FAQ (484 entries) see
http://forumsb.compuserve.com/gvfor...p?SRV=MSDevApps
(faqxxx.zip in lib 7)
or www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
or www.sqlserverfaq.com
or www.mssqlserver.com/faq|||Thanks Guys. I ended up just changing from the default port as the server
does need remote access and SQL authentication enabled. The server is behind
a router with firewall and port forwarding for just the SQL port. I suspect
that changing the port is a fairly good catch-all solution to
vulnerabilities in the future also. The activity may well have been users
trying to guess the sa password, which might explain why each unique IP had
about 8 or so connections open.
- Si
"Kevin McDonnell [MSFT]" <kevmc@.online.microsoft.com> wrote in message
news:DhULSwENEHA.1368@.cpmsftngxa10.phx.gbl...
> I reviewed someone SQL Server yesterday and since they had it exposed with
> a public IP on the internet, and because 1433 is one of the highest
scanned
> ports, someone had repeated tried guessing their 'sa' password.
> My advice to you:
> 1. Firewall. Get one if you don't have one.
> 2. If you don't need external machines connecting to your MSDE/SQL, have
it
> listen only on Shared Memory.
> 3. Use SQL Integrated Security. This eliminates hackers from attempting
to
> guess you 'sa' password.
> 4. Read our Best Practices.
>
http://www.microsoft.com/technet/pr...n/sp3sec00.mspx
>
> Thanks,
> Kevin McDonnell
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>
>
2012年3月25日星期日
Anyone helps me ? I cant attach Database.
2012年3月19日星期一
any way to attach a printscreen
Am i able to attach print screens as the error message given by SQL is quite
long
tks & rdgs
Message posted via droptable.com
http://www.droptable.com/Uwe/Forums...erver/200603/1
On Mon, 20 Mar 2006 10:04:29 GMT, maxzsim via droptable.com wrote:
>Hi ,
> Am i able to attach print screens as the error message given by SQL is quite
>long
Hi maxzsim,
Depends on the front-end you are using toa ccess the groups. I see in
the headers and in the added ad that you use SQLMonster. This is nothing
but a portal to the groups - they are not hosted by SQLMonster, but they
are Usenet groups. There are more portals to these groups, similar to
SQLMonster, that are used by other users. And many users use a
newsreader and a subscription to a usenet provider to access the groups
directly.
Though some of the portals would allow you to attach a screenprint, you
really shouldn't. In usenet, all binary content should be in one of the
many "binaries" groups. This group is "text only". Not all usenet
providers respect that unwritten law of usenet - but many do, and they
would either strip the attachment off of your message before propagating
it, or block the message completely.
The best way to get a long error message here is to run the offending
query in Query Analyzer, then use copy and paste to get the error
message from the QA output screen to the message.
And if you ever do need to post a screenshot, post it somewhere on a web
site where you have access, and post a link (plus a description of what
you link to) in the message.
Hugo Kornelis, SQL Server MVP
|||Hi Hugo ,
tk you very much for ur explanation and advice
rdgs
Hugo Kornelis wrote:
>Hi maxzsim,
>Depends on the front-end you are using toa ccess the groups. I see in
>the headers and in the added ad that you use SQLMonster. This is nothing
>but a portal to the groups - they are not hosted by SQLMonster, but they
>are Usenet groups. There are more portals to these groups, similar to
>SQLMonster, that are used by other users. And many users use a
>newsreader and a subscription to a usenet provider to access the groups
>directly.
>Though some of the portals would allow you to attach a screenprint, you
>really shouldn't. In usenet, all binary content should be in one of the
>many "binaries" groups. This group is "text only". Not all usenet
>providers respect that unwritten law of usenet - but many do, and they
>would either strip the attachment off of your message before propagating
>it, or block the message completely.
>The best way to get a long error message here is to run the offending
>query in Query Analyzer, then use copy and paste to get the error
>message from the QA output screen to the message.
>And if you ever do need to post a screenshot, post it somewhere on a web
>site where you have access, and post a link (plus a description of what
>you link to) in the message.
>
Message posted via droptable.com
http://www.droptable.com/Uwe/Forums...erver/200603/1
any way to attach a printscreen
Am i able to attach print screens as the error message given by SQL is quite
long
tks & rdgs
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200603/1On Mon, 20 Mar 2006 10:04:29 GMT, maxzsim via droptable.com wrote:
>Hi ,
> Am i able to attach print screens as the error message given by SQL is qui
te
>long
Hi maxzsim,
Depends on the front-end you are using toa ccess the groups. I see in
the headers and in the added ad that you use SQLMonster. This is nothing
but a portal to the groups - they are not hosted by SQLMonster, but they
are Usenet groups. There are more portals to these groups, similar to
SQLMonster, that are used by other users. And many users use a
newsreader and a subscription to a usenet provider to access the groups
directly.
Though some of the portals would allow you to attach a screenprint, you
really shouldn't. In usenet, all binary content should be in one of the
many "binaries" groups. This group is "text only". Not all usenet
providers respect that unwritten law of usenet - but many do, and they
would either strip the attachment off of your message before propagating
it, or block the message completely.
The best way to get a long error message here is to run the offending
query in Query Analyzer, then use copy and paste to get the error
message from the QA output screen to the message.
And if you ever do need to post a screenshot, post it somewhere on a web
site where you have access, and post a link (plus a description of what
you link to) in the message.
Hugo Kornelis, SQL Server MVP|||Hi Hugo ,
tk you very much for ur explanation and advice
rdgs
Hugo Kornelis wrote:
>Hi maxzsim,
>Depends on the front-end you are using toa ccess the groups. I see in
>the headers and in the added ad that you use SQLMonster. This is nothing
>but a portal to the groups - they are not hosted by SQLMonster, but they
>are Usenet groups. There are more portals to these groups, similar to
>SQLMonster, that are used by other users. And many users use a
>newsreader and a subscription to a usenet provider to access the groups
>directly.
>Though some of the portals would allow you to attach a screenprint, you
>really shouldn't. In usenet, all binary content should be in one of the
>many "binaries" groups. This group is "text only". Not all usenet
>providers respect that unwritten law of usenet - but many do, and they
>would either strip the attachment off of your message before propagating
>it, or block the message completely.
>The best way to get a long error message here is to run the offending
>query in Query Analyzer, then use copy and paste to get the error
>message from the QA output screen to the message.
>And if you ever do need to post a screenshot, post it somewhere on a web
>site where you have access, and post a link (plus a description of what
>you link to) in the message.
>
Message posted via droptable.com
http://www.droptable.com/Uwe/Forum...server/200603/1
any way to attach a printscreen
Am i able to attach print screens as the error message given by SQL is quite
long
tks & rdgs
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200603/1On Mon, 20 Mar 2006 10:04:29 GMT, maxzsim via SQLMonster.com wrote:
>Hi ,
> Am i able to attach print screens as the error message given by SQL is quite
>long
Hi maxzsim,
Depends on the front-end you are using toa ccess the groups. I see in
the headers and in the added ad that you use SQLMonster. This is nothing
but a portal to the groups - they are not hosted by SQLMonster, but they
are Usenet groups. There are more portals to these groups, similar to
SQLMonster, that are used by other users. And many users use a
newsreader and a subscription to a usenet provider to access the groups
directly.
Though some of the portals would allow you to attach a screenprint, you
really shouldn't. In usenet, all binary content should be in one of the
many "binaries" groups. This group is "text only". Not all usenet
providers respect that unwritten law of usenet - but many do, and they
would either strip the attachment off of your message before propagating
it, or block the message completely.
The best way to get a long error message here is to run the offending
query in Query Analyzer, then use copy and paste to get the error
message from the QA output screen to the message.
And if you ever do need to post a screenshot, post it somewhere on a web
site where you have access, and post a link (plus a description of what
you link to) in the message.
--
Hugo Kornelis, SQL Server MVP|||Hi Hugo ,
tk you very much for ur explanation and advice
rdgs
Hugo Kornelis wrote:
>>Hi ,
>> Am i able to attach print screens as the error message given by SQL is quite
>>long
>Hi maxzsim,
>Depends on the front-end you are using toa ccess the groups. I see in
>the headers and in the added ad that you use SQLMonster. This is nothing
>but a portal to the groups - they are not hosted by SQLMonster, but they
>are Usenet groups. There are more portals to these groups, similar to
>SQLMonster, that are used by other users. And many users use a
>newsreader and a subscription to a usenet provider to access the groups
>directly.
>Though some of the portals would allow you to attach a screenprint, you
>really shouldn't. In usenet, all binary content should be in one of the
>many "binaries" groups. This group is "text only". Not all usenet
>providers respect that unwritten law of usenet - but many do, and they
>would either strip the attachment off of your message before propagating
>it, or block the message completely.
>The best way to get a long error message here is to run the offending
>query in Query Analyzer, then use copy and paste to get the error
>message from the QA output screen to the message.
>And if you ever do need to post a screenshot, post it somewhere on a web
>site where you have access, and post a link (plus a description of what
>you link to) in the message.
>
--
Message posted via SQLMonster.com
http://www.sqlmonster.com/Uwe/Forums.aspx/sql-server/200603/1
Any way to attach a dual-log-file database without the log files?
like to know if there's another way around it.
Our problem is that a log file got so big it filled up the drive.
Couldn't even switch it to simple mode. So the thought was to detach
it, then attach it without the log file. However, it appears that we
had two log files in that database, so we get the following when
trying to use sp_attach_single_file_db:
File activation failure. The physical file name "E:\generic
\generic_log.ldf" may be incorrect.
The log was not rebuilt because there is more than one log file.
Msg 1813, Level 16, State 2, Line 1
Could not open new database 'Generic'. CREATE DATABASE is aborted.
Any thoughts? Thanks.Did you try sp_attach_single_file_db? According to BOL for 2005, this should allow attaching a db
having one data file but multiple log files. Actually, sp_attach* procedures are deprecated so use
CREATE DATABASE ... FOR ATTACH (or in this case FOR_ATTACH__REBUILD_LOG) instead. Also, see the
information on BOL for CREATE DATABASE and ATTACH_REBUILD_LOG.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"M Bourgon" <bourgon@.gmail.com> wrote in message
news:f5c0e2d4-3530-461d-a2e0-9238074f7c0f@.21g2000hsj.googlegroups.com...
> Odd problem I ran into today - we'll restore from backups, but I'd
> like to know if there's another way around it.
> Our problem is that a log file got so big it filled up the drive.
> Couldn't even switch it to simple mode. So the thought was to detach
> it, then attach it without the log file. However, it appears that we
> had two log files in that database, so we get the following when
> trying to use sp_attach_single_file_db:
> File activation failure. The physical file name "E:\generic
> \generic_log.ldf" may be incorrect.
> The log was not rebuilt because there is more than one log file.
> Msg 1813, Level 16, State 2, Line 1
> Could not open new database 'Generic'. CREATE DATABASE is aborted.
>
> Any thoughts? Thanks.
2012年3月6日星期二
Any Problems with Large Packages?
I've been suffering with a variety of symptoms lately, and I don't know why:
Can only debug once in BIDS. After that, it can never attach to DtsDebugHost.exe. DtsDebugHost.exe never receives any CPU time, and never grows past its initial memory allocation.
Save takes a long time with 100% CPU usage. This can be as simple as openning a SQL Server Destination component to correct the metadata due to an added column in the underlying table, then saving. It takes several minutes at 100% CPU.
I've had several Visual Studio crashes today (DW has reported these)
I've read here about people with 10MB or 17MB packages, so I feel badly complaining about my 3.2MB package! However, something is going on, and I'd like to know what it is, so I can debug again.
Thanks for any help.
Rebooting can sometimes work wonders
What SP level are you running? I highly recommend SP2.
As a "good" practice, I try to keep packages small, for a variety of reasons. Smaller packages are easier to debug, seem to be more stable in BIDS, and are easier to manage in a team environment with multiple developers. My packages normally are under 1mb, and most often are 300-700kb.
|||I'm running SP2.
Once I get it out to QA, I may look into breaking it up into smaller packages. I'm sure the size is due to the 17 outputs from the XML Source all being processed in the same data flow task. At the cost of reading the XML more than once, and of creating subset schemas (so I don't get hundreds of column not used warnings), I can break some pieces off and execute them in parallel.There are performance reasons as well, as there are buffers made wide by large string and NTEXT fields.
In the meantime, I'm wondering about how to avoid that reboot issue...
|||A couple of other suggestion:
Try setting Work Offline (under the SSIS menu) to true before saving, and see if that makes a difference (it shouldn't, but I've seen stranger things).
How complex are the transformations in the data flow? You might want to use one package to read the file once, and save all the outputs to RAW files. Then have other packages that pick up the RAW files to do the rest of the processing. RAW files are extremely fast, so they don't introduce as much overhead as you might expect. On the other hand, if the transformations are simple, you won't get a lot of benefit from that approach.
|||Another wonderful behavior is that data viewers aren't working reliably. I've just given up on one pair: one each on the default output and on the error output of a derived column transformation. The final step in that execution path writes to a SQL Server Destination, and indeed, the rows get there. But they don't stop at either data viewer, and there's no path to the destination that does not go through the derived column transformation.