DNS Hostnames

I'm chewing on a DNS blacklisting system that needs to store a list of
blacklisted hosts. I am having difficulty in deciding whether to use
VARCHAR or NVARCHAR for the hostname column.
Can anyone think of a reason why I might need to store a hostname
containing, say, Chinese characters? Is that even allowed in a hostname?
Peace & happy computing,
Mike Labosh, MCSD MCT
Owner, vbSensei.Com
"Escriba coda ergo sum." -- vbSenseiHello, Mike
According to RFC 1035, a domain name may contain uppercase and
lowercase letters (A-Z, a-z), digits (0-9), hypens (-) and points (.).
According to RFC 1738, an URL may contain only printable ASCII
characters (non-printable ASCII characters, but also some printable
characters, should be encoded with %).
In conclusion, it's better to use a varchar column instead of a
nvarchar in this case.
Razvan|||VARCHAR should be used for the hostname column.
Unicode is allowed to appear in internationalized domain names (IDN) as
defined in IDNA, but it's the responsibility of the application (e.g.,
browser) to convert the IDN to restricted-ASCII representation.
From Wikipedia: http://en.wikipedia.org/wiki/Intern...ed_domain_names
Internationalizing Domain Names in Applications (IDNA) is a mechanism
defined in 2003 for handling internationalized domain names containing
non-ASCII characters. Such domain names could not be handled by the existing
DNS and name resolver infrastructure. Rather than redesigning the existing
DNS infrastructure, it was decided that non-ASCII domain names should be
converted to a suitable ASCII-based form by web browsers and other user
applications; IDNA specifies how this conversion is to be done.
Martin C K Poon
Senior Analyst Programmer
====================================
"Mike Labosh" <mlabosh_at_hotmail.com> bl
news:%23dKp$EDYGHA.1352@.TK2MSFTNGP05.phx.gbl g...
> I'm chewing on a DNS blacklisting system that needs to store a list of
> blacklisted hosts. I am having difficulty in deciding whether to use
> VARCHAR or NVARCHAR for the hostname column.
> Can anyone think of a reason why I might need to store a hostname
> containing, say, Chinese characters? Is that even allowed in a hostname?
> --
>
> Peace & happy computing,
> Mike Labosh, MCSD MCT
> Owner, vbSensei.Com
> "Escriba coda ergo sum." -- vbSensei
>
>|||> According to RFC 1035, a domain name may contain uppercase and
> lowercase letters (A-Z, a-z), digits (0-9), hypens (-) and points (.).
> According to RFC 1738, an URL may contain only printable ASCII
> characters (non-printable ASCII characters, but also some printable
> characters, should be encoded with %).
PERFECT! THANKS!
Peace & happy computing,
Mike Labosh, MCSD MCT
Owner, vbSensei.Com
"Escriba coda ergo sum." -- vbSensei

dm query taking long time

I'm running a query (see below) on my development server and its taking around 45 seconds. It hosts 18 user databases ranging from 3 MB to 400 MB. The production server, which is very similar but with only 1 25 MB user database, runs the query in less than 1 second. Both servers have been running on VMWare for almost 1 year with no problems. However last week I applied SP 2 to the development server, and yesterday I applied Critical Update KB934458. The production server is still running SQL Server 2005 Standard SP 1. Other than that, both servers are identical and running Windows 2003 Server Standard SP 1. I'm not seeing this discrepancy with other queries running against user databases.

use MyDatabase

GO

select db_name(database_id) as 'Database', o.name as 'Table',

s.index_id, index_type_desc, alloc_unit_type_desc, index_level, i.name as 'Index Name',

avg_fragmentation_in_percent, fragment_count, avg_fragment_size_in_pages,

page_count, avg_page_space_used_in_percent, record_count,

ghost_record_count, min_record_size_in_bytes, avg_record_size_in_bytes, forwarded_record_count,

schema_id, create_date, modify_date from sys.dm_db_index_physical_stats (null, null, null, null, 'DETAILED') s

join sys.objects o on s.object_id = o.object_id

join sys.indexes i on i.object_id = s.object_id and i.index_id = s.index_id

where db_name(database_id) = 'MyDatabase'

order by avg_fragmentation_in_percent desc

--order by avg_fragment_size_in_pages desc

--order by page_count desc

--order by record_count desc

--order by avg_record_size_in_bytes desc

Alright Chap check this out.

Your dev server has 18 user databases and the

sys.dm_db_index_physical_stats (null, null, null, null, 'DETAILED')

checks all the databases.

replace the first NULL with the DBID of the database mydatabase and try running it again.

Jag

|||Thanks. So, I can consider this to be normal behavior?

I reduced the number of user databases from 18 to 9. Now it runs in about 1 second. (Same query, I haven't yet made the change you suggested.) I think its safe to say that this query does not scale!
|||In 'DETAILED mode the dmv will read all pages that are used in a database. In the query that you specified, you indicated that you wanted to walk though all the pages in all the databases that were available on the system. If you have one big database with a lot of data, this command will take a long time because of all the I/O.

If you want faster (but less detailed) results, you can use 'LIMITED' mode.

Thanks,