We want to store images in SQL Server 6.5 and publish these images on
our Web site. We're running both Internet Information Server (IIS) 4.0 and
Microsoft Transaction Server (MTS). My colleagues have suggested that we use an
object-oriented database such as Object Design's ObjectStore, Computer
Associates' Jasmine, or Informix's Universal Server Universal Data Option. These
products handle the data as graphics and provide methods for pattern matching
and other tasks. What do you think?
Don't lose the faith. Microsoft doesn't have an object-relational, or
universal, database such as IBM's extenders, Oracle's cartridges, Sybase's
adapters, or Informix's data blades. But Microsoft doesn't want you to buy a
competitor's relational database management system (RDBMS) or a competitor's
object database management system (ODBMS). The most common way to handle images
in SQL Server is to store URLs (or network filenames) in an image table. In
other words, you're storing 16-byte pointers to the graphics files, which can be
as large as 2GB each. You might want to store other information about the
graphics files, such as ownership and royalty information and keywords.
You can also store large binary data files using SQL Server's image
or text data types that you access via the Data Access Objects
(DAO)/Remote Data Objects (RDO)/ActiveX Data Objects (ADO) GetChunk or
AppendChunk methods. Image and text data types can each store up to 231-1
bytes of binary data. SQL Server 6.5 stores and manages data as a linked list of
2KB data pages that appear as if they were stored in a table row. SELECT
statements return text and image data up to the limit specified in the global
variable @@TEXTSIZE, and you can use READTEXT to read the data. In SQL Server
7.0, text and images are variable-length data types with the same maximum size
limit, but the rows contain only 16-byte addresses to files that contain the
data.
Microsoft isn't ignoring the special needs of giant image and multimedia
data files or the challenge of competitors' universal databases. See the http://www.terraserver.com site with TBs of SQL Server-managed geospatial data, and
read more about the topic by downloading Jim Gray's paper from http://research.microsoft.com/scalable.
I'm looking for a programmatic way to find out how long SQL Server has
been running. However, I need to be able to get the answer from a Transact-SQL
(T-SQL) script.
You can easily get this information from the sysprocesses table, a table in
the master database that contains information about processes running on the
server. The cool thing about sysprocesses is that it's not like an ordinary
table because it doesn't have permanent disk storage associated with it. SQL
Server builds the sysprocesses table dynamically whenever a user queries it, and
you can't update it. However, it contains all sorts of information, as you can
see in Table 1, that's helpful for performance tuning and doing SQL tricks.
You can figure out how long SQL Server has been running by checking the
login_time column for any of the four system processes--CHECKPOINT, Mirror
Handler, Lazy Writer, and RA Manager--that SQL Server uses to help manage
certain tasks. These processes run continuously, so you can use the login_time
for any of these processes to check the time that the server started. For
example, you can use the command
SELECT login_time FROM master ..sysprocesses WHERE spid = 1
What's a hash bucket, and why would you want more of them?
SQL Server always accesses a page from the data cache. Sometimes the page is
already there, and sometimes SQL Server needs to read the page from disk. In
either case, SQL Server must first check to see whether the page is in the data
cache. SQL Server uses a hashing algorithm with a defined number of hash buckets
controlled with the sp_configure command.
You can compare hash buckets to dresser drawers when you're looking for a
specific pair of socks. You know that the socks (data page) must be in that
drawer (hash bucket) unless they're dirty and still in the laundry (the page is
not already in the data cache). You know the socks are in the laundry (on disk)
if you search through the entire drawer (hash bucket) without finding the socks.
Of course, the time it takes to search for the socks depends on how many pairs
of socks you have in the drawer. You can search through 5 pairs of socks faster
than you can search through 50 pairs of socks.
Prev. page
1
[2]
3
4
next page 
