Stored procedure prepared statement no error and not working

Doh, I looked at numerous examples online, and these were pretty much the same as I used in my example, however I did think I was missing something, then I found another example which proved that I was missing:
EXECUTE stmt;

So the complete prepared statement looks like:
PREPARE stmt FROM @SQL;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;


Database throughful design vs Quick and dirty design comparison

Trying to normalize addresses is generally a bad idea.  There isn't a lot of value to normalizing addresses.  Both of your designs are inappropriate for the vast majority of systems.

There are two things you typically do with addresses:

Use them to send mail or packages to that location.
Use them to do geospatial analysis on that location.

Since you are using states, provinces, and boroughs in your design, and not prefectures, for example, I'm assuming that you are working in a North American context.  If that's true, then you have well established postal authorities (USPS, CPC) with very well regulated postal data and readily available address data quality tools.  Even if you are working outside of US/Canada, there are probably data quality tools that will do what you need.

With validation and standardization of your address data, you can make sure that you are able to meet your first goal.

Using ZIP+4 in the US and Postal Code in many other countries, you can get everything you need for your second goal.

A lot of people are really tempted to break addresses down into granular fields.  This is a reaction to how bad address data typically is when all you have is "address_line_1, address_line_2,...".  However, breaking out lousy, unvalidated city names into its own field only mean you've got a smaller pile of garbage instead of a larger pile.  The only way to solve this is to use an address data quality tool to validate and standardize your addresses.  If you attempt to normalize your address data you end up with a big pile of many-to-many associations.  This is because addresses in real life don't fit into the neat hierarchies that you would see in a textbook.

Unless you have some really specialized need for addresses, just keep your tables simple (a few address lines, with maybe the postal code broken out) and get a good address data quality tool to scrub the data on the way in.


While I don't know the specific internal mechanism(s) that are responsible for the differences, I can say that Heaps are managed (internally) slightly differently than Clustered Indexes (and possibly also Nonclustered Indexes) :

Deleting rows from a Heap such that one or more data pages are empty (no allocated rows) does not necessarily free up that space. You will likely need to either create, and then drop, a Clustered Index on the table, or call ALTER TABLE [TableName] REBUILD; (as of SQL Server 2014 ?). Please see the Microsoft Docs page for DELETE for more details and options.
Inserting individual rows (i.e. not a set-based INSERT) into a Heap does not fill the data pages as fully as it does with Clustered Indexes. Clustered Indexes will fit rows as long as there is space for the row (data and row-overhead) plus the 2-byte overhead of the slot array. Data pages in Heaps, however, don't use the number of bytes left on the page, but instead use a very generalized indicator of how full the page is, and there aren't that many levels that are reported. The levels are something along the lines of: 0%, 20%, 50%, 80%, and 100% full. And it will switch over to 100% while there is still space for another row (and in fact, had those same number of rows been inserted in a set-based operation, then it would have filled the page as much as possible). Of course, just like with the DELETE operations, rebuilding the Heap will pack as many rows as will fit onto the data page.

Now consider the following information, taken from the "When Page Compression Occurs" section of the Microsoft Docs page for Page Compression Implementation:

  ... As data is added to the first data page, data is row-compressed. ... When the page is full, the next row to be added initiates the page compression operation. The whole page is reviewed; ...

Hence, it seems entirely inline with this other Heap behavior that they would require an ALTER TABLE REBUILD, CREATE / DROP of a Clustered Index, or a change in the Data Compression setting (all of which rebuild the heap) before the data pages are written optimally. If Heaps are not fully aware of "whole pages" (until the Heap is rebuilt) and don't know when the page is definitely full, then they wouldn't know when to initiate the page compression operation (when dealing with updates and single-row inserts).

Another technicality that would further limit some Heaps from auto-applying Page Compression (even if they otherwise could) is that applying the compression would require all Nonclustered Indexes for that Heap (if any exist) to be rebuilt. As that linked page for "Data Compression" also states:

  Changing the compression setting of a heap requires all nonclustered indexes on the table to be rebuilt so that they have pointers to the new row locations in the heap.

The "pointers" being referred to are the Row IDs (RIDs), which are a combination of: FileID, PageID, and slot/position on the page. These RIDs are copied into Nonclustered Indexes. Being a precise physical location, they are sometimes faster lookups than traversing a b-tree with the Clustered Index keys. But, one drawback of a physical location is that it can change, and that is the issue here. Clustered Indexes, however, do not suffer from this problem because their Key values are copied into Nonclustered Indexes as the pointer back to the Clustered Index. And Key values remain the same, even when their physical location changes.

Also see:

the "Managing Heaps" section of the Microsoft Docs page for Heaps (Tables without Clustered Indexes):

  To rebuild a heap to reclaim wasted space, create a clustered index on the heap, and then drop that clustered index.

the "Considerations for When You Use Row and Page Compression" section of the Microsoft Docs page for Data Compression:

  When a heap is configured for page-level compression, pages receive page-level compression only in the following ways:

  Data is bulk imported with bulk optimizations enabled.
  Data is inserted using INSERT INTO ... WITH (TABLOCK) syntax and the table does not have a nonclustered index.
  A table is rebuilt by executing the ALTER TABLE ... REBUILD statement with the PAGE compression option.

And the statement quoted in the question.


Is there a tool to check if my database is normalized to the third normal form?

Normalization absolutely is used in the real world... and hopefully you know that 3NF is only the third one of... what is is now, 8?  But 3NF should be an easy target.

However... I would venture to say that there could not be such a tool.

Normalization, technically, is an attribute of each table.  Within a given database, different tables may have different levels of normalization.

Each table represents facts... facts about instances of a certain type of thing (person, account, order, shipment, item, location) including, sometimes, foreign keys which lead you to other kinds of facts about that thing.

Normalization has to do with how accurately and efficiently facts are represented in the tables as well as the ability of table's design to prevent ambiguous and redundant data patterns.

Thus, an understanding of the actual facts is required... which is outside the scope of automated tools.

Q: Is a table with { student, subject, instructor } in 3NF?
A: What are students, subjects and instructors?

In a world where all instructors taught all subjects and each student could take any combination but not more than one course on each subject from each instructor, this table could indeed be said to be in 3NF.  In the real world, making the claim of 3NF for this table is absurd.

To understand that is isn't in 3NF requires an understanding of the nature of the facts it represents.  In our reality, this table is not going to be 3NF since (among other reasons) the subject and the instructor are associated together in ways that have nothing to do with the student.  If we have the courses where instructors teach subjects stored elsewhere in our database, why would we copy both values here instead of a foreign key from the other table indicating that the student was signed up for the course?  If the instructor is replaced, we have to change multiple records in multiple places.

The more normalized a database is, the more intrinsically consistent it is with the real world and with itself, and the more difficult it is for the database's facts to be inadvertently untrue.  Database design is an art, but it is most definitely a science as well.

Even though I do not see eye-to-eye with everything he writes, I would recommend Chris Date's book, Database Design and Relational Theory: Normal Forms and All That Jazz which goes into excruciating detail about the underlying theory of the relational model.


When you restore a database you have the option to keep restoring additional files.  Such as if you are going to restore a FULL backup and then additional LOG or DIFF files to bring the database up to date.

WITH NORECOVERY - Leave the database in a state that allows additional files to be restored.

WITH RECOVERY - Brings the database online and ready for transactions.

If you use the WITH NORECOVERY switch, you will need to issue the RECOVERY command yourself, either with the last restore or in a separate command "RESTORE DATABASE [dbname] WITH RECOVERY;"


Where does Attunity's CDC services write error data?

I found the data I was looking for.  In each target database there are a series of system tables within the schema cdc.  The error messages I wanted are in the cdc.xdbcdc_trace table.

select * from MyTarget_CT.cdc.xdbcdc_trace

There is a similar table in the MSXDBCDC database, but it is currently empty on my system.

There is also information regarding the connection status to Oracle from SQL Server in a file located, most of which I believe is also found in the trace table mentioned above.

C:\Users\CTServiceName\AppData\Local\Temp\oradiag_XXX\diag\clients\user_XXX\host_XXX\alert\log.xml


SQL Server 2012 Always-On replica change

I want to pull just DB1 off of Server C and leave it replicated between Server A and Server B. Doable?

Yes this is doable. For your scenario if you want to remove the database from availability replica you must do that from secondary replica. So you have to login into secondary replica from which you need to remove database. Expand availability database, right click on it and select remove secondary database. You can choose multiple databases to remove at one go. More information in BOL document

If you want to do using TSQL which I prefer just login into secondary replica from which you want to remove the database and run

ALTER DATABASE db_name SET HADR OFF;
GO

When a secondary database is removed, it is no longer joined to the availability group and all information about the removed secondary database is discarded by the availability group. The removed secondary database is placed in the RESTORING state.

  If I pull DB1 off of my primary and then try to add it back in, just replicating to Server B, it is grayed out.

If you remove from primary replica means you are completely removing it from AOAG. You have to remove it from secondary replica as sated above.


You need to do this through the installer. Choose remove node from cluster in the SQL Server installer.

http://msdn.microsoft.com/en-us/library/ms191545.aspx


Yes, the SELECT executing in addition to the INSERT is the behavior that should be expected.

Based on the qualification (the where exists()... clause) and the DO INSTEAD clause,
the RULE produces a sequence of queries looking like this, in pseudo-code:

IF NOT EXISTS (SELECT 1 FROM gateway_text WHERE hash=NEW.hash)
 THEN INSERT...

IF EXISTS (SELECT 1 FROM gateway_text WHERE hash=NEW.hash)
 THEN SELECT * FROM gateway_text WHERE hash=NEW.hash;

In the first step, NEW.hash is not in the table yet so the INSERT is executed (or if it's in the table already, then it's not executed, but that's not the case you're asking about).

In the second step, NEW.hash is now in the table so the SELECT is executed too.

See  Rules on INSERT, UPDATE, and DELETE in PostgreSQL documentation for more details.

The (wrong) idea that the SELECT should not be executed when the INSERT gets executed is a common misinterpretation of how RULEs work, because intuition is misleading here.
When looking at the rule, we're tempted to think that it does this:

    IF EXISTS (SELECT 1 FROM gateway_text WHERE hash=NEW.hash)
     THEN
       SELECT * FROM gateway_text WHERE hash=NEW.hash
     ELSE
       INSERT...

But it doesn't. To achieve this, a procedural language like plpgsql should be used.


Is there an easy way to SELECT FROM another session's temp table?

#temp is session scope

CREATE TABLE (Transact-SQL) - Temporary Tables

A local temporary table, #table_name, exists only for the duration of a user session or the procedure that created the temporary table.

Do the official microsoft way no tricks, it would end in a mess


There are two things wrong with it.

Firstly, you need to specify maximum data lengths for the VARCHAR columns.

Secondly, the AUTO_INCREMENT column has to be the PRIMARY KEY.

The following DDL statement will work:

CREATE TABLE CUSTOMER (
  CUS_ID INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
  CUS_NAME VARCHAR(32),
  CUS_DOB DATE,
  CUS_ADDR VARCHAR(128),
  CUS_EMAIL VARCHAR(64),
  CUS_TEL VARCHAR(16),
  CUS_PW VARCHAR(32),
  CUS_JOINDATE DATETIME,
  CUS_LASTACCESS DATE
);

Obviously you'll need to change the VARCHAR types to reflect the sizes needed for your data.


Output a table as well-formed, indented JSON

While rereading the documentation, I noticed that whereas the pretty_bool option for JSON doesn't have an indented option, there is a jsonb_pretty(from_json jsonb) function which does produce indented text (Returns from_json as indented JSON text.) which looked as if it is what you are looking for.

When you have a "normal" table (I used your DDL in the question as my template), what you have to do is first convert it to JSON using the ROW_TO_JSON function (documentation), but as discussed here and elsewhere, this only converts the table to JSON on a row-by-row basis. The JSONB_AGG function (docs here) aggregates values, including nulls, as a JSON array).

The final piece of the puzzle is the JSONB_PRETTY (discussed above) function which takes the JSON produced and outputs indented JSON text using your original query as the inner loop of the query.

Fiddle available here (and all DDL and DML is at the bottom of this answer).

SELECT JSONB_PRETTY(JSONB_AGG(tab)) AS i_json FROM
(
  SELECT
  (
    SELECT ROW_TO_JSON(x)
    FROM
    (
      SELECT c.first_level_key) AS x
    ) AS first_last,
    c.key_name, c.key_value_en
  FROM
  dictionary AS c
) AS tab;

Sample output (entire table at end of this answer):

[
    {
        "key_name": "ttttttt",
        "first_last": {
            "first_level_key": "afasaffasa"
        },
        "key_value_en": "zxccc"
    },

I believe that this is (finally!) the correct answer!

When asking a question, please always provide your version - it can be very important for providing an answer.

DDL and DML (also on the fiddle):

Create table. Note that I used the TEXT datatype instead of VARCHAR(n) for reasons discussed here and here.

CREATE TABLE dictionary
(
  id INTEGER,
  first_level_key TEXT,
  key_name TEXT,
  key_value_en TEXT,
  key_value_fr TEXT
);

Populate it:

INSERT INTO dictionary
VALUES
(4, 'afasaffasa', 'ttttttt', 'zxccc', 'zzzzzzz'),
(4, 'afasawweww', 'rrrrrrr', 'zxccc', 'zzzzzzz'),
(4, 'afayyyyyyy', 'eeeeeee', 'zxccc', 'zzzzzzz'),
(4, 'xxxxxxxxxx', 'wwwwwww', 'zxccc', 'zzzzzzz'),
(4, 'mmmmmmmmmm', 'qqqqqqq', 'zxccc', 'zzzzzzz');

Run query:

SELECT JSONB_PRETTY(JSONB_AGG(tab)) AS i_json FROM
(
  SELECT
  (
    SELECT ROW_TO_JSON(x)
    FROM
    (
      SELECT c.first_level_key) AS x
    ) AS first_last,
    c.key_name, c.key_value_en
  FROM
  dictionary AS c
) AS tab;

Result:

i_json
[
    {
        "key_name": "ttttttt",
        "first_last": {
            "first_level_key": "afasaffasa"
        },
        "key_value_en": "zxccc"
    },
    {
        "key_name": "rrrrrrr",
        "first_last": {
            "first_level_key": "afasawweww"
        },
        "key_value_en": "zxccc"
    },
    {
        "key_name": "eeeeeee",
        "first_last": {
            "first_level_key": "afayyyyyyy"
        },
        "key_value_en": "zxccc"
    },
    {
        "key_name": "wwwwwww",
        "first_last": {
            "first_level_key": "xxxxxxxxxx"
        },
        "key_value_en": "zxccc"
    },
    {
        "key_name": "qqqqqqq",
        "first_last": {
            "first_level_key": "mmmmmmmmmm"
        },
        "key_value_en": "zxccc"
    }
]


Snapshot and RCSI.When does SQL Server go to VersionStore?

Referencing the documentation about Understanding Row Versioning-Based Isolation Levels, I've extracted what I think are the important take-aways with regards to your question, but I'd recommend reading the entire post for additional valuable information.

  When either READ_COMMITTED_SNAPSHOT or ALLOW_SNAPSHOT_ISOLATION
  database option is set ON, the SQL Server Database Engine assigns a
  transaction sequence number (XSN) to each transaction that manipulates
  data using row versioning. Transactions start at the time a BEGIN
  TRANSACTION statement is executed. However, the transaction sequence
  number starts with the first read or write operation after the BEGIN
  TRANSACTION statement. The transaction sequence number is incremented
  by one each time it is assigned.

  When either the READ_COMMITTED_SNAPSHOT or
  ALLOW_SNAPSHOT_ISOLATION database options are ON, logical copies
  (versions) are maintained for all data modifications performed in the
  database. Every time a row is modified by a specific transaction, the
  instance of the Database Engine stores a version of the previously
  committed image of the row in tempdb. Each version is marked with
  the transaction sequence number of the transaction that made the
  change. The versions of modified rows are chained using a link list.
  The newest row value is always stored in the current database and
  chained to the versioned rows stored in tempdb.

  Row versions are held long enough to satisfy the requirements of
  transactions running under row versioning-based isolation levels. The
  Database Engine tracks the earliest useful transaction sequence number
  and periodically deletes all row versions stamped with transaction
  sequence numbers that are lower than the earliest useful sequence
  number.

  Behavior When Reading Data

  When a transaction using the snapshot isolation level starts, the
  instance of the Database Engine records all of the currently active
  transactions. When the snapshot transaction reads a row that has a
  version chain, the Database Engine follows the chain and retrieves the
  row where the transaction sequence number is:

  Closest to but lower than the sequence number of the snapshot    transaction reading the row.
  Not in the list of the transactions active when the snapshot    transaction started.

  Read operations performed by a snapshot transaction retrieve the last
  version of each row that had been committed at the time the snapshot
  transaction started. This provides a transactionally consistent
  snapshot of the data as it existed at the start of the transaction.

  Read-committed transactions using row versioning operate in much the
  same way. The difference is that the read-committed transaction does
  not use its own transaction sequence number when choosing row
  versions. Each time a statement is started, the read-committed
  transaction reads the latest transaction sequence number issued for
  that instance of the Database Engine. This is the transaction sequence
  number used to select the correct row versions for that statement.
  This allows read-committed transactions to see a snapshot of the data
  as it exists at the start of each statement.


What is the difference between Schema and Database in Oracle?

You can think about the schema as a user home directory in Unix. A schema and oracle user are strongly tight together. One user maps to a single schema. You can temporarily change the current schema in a similar way as you do in Unix by ALTER SESSION SET CURRENT_SCHEMA=USER1.

Objects in other schemas can be reached in the very same way as in Unix: Just precede the object name with SCHEMA. eg: USER1.TABLE1, USER2.TABLE2 would be an example. After you change the current schema to USER1 you don't need to append the USER1 prefix anymore.

A database is the most wide container, it collects schemas-users, tablespaces (datafiles are part of a tablespace) and one or more (RAC) instances.

Things get more complicated with 12c multitenant option because you can have multiple pluggable databases (PDB) in a single container database (CDB). But it is just another story.


Query data from multiple linked remote databases

I wrote something a while back, perhaps this link will help you.

http://www.mssqltips.com/sqlservertip/2017/script-to-check-all-your-linked-server-connections-for-sql-server/

I had a need to verify that the linked servers were working, especially after a server rebuild. And I had the same issues you are seeing with regards to using straight t-sql. So I ended up using Powershell in order to get the job done.

HTH


What is cool-down time in Alibaba Cloud Auto Scaling?

I had a quick check of the cool-down time documentation  and it appears to refer to the time in which auto scaling will not occur after a previous auto scaling event has completed.


To Get Currently running jobs and their Status

--- Script By: Amna Asif___________________For: sqlcache.blogspot.com
--- Purpose: Currently running jobs and their Status

    SELECT  jb.name,
            jb.originating_server ServerName,
            ja.run_requested_date JobStartTime,
            DATEDIFF(MINUTE, ja.run_requested_date, GETDATE()) as TimeElapsed_Minutes,
            case when ja.last_executed_step_id is null
                 then 'Step '+Cast (start_step_id as varchar(20)) +' ['+sstep.step_name+'] executing'
                 else 'Step ' +Cast ( last_executed_step_id+1 as varchar(20))+' ['+ lstep.step_name
                      + '] executing'
            end CurrentStepID , sstep.step_name JobStartedfromStep
            , Case ja.run_requested_source when 1 then 'SCHEDULER'
                                   when 2 then 'ALERTER'
                                   when 3 then 'BOOT'
                                   when 4 then 'USER'
                                   when 6 then 'ON_IDLE_SCHEDULE' else 'Unknown' end JobRunSource
    FROM    msdb.dbo.sysjobs_view jb
            INNER JOIN msdb.dbo.sysjobactivity ja ON jb.job_id = ja.job_id
            INNER JOIN msdb.dbo.syssessions sess ON sess.session_id = ja.session_id
            LEFT JOIN MSDB.DBO.sysjobsteps sstep ON sstep.step_id =start_step_id and sstep.job_id=jb.job_id
            LEFT JOIN MSDB.DBO.sysjobsteps lstep ON lstep.step_id =last_executed_step_id + 1 and lstep.job_id=jb.job_id
    WHERE   stop_execution_date IS NULL
            AND run_requested_date IS NOT NULL

Stop\kill Job command

USE msdb ;
GO
EXEC dbo.sp_stop_job N'Your Job Name' ;
GO


What is the meaning of the segment name of a domain index?

The Oracle Text index consists of four basic tables, referred to as the $I, $K, $N and $R tables respectively. Other tables are used when particular indexing options are turned on. The tables exist within the schema of the text index owner, and have names concatenated from DR$, the name of the index, and the suffix (e.g. $I)

Oracle Text Whitepaper

According to the whitepaper, these are tables used by Oracle Text.

Use the following query to get the index size. For example, I have an index called I_ICOL1.

SQL> select segment_name,bytes/1024/1024 MB from dba_segments where SEGMENT_NAME='I_ICOL1';

SEGMENT_NAME        MB
------------        ----------
I_ICOL1             .4375


Increase in number of temp files being generated after increasing checkpoint_timeout

Using temp files is not necessarily a bad thing.  They are nothing to worry about unless the queries that have started using them have gotten slower, or the amount of them that exist simultaneously is threatening to fill up your storage.  The change to autovacuum setting is more likely to be the cause than the change to the checkpoint setting.

What lead you to make these changes in the first place?  That could provide a clue.


Why do information_schema queries scan all databases?

The original metadata storage for MySQL was not ideal. It didn't allow transactional DDLs, it had reliability issues, and it was slow and buggy. One of the issues that created was that querying information_schema was slow.

MySQL 8.0, with some foundational work being done in 5.6 and 5.7, finally got rid of the old system (.frms), and that allowed migrating it to a native system, and even being able to create indexes for metadata tables, speeding it up considerably.

MariaDB still uses the old system, but there are tasks filed to (potentially) migrate to a new system, similar to that of MySQL 8: https://jira.mariadb.org/browse/MDEV-11655 (and related tasks). Subscribe that task on MariaDB tracker or consider sponsoring the work. Obviously I don't know, but based on my interactions on the MariaDB JIRA, they will probably want to fix that larger task first.


You may be able to use a variation of the following technique - which forces repeated 'MIN/MAX' range scans:

Assumptions

You can produce a list of all possible year/month combinations
number is not null (which it can't be as it is in the PK, but I mention it as there is a way of working around if nulls are permitted)

testbed:

create table foo(month, year, num, primary key(month, year, num)) as
with m as ( select extract(month from d) as month, extract(year from d) as year
            from (select add_months(sysdate,1-level) as d from dual connect by level<50) )
select month, year, num
from m cross join
     (select level as num from dual connect by level<100000 order by dbms_random.random());

normal query:

select distinct month, year from foo;
--gets=11656

min/max technique:

with m as ( select extract(month from d) as month, extract(year from d) as year
            from (select add_months(sysdate,1-level) as d from dual connect by level<50) )
select month, year, decode(( select min(num)
                             from foo
                             where month=m.month and year=m.year )
                           ,null, 'N', 'Y') as has_data_yn
from m;
--gets=294

Some explanation in response to comments:

In each case (the testbed and the min/max query), the subquery factoring clause just generated a list of (year, month) tuples:

with m as ( select extract(month from d) as month, extract(year from d) as year
            from (select add_months(sysdate,1-level) as d from dual connect by level<50) )
select * from m;
/*
MONTH                  YEAR
---------------------- ----------------------
1                      2012
12                     2011
11                     2011
10                     2011
...
...
*/

Then the technique uses a subquery in the select clause to check if any rows are present for the (month, year) - this subquery necessarily must only produce at most 1 row:

select min(num)
from foo
where month=m.month and year=m.year;

This is very quick because it makes use of the ordered nature of the PK - however it needs to be executed once for each month - if there are millions of rows for each month that makes sense, but not if there are few enough to fit in a small number of block.


Network Packet Payload Error when Trying to Create Distributed Availability Group

Well I finally found the problem and it was my own dumb mistake.  When you create the distributed availability group, for the LISTENER_URL clauses, you have to specify the listener DNS names, but the mirroring endpoint ports.  I was specifying the listener DNS names and the listener ports.

For example, here is my endpoint definition (note port 5022):

CREATE ENDPOINT [Hadr_endpoint]
    STATE=STARTED
    AS TCP (LISTENER_PORT = 5022, LISTENER_IP = (192.168.159.102))
    FOR DATA_MIRRORING (ROLE = ALL, AUTHENTICATION = WINDOWS NEGOTIATE
, ENCRYPTION = REQUIRED ALGORITHM AES)
GO

Here is my listener definition (note port 1435):

ALTER AVAILABILITY GROUP [AG1]
ADD LISTENER N'AG1LISTENER' (
WITH IP
((N'192.168.232.203', N'255.255.255.0')
)
, PORT=1435);
GO

And here is the CORRECT way to define the distributed AG (note listener DNS name but endpoint port):

CREATE AVAILABILITY GROUP [DistAG]
WITH (DISTRIBUTED)
AVAILABILITY GROUP ON
    'AG1' WITH
    (
    LISTENER_URL = 'tcp://AG1LISTENER:5022',
    AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
    FAILOVER_MODE = MANUAL,
    SEEDING_MODE = AUTOMATIC
    ),
    'AG2' WITH
    (
    LISTENER_URL = 'tcp://AG2LISTENER:5022',
    AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
    FAILOVER_MODE = MANUAL,
    SEEDING_MODE = AUTOMATIC
    );
GO

This is explained very clearly in the huge purple note highlighted in this article that I somehow completely overlooked before:  https://docs.microsoft.com/en-us/sql/database-engine/availability-groups/windows/configure-distributed-availability-groups?view=sql-server-2017


Unless your database is inefficient enough to read the whole row when you ask for just the IDs and the thumbnail, then don't duplicate the data. The join or sub-query to add the thumbnail when needed will not be "complex" for any good database system. You have either

SELECT <stuff>
FROM   Profile
LEFT OUTER JOIN
       Photo
       ON  Photo.user_id = Profile.user_id
       AND Photo.order = 0

or

SELECT <profilestuff>
     , thumbnail = (SELECT thumbnail
                    FROM   Photos
                    WHERE  Photo.user_id = Profile.user_id
                    AND    Photo.order = 0
                )
FROM   Profile

You'll want a the Photos table to have an index on user_id, order but you'll probably have that anyway as it is the only candidate in this table layout for the primary key.

In either case you could create a view that does this instead of including the extra lookup in all other queries that reference the profiles and need to know the thumbnail.

If you duplicate the thumbnail you have to implement keeping that cached copy in sync with the other data, and it will be wasteful of space if you are storing the actual binary file not just the filename or other reference.

You might want to add a thumbnail id to the profile table to allow the user to pick an image that isn't the first one (if they have them ordered chronologically for general display but think one from the middle best represents them, for instance).


Is good idea to implement ProxySQL in production with Docker?

HA implies that something will break.  But if all the pieces are in the same server, it seems like the most likely thing to break is the server -- taking down everything.

For HA to be really effective, you need separate servers geographically separated.

A blend would be to have such separate servers, then have dockers in each.  This could, for example, provide multiple HA systems sharing, say, 3 servers, where each system is split up for HA.

At that point, you should consider Galera (PXC or MariaDB) for its HA capabilities in 3 nodes in different locations.  Each node could be in a docker if desired.


Select complete next row based on the current row

Trying to guess your requirements here, You want to "remove" rows that are part of div-Purchase pairs.

If by remove you mean don't select them, i.e. filter them out in a where clause, then something like this might work:

with TestCTE as
(
    select ID, [Partner], [Type], Amount,
        LEAD([Type], 1) OVER (ORDER BY ID) NextType,
        LAG([Type], 1) OVER (ORDER BY ID) PreviousType
    from test
)
select ID, [Partner], [Type], Amount
from TestCTE
where NOT ( [Type] = 'div' AND [NextType] = 'Purchase' )
  and NOT ( [Type] = 'Purchase' AND [PreviousType] = 'div' )

But if by remove, you mean delete, then that's simply:

with TestCTE as
(
    select ID, [Partner], [Type], Amount,
        LEAD([Type], 1) OVER (ORDER BY ID) NextType,
        LAG([Type], 1) OVER (ORDER BY ID) PreviousType
    from test
)
DELETE
from TestCTE
where ( [Type] = 'div' AND [NextType] = 'Purchase' )
  or ( [Type] = 'Purchase' AND [PreviousType] = 'div' )

That's two examples that both use a select and a delete using a CTE and similar where clauses. If you want to update, you can use the same strategy.


Check MySQL service use following  command:

ps -ef | grep mysql

If  MySQL  process is running then first stop mysql process.

kill -9 mysql_pid

or

/etc/init.d/mysql stop

Remove mysql base and data dir. By default it's location is /usr/local/mysql.
Use  following  command:

rm -r mysql

Start with fresh installation:
Ref this link or this for MySQL  binary installation.


What is a database with ".res" in its name?

The MainDB.res is not the Actual database.Someone by mistake have created it in your data directory.

Have a look at the content of my datadir

-rwx------ 1 mysql mysql     0 2012-05-23 14:48 debian-5.1.flag
drwx------ 2 mysql mysql  4096 2012-05-28 16:09 mysql
-rwx------ 1 mysql mysql     6 2012-05-23 14:49 mysql_upgrade_info
-rw-rw---- 1 mysql mysql     5 2012-05-29 09:15 OSS-240.pid
drwx------ 2 mysql mysql 36864 2012-05-28 16:58 test
drwx------ 2 mysql mysql  4096 2012-05-29 10:39 world
drwxr-xr-x 2 mysql mysql   4096 2012-05-29 14:29 world.res

where world.res is the directory which i have created as

mkdir world.res

and now when i want to acess it in the MySQL Shell see the result(The world.res is created as #mysql50#world.res by itself.
)

mysql> use #mysql50#world.res
ERROR 1102 (42000): Incorrect database name '#mysql50#world.res'

So in my opinion the MainDB.res is not the database.

UPDATE

In MySQL you can't create the Database's that contains the word "."

mysql> create database test.res;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '.res' at line 1

so it is sure that that was not your database.


How to get (format) a Firebird v3 DATEDIFF() to the number of years, months and days all together?

are you looking something like this:

declare @d1 datetime, @d2 datetime, @y int, @m int, @d int
set @d1 = '2018-10-26'
set @d2 = '2019-12-12'

set @y = datediff(year, @d1, @d2)
set @m = datediff(month, dateadd(year, @y, @d1), @d2)
if dateadd(month, @m, dateadd(year, @y, @d1)) > @d2 set @m = @m - 1

set @d = datediff(day, dateadd(month, @m, dateadd(year, @y, @d1)), @d2)
print cast(@y as nvarchar) + ' year(s) ' + cast(@m as nvarchar) + ' month(s) and ' + cast(@d as nvarchar) + ' day(s)'

Results:

  1 year(s) 1 month(s) and 16 day(s)


TRUNCATE effectively drops and re-creates the table, so the allocated space is gone. A DELETE... command will only remove the rows but does not cause the table size on disk to automatically shrink. This would cause excessive I/O for every DELETE... command to shrink files if it were true.

Truncate Reference for MySQL 5.7


First things first. Make sure you have developed and documented a disaster recovery (DR) strategy. Spend some time thinking up ways that things can go wrong, how to recover from them, and testing them to get an idea of how long it will take, especially when restoring from a backup. Some general ideas:

mysql crashed, but server is fine: fix error and start mysql.
MySQL has to be restored from a backup: restore from a backup and start mysql <-- test this before it becomes something you have to do in an emergency.
Server died and has to be replaced: get a replacement server in place and restore from a backup.

Once you have a DR strategy and a method developed to test your backups in place, then you can move in to more periodic tasks:

test your restore process regularly. This ensures familiarity in case when it's necessary.
ensure proper indexes. If you're using percona server, you can get statistics on which indexes are unused after a given time (month or so)
slow query review. Enable the slow query log with long query time of 1second or so and use pt-query-digest to review them on a weekly/monthly basis.
read http://www.mysqlperformanceblog.com/ and blogs from http://planet.mysql.com/ .. on such a tiny database, you'll rarely have many of the performance issues of interest. So you'll have plenty of time to read up on interesting issues and how to resolve them.


Analysis service database security at application level

If your users succeed to connect to the cube with their domain users, than the server permission is too lax.

The security model of the SSAS is actually build around Windows authentication (using Windows logins). In Management Studio, right click on the SSAS server -> Properties -> Security. You'll see there who is an administrator of this instance of SSAS. All logins here will be able to do everything they want (process the cube, browse the database, backup, script..whatever).

If you want to limit the permissions, you have to go further and create roles within your SSAS db. There you'll grant whatever privileges you need for the application.

Please see further details in the following answer (and especially in the references section).

But if some server administrator is granting admin permissions to another user, you can't really do much. There was a very good advice in another question (regarding obfuscation of DB code), this should be part of the licensing process and the EULA. If the users break it, you can at least sue them.


How to view who gets kicked from my SQL Server Script?

In the Job Step Properties, on thew Advanced page, enable the option to include step output in job history:

Then include a PRINT statement in your cursor loop to output the details of each KILL.

Example:

declare @message varchar(max), @spid int, @loginame varchar(255), @cmd varchar(255), @hostname varchar(255)

-- For each row in the cursor, kill the process by spid
Fetch NEXT FROM MYCursor INTO @spid, @loginame, @hostname
While (@@FETCH_STATUS <> -1)
begin
    select @cmd = 'kill ' + cast(@spid as varchar(5))
    exec(@cmd)

    set @message = 'SPID: ' + CAST(@spid AS VARCHAR(5)) + ' | Login: ' + @loginame + ' | Host: ' + @hostname;

    PRINT @message;

    Fetch NEXT FROM MYCursor INTO @spid, @loginame, @hostname
end


"where" on json field causing Arithmetic overflow error

This isn't anything to do with JSON specifically. You see the same with

SELECT 1
WHERE  '123' > 12.0;

JSON_VALUE has a return type of nvarchar(4000).

The literal 12.0 has a datatype of numeric(3,1).

As numeric/decimal has a higher datatype precedence than nvarchar the result of the function call is cast to numeric(3,1)

You can use an explicit cast to control the scale and precision used yourself.

e.g.

 CAST(JSON_VALUE(LastReadings, '$.lastReadings."7-temp".value') AS NUMERIC(4,1)) > 12.0

Would work fine for your example data.


Have you tried parallel pg_restore, i.e. the -j flag?

fsync=off can be better than just synchronous_commit=off.  In fact, the latter might not do much at all because most of the loading should be done in large COPY commands which wouldn't be committing until the end anyway.

You can also try increasing max_wal_size.

Finally, use tools like top, vmstat, sar, perf, or strace to figure out what the bottleneck is, IO, CPU, or perhaps network or something else.


How do I design a Dimension and Fact Table from a relational database?

First, I suggest you read about star schema first. Not understanding the concepts could lead to wrong results.

You may use the transaction as your fact table as in the diagram below.

Don't use DISTINCT, instead you want to use:

SELECT ... FROM fact GROUP BY dimension data (time, transaction and bank)
WHERE condition to restrict dimension data and join with fact.


Is there a restriction which prevents you from creating a user and a role with the same name?

No, you cannot have a User and a Role with the same name.  These objects are all stored and referenced in sys.database_principals, requiring they are unique.

sys.database_principals MSDN Reference

Quoted from the name parameter:

  name : Name of principal, unique within the database.


Is $IDENTITY documented and reliable in SQL Server?

$IDENTITY (and $ROWGUID) are documented in SELECT Clause (Transact-SQL).

I would caution against using it because it will throw an error when a table doesn't have an identity column. Take these two examples - the first one works (check your Results tab), but the second one throws an error:

CREATE TABLE #EmployeesWithIdentity (EmployeeID INT IDENTITY(1,1), EmployeeName VARCHAR(50));
SELECT $IDENTITY FROM #EmployeesWithIdentity;
GO

CREATE TABLE #Employees (EmployeeName VARCHAR(50));
SELECT $IDENTITY FROM #Employees;
GO

Here's what the second one produces:

Msg 207, Level 16, State 1, Line 6
Invalid column name '$IDENTITY'.

If you're looking to find which columns have an identity field, I'd use the method described in this Stack Overflow post instead:

select COLUMN_NAME, TABLE_NAME
from INFORMATION_SCHEMA.COLUMNS
where TABLE_SCHEMA = 'dbo'
and COLUMNPROPERTY(object_id(TABLE_NAME), COLUMN_NAME, 'IsIdentity') = 1
order by TABLE_NAME

Or, using the catalog views:

SELECT s.name,t.name,c.name
FROM sys.schemas AS s
JOIN sys.tables AS t ON s.[schema_id] = t.[schema_id]
JOIN sys.identity_columns AS c ON t.[object_id] = c.[object_id];


Any system tables/views to determine query volume per table

You can use statistics data by tracking the most modified ones

   SELECT
   --into ##SQL_STATS_INFO
   --comment out h. columns for non-sql 2016 servers
  distinct
    (select db_name()) as Database_name
    ,o.name as Table_name
    ,c.name AS column_name
    ,s.name AS statistics_name

    ,p.last_updated
    ,p.rows
    ,p.rows_sampled
    ,h.range_high_key
  ,h.range_rows
  ,h.equal_rows
  ,h.distinct_range_rows
  ,h.average_range_rows
,p.modification_counter
  ,h.step_number
   --,sc.stats_column_id
  FROM sys.stats AS s
cross apply sys.dm_db_stats_properties(s.object_id, s.stats_id) p
cross apply sys.dm_db_stats_histogram(s.object_id, s.stats_id) h
INNER JOIN sys.stats_columns AS sc
ON s.object_id = sc.object_id AND s.stats_id = sc.stats_id
INNER JOIN sys.columns AS c
ON sc.object_id = c.object_id AND c.column_id = sc.column_id
inner join sys.objects o
on o.object_id = s.object_id
WHERE o.object_id > 100
and p.rows > 1000
and p.modification_counter > 100
order by o.name


Single table with multiple NULL columns vs multiple tables

There is no hard-and-fast rule.  Here's the logic I would use in coming to a decision.

In general, it is clumsy to have an array of things (delivery addresses) spread across multiple columns.

I would pull out the entire "delivery" set of columns and make a table for them. There would be one or two rows in this new table.

Then, I would do one of these approaches:

Plan A:  In the main table, have two columns:

delivery INT UNSIGNED NOT NULL,
alt_delivery INT UNSIGNED  NULL, -- note Nullable

Plan B:  The delivery table would have a column with 1 or 2 in it, indicating 1=preferred.  (Or some variant on such).  The include that column in the JOIN.

Plan B is especially good for something like phone numbers, since there can be an arbitrarily large set of such (cell, home, work, fax, etc.)  On the other hand, for delivery you may have a rather strong limit today of exactly 1 or 2 addresses.

In both cases, it is probably not wise to do any kind of de-dupping of locations or phones.  So what if there is an occasional dup; after all, cohabitation is common.

In a slightly different use case, a billing UI might ask the user "Is the shipping address the same as billing address?"  This is giving the user the option to tie the two together.  In this case, the main table has two non-null columns bill_to and send_to, that may or may not link to the same address.

In a "location" table, it is clumsy to 'normalize' city, country, etc.  And it is not justifiable for either reason for normalizing:  It does not save much space, and you aren't likely to need to change the spelling of the city/country in some central location.  (Czechoslovakia notwithstanging)


Postgres columns of latitude and longitude from varchar to numeric

You need the USING clause to ALTER TABLE ... TYPE ..., e.g.:

ALTER TABLE mytable
  ALTER COLUMN "Longitude" TYPE NUMERIC(14, 11)
    USING ("Longditude"::NUMERIC(14,11)),
  ALTER COLUMN "Latitude" TYPE NUMERIC(14, 11)
    USING ("Latitude"::NUMERIC(14,11));

assuming you want a numeric with precision 14 and scale 11 and your columns really do have an upper case first letter.

For more details see the manual on ALTER TABLE.

after edit:

You seem to be using a broken client that's trying to prepend an EXPLAIN to the ALTER TABLE. You can't EXPLAIN an ALTER TABLE statement.


RAM Impact on Oracle database operations

Praveen,

Oracle provides a lot of functionality to enable you to trace individual sessions (with waits and binds) or statements. You don't list the version in use, but most probably you can trace the inserts using DBMS_MONITOR package introduced in 10g. In 11g and if you have the relevant management pack licensed you could also use Real Time SQL Monitoring. http://download.oracle.com/docs/cd/B28359_01/server.111/b28274/instance_tune.htm#CACGEEIF If you take this approach, of tracing the problematic SQL then you can know for certain where the time is going. The most common cause by the way for slow inserts is nothing to do with RAM and everything to do with the number of indexes on the table.


SQL Server 2008 R2 Express password overwrite

As stated in the comments to your question SQL Server will not revert a password back to the previous one used. I believe the problem you are having is that your application has the sa password stored somewhere that it needs to be saved to. That is likely why you are receiving the error regarding login credentials. I would suggest checking the documentation for your application (if it is COTS) to see where the password for the SQL Login is set at.

If the application is a Windows Service you will likely find the password set in some configuration file or registry key. I would hope not in plain text, but no product is perfect. If you find the password is not in plain text (garbled or unreadable) this would indicate that the application has some configuration API (GUI or command-line/CLI) that needs to be used to set that password so the application stores it where it needs to see it.


Distributing a semi-large key/value list

An RDB would be the fastest way to replace/create an entire dataset. You can prepare the bi-annual forklift update beforehand at HQ at your convenience and ship it out to the customers. Do note that loading from RDB requires downtime.

As for the 0.1-1K updates/day per client-local Redis database - some of the real questions are:

How many updates are done to the master database?
Are all updates applied to all client/local databases?
Can the updates be batched?
Is there a latency budget for updates to be shipped to clients?
10 clients/database per customer, but how many customers overall?

I assume there are many possible solutions to this challenge, but I'm for KISSing it pimple :)


My guess is the question is something like:

I have a table that looks something like this:

+----+----------+----------+---------+
| ID |  Status  | Approved | Request |
+----+----------+----------+---------+
|  1 | NULL     | 5        | NULL    |
|  1 | Approved | NULL     | NULL    |
|  1 | NULL     | NULL     | 10      |
+----+----------+----------+---------+

And you are looking to combine all these rows into just the NON-Null values for each column.  Something like:

+----+----------+----------+---------+
| ID |  Status  | Approved | Request |
+----+----------+----------+---------+
|  1 | Approved |        5 |      10 |
+----+----------+----------+---------+

For the purpose of the examples I will show below I have created the below table.  (For the sake of cleanup ease on my side I am using Table Variables instead of a physical/temp table.)

DECLARE @Table TABLE
(
    ID INT,
    [Status] VarChar(20) NULL,
    Approved INT NULL,
    Request INT NULL
)

INSERT INTO @Table (ID, [Status], Approved, Request)
VALUES
(1, NULL, 5, NULL),
(1, 'Approved', NULL, NULL),
(1, NULL, NULL, 10)

There are a two ways to achieve this result that I am aware of:

1) Using Sub Queries in the SELECT statement.  Something like below:

SELECT T.ID,
T.[Status],
(
    SELECT TOP (1) temp1.Approved
    FROM @Table temp1
    WHERE temp1.ID = T.ID
    AND temp1.Approved IS NOT NULL
    --If Needed You can add additional WHERE clauses
    --Or you can add some kind of ORDER clause to get the value you want
) AS Approved,
(
    SELECT TOP (1) temp1.Request
    FROM @Table temp1
    WHERE temp1.ID = T.ID
    AND temp1.Request IS NOT NULL
    --If Needed You can add additional WHERE clauses
    --Or you can add some kind of ORDER clause to get the value you want
) AS Request
FROM @Table T
WHERE ID = 1
AND [Status] = 'Approved'
--If Needed You can add additional WHERE clauses

We are simply running a second and third select, selecting a single value (the TOP (1) to avoid an error where a subquery returns more than one result), and having that display as the result for that column.  The benefit of this option is it guarantees that we only get one row per instance of something in the table WHERE ID = 1 AND [Status] = 'Approved'.

2) Another option I am aware of is using additional JOINS.  Something like below:

SELECT T.ID,
T.[Status],
App.Approved,
Req.Request
FROM @Table T
    LEFT OUTER JOIN @Table App
        ON App.ID = T.ID
        AND App.Approved IS NOT NULL
    LEFT OUTER JOIN @Table Req
        ON Req.ID = T.ID
        AND Req.Request IS NOT NULL
WHERE T.ID = 1
AND T.[Status] = 'Approved'

This approach allows you to get more than just a single value for that row.  (Say there was some additional 5th column and you wanted that value from the "Request" row.  You can just add a Req.[ColumnName] in the SELECT).  This does have a possibility for returning multiple rows per ID = 1 AND [Status] = 'Approved' combination, if there are more than one row with ID = 1 AND Request IS NOT NULL OR ID = 1 and Approved IS NOT NULL.

There is a 3rd option using the XML STUFF:

Which allows you to combine multiple rows of the same column into a single "cell" using concatenation.  This is explained in great detail via this Stack Overflow Question.

Hopefully that give you what you were looking for.


MySQL doesn't store metadata about binary logs (well, it does, but only to control current and/or executed commands, not about the binlog themselves).

You can use SHOW BINLOG EVENTS to read the actual binlogs, but that most likely will not be helpful, and will be very slow (it just read the logs). Yes, the only way I can think of is to read the actual logs with mysqlbinlog and check the second line after the log position of the first and last events.

# at 256
#181130  9:28:36 server id 123  end_log_pos 545

If you don't need exact dates, there may be a shortcut for avoid reading the whole log- you can use the mtime (last modified time) of the filesystem metadata to get an aproximation of when it was last written (but not that will not be 100% acurate- flushing may be delayed by the filesystem, and the time the log was written may be different than that of when one the transaction was executed. But it may be a shortcut if you just want to find a particular event before reading just the one you are intereted in.


Can we configure Certificate-based Authentication to connect(logon) sql client?

Answer originally provided in a comment by Kin:

The answer is no.

Only Database Mirroring and Service Broker connections can authenticate using certificates.

You might want to check Remus Rusanu 's answer on Stack Overflow and his article:

How does Certificate based Authentication work?.


Multiple results from a single query into different columns

A few things table_b's schema must be fixed. You can't have an update that updates variable columns, some of which may not even be created. Because you don't know how many matches you'll have, what you likely want here is an array type.

ALTER TABLE table_b
  DROP COLUMN ID_number_X,
  ADD COLUMN ID_number_X text[];

Now you have an array type of text[] on the table.

      Table "pg_temp_6.table_b"
   Column    |   Type    | Modifiers
-------------+-----------+-----------
 column_1    | text      |
 id_number_y | integer   |
 id_number_x | integer[] |

And you can proceed creating UPDATE. Next, you need a simply query from which to do the update.

SELECT id_number_y, array_agg(id_number_x) AS id_number_x
FROM table_a
GROUP BY id_number_y;

 id_number_y |        id_number_x
-------------+---------------------------
         123 | {HT59452,HT59453,HT59454}
         101 | {HT59456}
         789 | {HT59455}

With this you can wrap the query in the UPDATE and get what you want.

UPDATE table_b AS B
SET id_number_x = A.id_number_x
FROM (
    SELECT id_number_y, array_agg(id_number_x) AS id_number_x
    FROM table_a
    GROUP BY id_number_y
) AS A
WHERE B.id_number_y = A.id_number_y;

Now you have..

# TABLE TABLE_b;
 column_1 | id_number_y |        id_number_x
----------+-------------+---------------------------
 foo      |         123 | {HT59452,HT59453,HT59454}
 bar      |         789 | {HT59455}
 baz      |         101 | {HT59456}

That said, this is rarely necessary and there are two other ways to do this which may better fit your needs,

MATERIALIZED VIEW
VIEW

Normally, this isn't needed because you simply use a JOIN.


Best Way to Grant Read All Permission in SQL Server 2008 R2?

For future databases, do this because all DBs are created from model

USE model
EXEC sp_addrolemember N'db_datareader', N'MY_DOMAIN\SQL-READ-ALL'

For existing databases, just run what you have above, once


Filtering data that could have more than one category

If I understood you correctly, one way to achieve this is getting those rows where category = 1, then check for the non-existence of non-category1 rows:

SELECT document, term
FROM Annotation ann
WHERE
    category = 1
    AND NOT EXISTS (
        SELECT 1
        FROM Annotation a
        WHERE
            a.document = ann.document
            AND a.term = ann.term
            AND category <> 1
    )
;

(Thanks to DavideChicco.it for showing that this was overly complicated).


mysql > why replace command is not working on strings coming from json encoded?

As a primer it looks like the data is being stored with the escape character \ backslash to allow the WordPress server to automatically use the data in the engine itself.

You would have to double the back-slashes to find and replace the string.

You can verify this via dbfiddle.uk.

If you run your Search String against a MySQL 8.0 instance like this:

 select 'http:\/\/dev.example.com\/example\/'

... then you will receive this:

http://dev.example.com/example/

Reference: db<>fiddle for Question 255169 (db<>fiddle)

This isn't what is stored in the database and thus will no be found.

Solution

The solution is to double the (MySQL) escape character \ into:

select 'http:\\/\\/dev.example.com\\/example\\/'

...which returns this:

http:\/\/dev.example.com\/example\/

Reference: db<>fiddle for Question 255169 (db<>fiddle)


Not an "answer", but steps for debugging...

All of these need to agree:

 tag on HTML
character_set_client, character_set_connection, and character_set_results
the WP setting (I don't know what is, try this?)
the CHARACTER SET on the columns of the relevant tables, or if nothing mentioned, then on the table, from which the columns inherit.
And the connection user should not be root.

If, however, the data is already stored in the wrong encoding, the problem is messier.  Do analyze this, do SELECT HEX(col), col ... to look at some particular thing that is causing the black diamonds (etc).  Show that to us, plus list the other things; then we can proceed.


Having generalized security across all servers / applications would be a bad approach. With your suggestion, once you let John Doe from Customer Service have read access the Customer database (which he needs in order to accomplish his job), you effectively give him read access to job applicants in an HR database. The HR database would contain Personally Identifiable Information (PII). Since John Doe is not apart of HR, he shouldn't have the permissions to access this data. Allowing him to read out of the HR database would cause compliance issues and could result in major fines when those auditors bust through the door!

John Doe would also be able to read salaries out of the Payroll database, and ohh boy, once that info goes public you're bound to have some tension in the office; employees will question why the new guy is being paid more than them, etc.

Now that I've beat that horse, here is an article I ran across recently discussing how to setup AD groups with specific levels of access to specific databases. This goes into a little bit more detail than you may need, such as creating scripts to create the AD groups, but should be a helpful start.

http://www.sqlservercentral.com/articles/Security/133778/


Rounding of SMALLMONEY Data Type in SQL Server 2005

I am fairly certain that it just looks at the third decimal digit... and that's 4 so it rounds down to 1.28.

Clarify - it looks to the digit one greater than what you are rounding to... so it looks to the third because you are rounding to the second.


In AWS Aurora's performance insights. What qualifies as "Other" and how do I investigate it?

Our AWS rep says that "Other" is the sum of all other executing queries. There's also another category called "Unknown" which is queries that AWS hasn't mapped yet.


Migrate database from one server to another without downtime

In general I don't think it's possible to move a database without any downtime with MySQL standard tools.

However you can try to use mysqldump and mysqlbinlog to minimize "data loss": see section "Example: mysqldump + mysqlbinlog for Backup and Restore" in https://dev.mysql.com/doc/refman/8.0/en/mysqlbinlog-backup.html


From your description, you'll need the following tables ("..." means you might need additional fields in that entity):

User (UserID, EmailAddress, Password ...)
Session (SessionID, CreatedDate, UserID, ExpiryDate, PurchaseCompleteInd ...)
Product (ProductID, Name, UnitPrice ...)
SessionProductLink (ProductID, SessionID, Quantity ...)

The SessionProductLink is a Junction table, which is the 'bit of the design' you were missing.

The field names in italics are foreign keys (it should be obvious which fields they link to ...). the ID fields are the clustered key fields in the first three entities, for SessionProductLink you'd want a compound key of (ProductID, SessionID). (You can use a surrogate key there if you want, that's a style decision you can make)

Other things you might want to think about:

Security. You want to store your user passwords securely encrypted (i.e. use bcrypt), if you support credit cards you legally are not allowed to store the full credit card details in most cases, etc.
Invoicing - which payment methods are you going to support? Do you want people to be able to pay for multiple 'sessions' with one invoice? (This is more common for business accounts, typically retail customers are one purchase = one invoice = one payment method) Do you want to accept foreign currencies? (Between this point and the first one, you'll almost need a payment processor to make sure you don't land yourself in massive strife ...)
What happens if a product price changes? You don't want your past purchases/invoice prices to change, right?
You'll need to store your sessions (or the completed ones at least) forever (depending on your country's legal requirements for document storage for commercial transactions), since they're a legal record. Similarly, you can't just delete old Product records, you need to mark them obsolete so they don't show up as available for purchasing but do show up in historical purchase records (otherwise your app will show for old items that someone purchased 5 of product ID 119 and 2 of product ID 135 and you don't know what the hell they actually bought...).

That's all I can think of right now, but that should be enough to get you started.


A simple Query causing high CPU in SQL Server 2008

Based on your schema it looks like trans_seq can't be null so I would remove the isnull from the select as that would have a small amount of CPU overhead in just checking the value that is returned from the max function.

SELECT max(trans_seq) +1
FROM inv_inventory_journal
WHERE organization_id = @P0
AND wkstn_id = '600'

Also if your query is always setting the wkstn_id to a constant 600. You could create a filtered index on that column.

USE [LKY_Xcenter]
GO
CREATE NONCLUSTERED INDEX [<Name of Missing Index, sysname,>]
ON [dbo].[inv_inventory_journal] ([organization_id],[wkstn_id])
INCLUDE ([trans_seq])
WHERE [trans_seq] = 600;
GO

The nice thing about filtered indexes is that from an IO standpoint they only contain the rows that satisfies the where statement defined in the index so you could get better performance from them.

One thing of note with the filtered indexes is that in order for the query optimizer to use them the value in the where clause must be a constant in the query.

Here is a couple of references to using filtered indexes:
MSDN

Brent Ozar


I don't know why I didn't try this earlier, but a simple reboot resolved this issue. Note, that the simple restart of xampp and thus of mysql and apache did not work.


How to set up last access (timestamptz) in table 1( basic info table) when working with many other tables having foreign key from table 1?

I have two solutions:

Create a lastAccess column on all 5 of the tables. Create database triggers on each table to update it's corresponding lastAccess column. This will allow you to track when each table is updated.
Create lastAccess on Table 1. Then create triggers on tables 2,3,4,5 that will update the lastAccess column on Table 1.


You don't actually have to dump to upgrade a PostgreSQL instance. For example, you can bring up a new cluster with access to an older cluster using the pg_upgrade command. If you're using XFS you can even use --clone. I would read the rest of the docs for pg_upgrade.

If you're just looking to move the instance you can try pg_basebackup - though I'm not sure that works across major versions.


Is there a way to connect a Postgres 9 database client to a Postgres 8 system?

Via PostgreSQL FDW you can connect to any other PostgreSQL (as well as other databases), regardless of the version of the location (remote, local, or same) or version (older, same, or newer) of that other PostgreSQL.


Select Mysql Table based on other table field value

The only way to "dynamically" use a tablename is via a Stored Routine in which you do CONCAT(...) to build the SQL, plus PREPARE and EXECUTE to then perform the constructed SQL.

Needing to do this is usually a sign of poor schema design.  Please explain the schema and why you went that direction; we may be able to help 'fix' it.


mysql, select and sorting by group key + with first row that has that key in another column

It was fairly brutal to figure out this answer, but i think a left outer join on the same table matching group to unit column worked. I also had to deal with group column being possibly empty or null.

SELECT
a.id,
a.unit,
a.`group`,
a.col2,
a.col3,
a.col4,
a.col5
FROM tablename AS a
LEFT OUTER JOIN tablename AS b
  ON nullif(a.`group`, '') <=> a.unit
ORDER BY COALESCE(b.unit, a.unit);


SQL Relationship between Subtree Cost and Performance Time

The subtree cost represents the estimated cost of a plan. It can be useful when investigating why the query optimizer chose one plan over another. For example, you might see a plan with a hash join and think that a loop join would have been a more efficient choice. Adding a query hint to force a loop join and comparing subtree costs can be helpful in determining why SQL Server chose a hash join.

The estimated cost of the plan will often not match the "performance time" of a query for many reasons, including hardware differences, blocking by other processes, overall server workload, model limitations, and assumptions based on imperfect information. In addition, a subtree cost of 0.1 versus 0.2 is really not a meaningful difference at all. If you have a query that has a low relative cost to the rest of your workload but that query runs for a long time that's a hint that the query optimizer is making an incorrect assumption or deduction. The root cause of those types of issues often comes down to cardinality estimates. On the other hand, sometimes a relatively expensive query will run for a long time. Looking at the parts of the plan estimated to take a long time can provide useful clues as to why the query is running for a long time. However, some query tuners will tell you to not look at estimated costs at all.

Below are a few example queries just to show that it's possible to have an extreme difference between the estimated cost and the run time. I'm testing on SQL Server 2017, but it's possible to come up with similar demos in all versions. First I put 100k sequential integers into a heap:

CREATE TABLE dbo.OptimizerUnits (ID BIGINT NOT NULL);

INSERT INTO dbo.OptimizerUnits WITH (TABLOCK)
SELECT TOP (100000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
FROM master..spt_values t1
CROSS JOIN master..spt_values t2
OPTION (MAXDOP 1);

Consider the following query:

SELECT ID
FROM dbo.OptimizerUnits
WHERE
(ID % 10) % 101  = 10

A human can look at that query and deduce that it won't return any rows, but the optimizer currently doesn't have that kind of logic built-in. It instead guesses that about 990 rows will be returned. That gives the following query a total estimated cost of 79590.1 units:

WITH OptimizerUnitsCTE (ID) AS
(
    SELECT ID
    FROM dbo.OptimizerUnits
    WHERE
    (ID % 10) % 101  = 10
)
SELECT TOP (100) t1.ID, t2.ID, t3.ID
FROM OptimizerUnitsCTE t1
CROSS JOIN OptimizerUnitsCTE t2
CROSS JOIN OptimizerUnitsCTE t3
ORDER BY t1.ID + t2.ID + t3.ID DESC;

However, the query runs in under 50 ms on my machine.

Now let's go in the other direction. Consider the following query:

SELECT ID
FROM dbo.OptimizerUnits
WHERE
(ID % 10) % 101  = 1
AND (ID % 10) % 102  = 1
AND (ID % 10) % 103  = 1
AND (ID % 10) % 104  = 1

Once again, a human could deduce that the above query will return exactly 10000 rows. The query optimizer does not know that and it guesses that the query will return just 16.7439 rows. This results in an estimated cost of 1.45306 optimizer units for the following query:

WITH OptimizerUnitsCTE (ID) AS
(
    SELECT ID
    FROM dbo.OptimizerUnits
    WHERE
    (ID % 10) % 101  = 1
    AND (ID % 10) % 102  = 1
    AND (ID % 10) % 103  = 1
    AND (ID % 10) % 104  = 1
)
SELECT TOP (100) t1.ID, t2.ID, t3.ID
FROM OptimizerUnitsCTE t1
CROSS JOIN OptimizerUnitsCTE t2
CROSS JOIN OptimizerUnitsCTE t3
ORDER BY t1.ID + t2.ID + t3.ID DESC;

I ran the query for a while on my machine and estimate that it would take around 4.5 days to complete.

In summary, poor cardinality estimates made a query with a cost of 79590.1 units take under a second and a query with a cost of 1.45306 units take about 4.5 days.


I assume SQL Server because of the getdate(). It would be something similar to

CREATE TRIGGER Management.PaymentsCreditCard
               ON Management.Payments
               AFTER INSERT,
                     UPDATE
BEGIN
  UPDATE Management.Payments
         SET CreditCardDetails = NULL
         FROM inserted
              INNER JOIN Management.PaymentMethods
                         ON PaymentMethods.PaymentMethodID = inserted.PaymentMethodID
         WHERE Payments.PaymentID = inserted.PaymentID
               AND PaymentMethods.Description = 'credit card';
END;

. (Just to give you the idea. I haven't tested it, it might need some adaption.)


How do you know it's the full text search that's slow? It is very likely that the slow down is caused more by AND pays='USA' You do not have an index on it and with 5 million records 10 seconds seems fair enough.

Create an index on the pays field. This will speed things up provided that the pays field has good  cardinality.


Creating Temporal table without adding DateTime columns

If you're using System-Versioned Temporal Tables then I believe you need not change your table schema. Rather separate tables are created to automatically manage history on your existing tables.
There's also alternatives in SQL Server that shouldn't require you to change your existing table schema either such as Change Tracking or Change Data Capture (CDC).


PostgreSQL: Issue with a corrupted GiST index on ll_to_earth

Looks like a bug in either the GiST index implementation, the ll_to_earth() function (or maybe the specific operator / operator class). You have pretty much ruled out plain index corruption by trying REINDEX.

First try to upgrade to a current version of Postgres and see if this fixes your problem. 9.5 is getting old (and the current point release is 9.5.15). I did not find any specific entries concerning your case in the release notes since 9.5.10 - on a quick glance! At least upgrade to latest point release, currently 9.5.15 - as is the recommendation of the project. Or to the latest version Postgres 11.1 if that's an option, and see if the problem goes away. (Or recreate your db in pg 11 just to test.)

Both extensions cube and earthdistance have been updated, too. Check curent versions for your installation with:

SELECT * FROM pg_available_extensions where name IN ('cube', 'earthdistance');

For Postgres 11:

cube    1.4
earthdistance   1.1

To see current versions for any given Postgres version try this fiddle.

If upgrading does not fix the problem please file a bug report.


Database Schema for an address book with different mailing lists

I think you should definitely keep the data normalized as you have it now.  I would go a step further and instead of updating John Smith, add a new record for his phone information and mark the old one as inactive.  Then  you have history as well.

It seems complicated but it's really not, and the DB is optimized for this sort of query.

For your update example, it would be as simple as:

UPDATE dbo.phone
Set PhoneNum = '111-555-1234'
WHERE UserId IN (SELECT UserID FROM dbo.Users WHERE Name='John Smith')


is there a way to find out who was spid228 at a given time in the past?

You can easily extract that information from the default trace:

DECLARE @path nvarchar(4000);

SELECT @path= path
FROM sys.traces
WHERE id = 1;

SELECT TextData, HostName, ApplicationName, LoginName, SPID, StartTime
FROM fn_trace_gettable(@path, DEFAULT)
WHERE TextData LIKE '%xp_cmdshell%';


Does Index Intersection work with Included Columns?

Included columns don't prevent the index being used for any purpose.

The query optimizer will pick the best index (or possibly a table scan) that is the most efficient for the query being compiled.  Keep indexes as small as possible, while still providing the desired functionality.  According to Books Online INCLUDEd columns don't affect the query optimizer's selection of an index based strictly on size, however if any given index has all columns required for a query, either as key columns or included columns, that index will be given priority.

Since the query optimizer is a fairly opaque beast, you most likely need to test the suggested index to see if it is used, and what the resulting impact is for INSERTs, UPDATEs, and DELETEs.


How to convert a Microsoft SQL Server CE file (.sdf) to Postgres 9.6 /pgAdmin 4?

You can use my tools to script data and schema as SQL Server compatible scripts, and if required tweak those to run with Postgress: http://erikej.github.io/SqlCeToolbox/


Migration DB postgresql in windows to Red Hat(linux)

pg_dump will create a file with the queries that are needed to recreate the state of your database. The file will look like a transaction or write ahead log.

pg_dump databasename > dumpfilename

pg_restore then will use this file to recreate your database.
It's also useful to migrate to a newer database version

you could also use

psql newdatabasename < dumpfilename


Using the undocumented features DBCC IND and DBCC PAGE, you can pretty easily tell exactly what SQL Server does with rows that exceed the "maximum" size of 8,060 bytes.

To show how this works, I'll create a simple table in tempdb where the row width is 10,000 bytes, then run DBCC IND to get a list of pages where the data is stored.  We'll then run DBCC PAGE to see the content of those pages.

First, we create the table with a maximum width of 10,000 bytes:

SET NOCOUNT ON;
IF OBJECT_ID(N'dbo.WidthTest', N'U') IS NOT NULL
DROP TABLE dbo.WidthTest;
CREATE TABLE dbo.WidthTest
(
      Col01 varchar(1000) NOT NULL
    , Col02 varchar(1000) NOT NULL
    , Col03 varchar(1000) NOT NULL
    , Col04 varchar(1000) NOT NULL
    , Col05 varchar(1000) NOT NULL
    , Col06 varchar(1000) NOT NULL
    , Col07 varchar(1000) NOT NULL
    , Col08 varchar(1000) NOT NULL
    , Col09 varchar(1000) NOT NULL
    , Col10 varchar(1000) NOT NULL
) ON [PRIMARY];

And populate that with a single row:

INSERT INTO dbo.WidthTest (Col01, Col02, Col03, Col04, Col05, Col06, Col07, Col08, Col09, Col10)
VALUES (
      REPLICATE('A', 1000)
    , REPLICATE('B', 1000)
    , REPLICATE('C', 1000)
    , REPLICATE('D', 1000)
    , REPLICATE('E', 1000)
    , REPLICATE('F', 1000)
    , REPLICATE('G', 1000)
    , REPLICATE('H', 1000)
    , REPLICATE('I', 1000)
    , REPLICATE('J', 1000)
    );

Here we're creating a table to hold the DBCC IND output, and populating that table:

DECLARE @fileID int;
DECLARE @pageID int;
DECLARE @slotID int
DECLARE @cmd nvarchar(max);

IF OBJECT_ID(N'dbo.IndexDetails', N'U') IS NOT NULL
DROP TABLE dbo.IndexDetails;
CREATE TABLE dbo.IndexDetails
(
      PageFID int NULL
    , PagePID int NULL
    , IAMFID int NULL
    , IAMPID int NULL
    , ObjectID int NULL
    , IndexID int NULL
    , PartitionNumber int NULL
    , PartitionID bigint NULL
    , iam_chain_type varchar(100) NULL
    , PageType int NULL
    , IndexLevel int NULL
    , NextPageFID int NULL
    , NextPagePID int NULL
    , PrevPageFID int NULL
    , PrevPagePID int NULL
) ON [PRIMARY];

SET @cmd = 'DBCC IND (''tempdb'', ''dbo.WidthTest'', 1);';
INSERT INTO dbo.IndexDetails
(
      PageFID
    , PagePID
    , IAMFID
    , IAMPID
    , ObjectID
    , IndexID
    , PartitionNumber
    , PartitionID
    , iam_chain_type
    , PageType
    , IndexLevel
    , NextPageFID
    , NextPagePID
    , PrevPageFID
    , PrevPagePID
)
EXEC sys.sp_executesql @cmd;

Finally this cursor iterates over the contents of the dbo.IndexDetails table showing the page contents for each page used by the table:

DBCC TRACEON (3604); /* send DBCC PAGE output to the client (messages tab) */
DECLARE cur CURSOR LOCAL FORWARD_ONLY STATIC
FOR
SELECT PageFID, PagePID
FROM dbo.IndexDetails id
WHERE id.PageType IN (1, 3, 4) /* data pages, and text pages */;
OPEN cur;
FETCH NEXT FROM cur INTO @fileID, @pageID;
WHILE @@FETCH_STATUS = 0
BEGIN
    DBCC PAGE (tempdb, @fileID, @pageID, 1)
    FETCH NEXT FROM cur INTO @fileID, @pageID;
END
CLOSE cur;
DEALLOCATE cur;
DBCC TRACEOFF (3604); /* send DBCC PAGE output to the error log (default) */

The interesting bits of output from the cursor are displayed on the Messages tab in SSMS.

This is the first page.  Notice the Record Type = PRIMARY_RECORD:

PAGE: (1:319464)

BUFFER:

BUF @0x0000000203A1C0C0

bpage = 0x000000017018E000          bhash = 0x0000000000000000          bpageno = (1:319464)
bdbid = 2                           breferences = 0                     bcputicks = 0
bsampleCount = 0                    bUse1 = 950                         bstat = 0x10b
blog = 0x212121cc                   bnext = 0x0000000000000000

PAGE HEADER:

Page @0x000000017018E000

m_pageId = (1:319464)               m_headerVersion = 1                 m_type = 1
m_typeFlagBits = 0x0                m_level = 0                         m_flagBits = 0x8000
m_objId (AllocUnitId.idObj) = 178209m_indexId (AllocUnitId.idInd) = 7680
Metadata: AllocUnitId = 2161727832816943104
Metadata: PartitionId = 1152921515708121088                              Metadata: IndexId = 0
Metadata: ObjectId = 1013578649     m_prevPage = (0:0)                  m_nextPage = (0:0)
pminlen = 4                         m_slotCnt = 1                       m_freeCnt = 992
m_freeData = 7198                   m_reservedCnt = 0                   m_lsn = (60:220956:448)
m_xactReserved = 0                  m_xdesId = (0:0)                    m_ghostRecCnt = 0
m_tornBits = 0                      DB Frag ID = 1

Allocation Status

GAM (1:2) = ALLOCATED               SGAM (1:3) = NOT ALLOCATED
PFS (1:315432) = 0x43 ALLOCATED  95_PCT_FULL                             DIFF (1:6) = NOT CHANGED
ML (1:7) = NOT MIN_LOGGED

DATA:

Slot 0, Offset 0x60, Length 7102, DumpStyle BYTE

Record Type = PRIMARY_RECORD        Record Attributes =  NULL_BITMAP VARIABLE_COLUMNS
Record Size = 7102
Memory Dump @0x000000000DBAA060

0000000000000000:  0......ü..6.N.f.N.6.
0000000000000014:  ....î.Ö.¾..........>
0000000000000028:  ..è...àß............
000000000000003C:  ..I...è...àß........
0000000000000050:  ......2_..è...àß....
0000000000000064:  ..DDDDDDDDDDDDDDDDDD
0000000000000078:  DDDDDDDDDDDDDDDDDDDD
000000000000008C:  DDDDDDDDDDDDDDDDDDDD
00000000000000A0:  DDDDDDDDDDDDDDDDDDDD
00000000000000B4:  DDDDDDDDDDDDDDDDDDDD
00000000000000C8:  DDDDDDDDDDDDDDDDDDDD
00000000000000DC:  DDDDDDDDDDDDDDDDDDDD
00000000000000F0:  DDDDDDDDDDDDDDDDDDDD
0000000000000104:  DDDDDDDDDDDDDDDDDDDD
0000000000000118:  DDDDDDDDDDDDDDDDDDDD
000000000000012C:  DDDDDDDDDDDDDDDDDDDD
0000000000000140:  DDDDDDDDDDDDDDDDDDDD
0000000000000154:  DDDDDDDDDDDDDDDDDDDD
0000000000000168:  DDDDDDDDDDDDDDDDDDDD
000000000000017C:  DDDDDDDDDDDDDDDDDDDD
0000000000000190:  DDDDDDDDDDDDDDDDDDDD
00000000000001A4:  DDDDDDDDDDDDDDDDDDDD
00000000000001B8:  DDDDDDDDDDDDDDDDDDDD
00000000000001CC:  DDDDDDDDDDDDDDDDDDDD
00000000000001E0:  DDDDDDDDDDDDDDDDDDDD
00000000000001F4:  DDDDDDDDDDDDDDDDDDDD
0000000000000208:  DDDDDDDDDDDDDDDDDDDD
000000000000021C:  DDDDDDDDDDDDDDDDDDDD
0000000000000230:  DDDDDDDDDDDDDDDDDDDD
0000000000000244:  DDDDDDDDDDDDDDDDDDDD
0000000000000258:  DDDDDDDDDDDDDDDDDDDD
000000000000026C:  DDDDDDDDDDDDDDDDDDDD
0000000000000280:  DDDDDDDDDDDDDDDDDDDD
0000000000000294:  DDDDDDDDDDDDDDDDDDDD
00000000000002A8:  DDDDDDDDDDDDDDDDDDDD
00000000000002BC:  DDDDDDDDDDDDDDDDDDDD
00000000000002D0:  DDDDDDDDDDDDDDDDDDDD
00000000000002E4:  DDDDDDDDDDDDDDDDDDDD
00000000000002F8:  DDDDDDDDDDDDDDDDDDDD
000000000000030C:  DDDDDDDDDDDDDDDDDDDD
0000000000000320:  DDDDDDDDDDDDDDDDDDDD
0000000000000334:  DDDDDDDDDDDDDDDDDDDD
0000000000000348:  DDDDDDDDDDDDDDDDDDDD
000000000000035C:  DDDDDDDDDDDDDDDDDDDD
0000000000000370:  DDDDDDDDDDDDDDDDDDDD
0000000000000384:  DDDDDDDDDDDDDDDDDDDD
0000000000000398:  DDDDDDDDDDDDDDDDDDDD
00000000000003AC:  DDDDDDDDDDDDDDDDDDDD
00000000000003C0:  DDDDDDDDDDDDDDDDDDDD
00000000000003D4:  DDDDDDDDDDDDDDDDDDDD
00000000000003E8:  DDDDDDDDDDDDDDDDDDDD
00000000000003FC:  DDDDDDDDDDDDDDDDDDDD
0000000000000410:  DDDDDDDDDDDDDDDDDDDD
0000000000000424:  DDDDDDDDDDDDDDDDDDDD
0000000000000438:  DDDDDDDDDDDDDDDDDDDD
000000000000044C:  DDEEEEEEEEEEEEEEEEEE
0000000000000460:  EEEEEEEEEEEEEEEEEEEE
0000000000000474:  EEEEEEEEEEEEEEEEEEEE
0000000000000488:  EEEEEEEEEEEEEEEEEEEE
000000000000049C:  EEEEEEEEEEEEEEEEEEEE
00000000000004B0:  EEEEEEEEEEEEEEEEEEEE
00000000000004C4:  EEEEEEEEEEEEEEEEEEEE
00000000000004D8:  EEEEEEEEEEEEEEEEEEEE
00000000000004EC:  EEEEEEEEEEEEEEEEEEEE
0000000000000500:  EEEEEEEEEEEEEEEEEEEE
0000000000000514:  EEEEEEEEEEEEEEEEEEEE
0000000000000528:  EEEEEEEEEEEEEEEEEEEE
000000000000053C:  EEEEEEEEEEEEEEEEEEEE
0000000000000550:  EEEEEEEEEEEEEEEEEEEE
0000000000000564:  EEEEEEEEEEEEEEEEEEEE
0000000000000578:  EEEEEEEEEEEEEEEEEEEE
000000000000058C:  EEEEEEEEEEEEEEEEEEEE
00000000000005A0:  EEEEEEEEEEEEEEEEEEEE
00000000000005B4:  EEEEEEEEEEEEEEEEEEEE
00000000000005C8:  EEEEEEEEEEEEEEEEEEEE
00000000000005DC:  EEEEEEEEEEEEEEEEEEEE
00000000000005F0:  EEEEEEEEEEEEEEEEEEEE
0000000000000604:  EEEEEEEEEEEEEEEEEEEE
0000000000000618:  EEEEEEEEEEEEEEEEEEEE
000000000000062C:  EEEEEEEEEEEEEEEEEEEE
0000000000000640:  EEEEEEEEEEEEEEEEEEEE
0000000000000654:  EEEEEEEEEEEEEEEEEEEE
0000000000000668:  EEEEEEEEEEEEEEEEEEEE
000000000000067C:  EEEEEEEEEEEEEEEEEEEE
0000000000000690:  EEEEEEEEEEEEEEEEEEEE
00000000000006A4:  EEEEEEEEEEEEEEEEEEEE
00000000000006B8:  EEEEEEEEEEEEEEEEEEEE
00000000000006CC:  EEEEEEEEEEEEEEEEEEEE
00000000000006E0:  EEEEEEEEEEEEEEEEEEEE
00000000000006F4:  EEEEEEEEEEEEEEEEEEEE
0000000000000708:  EEEEEEEEEEEEEEEEEEEE
000000000000071C:  EEEEEEEEEEEEEEEEEEEE
0000000000000730:  EEEEEEEEEEEEEEEEEEEE
0000000000000744:  EEEEEEEEEEEEEEEEEEEE
0000000000000758:  EEEEEEEEEEEEEEEEEEEE
000000000000076C:  EEEEEEEEEEEEEEEEEEEE
0000000000000780:  EEEEEEEEEEEEEEEEEEEE
0000000000000794:  EEEEEEEEEEEEEEEEEEEE
00000000000007A8:  EEEEEEEEEEEEEEEEEEEE
00000000000007BC:  EEEEEEEEEEEEEEEEEEEE
00000000000007D0:  EEEEEEEEEEEEEEEEEEEE
00000000000007E4:  EEEEEEEEEEEEEEEEEEEE
00000000000007F8:  EEEEEEEEEEEEEEEEEEEE
000000000000080C:  EEEEEEEEEEEEEEEEEEEE
0000000000000820:  EEEEEEEEEEEEEEEEEEEE
0000000000000834:  EEFFFFFFFFFFFFFFFFFF
0000000000000848:  FFFFFFFFFFFFFFFFFFFF
000000000000085C:  FFFFFFFFFFFFFFFFFFFF
0000000000000870:  FFFFFFFFFFFFFFFFFFFF
0000000000000884:  FFFFFFFFFFFFFFFFFFFF
0000000000000898:  FFFFFFFFFFFFFFFFFFFF
00000000000008AC:  FFFFFFFFFFFFFFFFFFFF
00000000000008C0:  FFFFFFFFFFFFFFFFFFFF
00000000000008D4:  FFFFFFFFFFFFFFFFFFFF
00000000000008E8:  FFFFFFFFFFFFFFFFFFFF
00000000000008FC:  FFFFFFFFFFFFFFFFFFFF
0000000000000910:  FFFFFFFFFFFFFFFFFFFF
0000000000000924:  FFFFFFFFFFFFFFFFFFFF
0000000000000938:  FFFFFFFFFFFFFFFFFFFF
000000000000094C:  FFFFFFFFFFFFFFFFFFFF
0000000000000960:  FFFFFFFFFFFFFFFFFFFF
0000000000000974:  FFFFFFFFFFFFFFFFFFFF
0000000000000988:  FFFFFFFFFFFFFFFFFFFF
000000000000099C:  FFFFFFFFFFFFFFFFFFFF
00000000000009B0:  FFFFFFFFFFFFFFFFFFFF
00000000000009C4:  FFFFFFFFFFFFFFFFFFFF
00000000000009D8:  FFFFFFFFFFFFFFFFFFFF
00000000000009EC:  FFFFFFFFFFFFFFFFFFFF
0000000000000A00:  FFFFFFFFFFFFFFFFFFFF
0000000000000A14:  FFFFFFFFFFFFFFFFFFFF
0000000000000A28:  FFFFFFFFFFFFFFFFFFFF
0000000000000A3C:  FFFFFFFFFFFFFFFFFFFF
0000000000000A50:  FFFFFFFFFFFFFFFFFFFF
0000000000000A64:  FFFFFFFFFFFFFFFFFFFF
0000000000000A78:  FFFFFFFFFFFFFFFFFFFF
0000000000000A8C:  FFFFFFFFFFFFFFFFFFFF
0000000000000AA0:  FFFFFFFFFFFFFFFFFFFF
0000000000000AB4:  FFFFFFFFFFFFFFFFFFFF
0000000000000AC8:  FFFFFFFFFFFFFFFFFFFF
0000000000000ADC:  FFFFFFFFFFFFFFFFFFFF
0000000000000AF0:  FFFFFFFFFFFFFFFFFFFF
0000000000000B04:  FFFFFFFFFFFFFFFFFFFF
0000000000000B18:  FFFFFFFFFFFFFFFFFFFF
0000000000000B2C:  FFFFFFFFFFFFFFFFFFFF
0000000000000B40:  FFFFFFFFFFFFFFFFFFFF
0000000000000B54:  FFFFFFFFFFFFFFFFFFFF
0000000000000B68:  FFFFFFFFFFFFFFFFFFFF
0000000000000B7C:  FFFFFFFFFFFFFFFFFFFF
0000000000000B90:  FFFFFFFFFFFFFFFFFFFF
0000000000000BA4:  FFFFFFFFFFFFFFFFFFFF
0000000000000BB8:  FFFFFFFFFFFFFFFFFFFF
0000000000000BCC:  FFFFFFFFFFFFFFFFFFFF
0000000000000BE0:  FFFFFFFFFFFFFFFFFFFF
0000000000000BF4:  FFFFFFFFFFFFFFFFFFFF
0000000000000C08:  FFFFFFFFFFFFFFFFFFFF
0000000000000C1C:  FFGGGGGGGGGGGGGGGGGG
0000000000000C30:  GGGGGGGGGGGGGGGGGGGG
0000000000000C44:  GGGGGGGGGGGGGGGGGGGG
0000000000000C58:  GGGGGGGGGGGGGGGGGGGG
0000000000000C6C:  GGGGGGGGGGGGGGGGGGGG
0000000000000C80:  GGGGGGGGGGGGGGGGGGGG
0000000000000C94:  GGGGGGGGGGGGGGGGGGGG
0000000000000CA8:  GGGGGGGGGGGGGGGGGGGG
0000000000000CBC:  GGGGGGGGGGGGGGGGGGGG
0000000000000CD0:  GGGGGGGGGGGGGGGGGGGG
0000000000000E38:  GGGGGGGGGGGGGGGGGGGG
0000000000000E4C:  GGGGGGGGGGGGGGGGGGGG
0000000000000E60:  GGGGGGGGGGGGGGGGGGGG
0000000000000E74:  GGGGGGGGGGGGGGGGGGGG
0000000000000E88:  GGGGGGGGGGGGGGGGGGGG
0000000000000E9C:  GGGGGGGGGGGGGGGGGGGG
0000000000000EB0:  GGGGGGGGGGGGGGGGGGGG
0000000000000EC4:  GGGGGGGGGGGGGGGGGGGG
0000000000000ED8:  GGGGGGGGGGGGGGGGGGGG
0000000000000EEC:  GGGGGGGGGGGGGGGGGGGG
0000000000000F00:  GGGGGGGGGGGGGGGGGGGG
0000000000000F78:  GGGGGGGGGGGGGGGGGGGG
0000000000000F8C:  GGGGGGGGGGGGGGGGGGGG
0000000000000FA0:  GGGGGGGGGGGGGGGGGGGG
0000000000000FB4:  GGGGGGGGGGGGGGGGGGGG
0000000000000FC8:  GGGGGGGGGGGGGGGGGGGG
0000000000000FDC:  GGGGGGGGGGGGGGGGGGGG
0000000000000FF0:  GGGGGGGGGGGGGGGGGGGG
0000000000001004:  GGHHHHHHHHHHHHHHHHHH
0000000000001018:  HHHHHHHHHHHHHHHHHHHH
000000000000102C:  HHHHHHHHHHHHHHHHHHHH
0000000000001040:  HHHHHHHHHHHHHHHHHHHH
0000000000001054:  HHHHHHHHHHHHHHHHHHHH
0000000000001194:  HHHHHHHHHHHHHHHHHHHH
00000000000011A8:  HHHHHHHHHHHHHHHHHHHH
00000000000011BC:  HHHHHHHHHHHHHHHHHHHH
00000000000011D0:  HHHHHHHHHHHHHHHHHHHH
00000000000011E4:  HHHHHHHHHHHHHHHHHHHH
00000000000011F8:  HHHHHHHHHHHHHHHHHHHH
000000000000120C:  HHHHHHHHHHHHHHHHHHHH
0000000000001220:  HHHHHHHHHHHHHHHHHHHH
0000000000001234:  HHHHHHHHHHHHHHHHHHHH
0000000000001248:  HHHHHHHHHHHHHHHHHHHH
000000000000125C:  HHHHHHHHHHHHHHHHHHHH
0000000000001270:  HHHHHHHHHHHHHHHHHHHH
0000000000001284:  HHHHHHHHHHHHHHHHHHHH
0000000000001298:  HHHHHHHHHHHHHHHHHHHH
00000000000012AC:  HHHHHHHHHHHHHHHHHHHH
00000000000012C0:  HHHHHHHHHHHHHHHHHHHH
00000000000012D4:  HHHHHHHHHHHHHHHHHHHH
00000000000012E8:  HHHHHHHHHHHHHHHHHHHH
00000000000012FC:  HHHHHHHHHHHHHHHHHHHH
0000000000001310:  HHHHHHHHHHHHHHHHHHHH
0000000000001324:  HHHHHHHHHHHHHHHHHHHH
0000000000001338:  HHHHHHHHHHHHHHHHHHHH
000000000000134C:  HHHHHHHHHHHHHHHHHHHH
0000000000001360:  HHHHHHHHHHHHHHHHHHHH
0000000000001374:  HHHHHHHHHHHHHHHHHHHH
0000000000001388:  HHHHHHHHHHHHHHHHHHHH
000000000000139C:  HHHHHHHHHHHHHHHHHHHH
00000000000013B0:  HHHHHHHHHHHHHHHHHHHH
00000000000013C4:  HHHHHHHHHHHHHHHHHHHH
00000000000013D8:  HHHHHHHHHHHHHHHHHHHH
00000000000013EC:  HHIIIIIIIIIIIIIIIIII
0000000000001400:  IIIIIIIIIIIIIIIIIIII
0000000000001414:  IIIIIIIIIIIIIIIIIIII
0000000000001428:  IIIIIIIIIIIIIIIIIIII
000000000000143C:  IIIIIIIIIIIIIIIIIIII
0000000000001450:  IIIIIIIIIIIIIIIIIIII
0000000000001464:  IIIIIIIIIIIIIIIIIIII
0000000000001478:  IIIIIIIIIIIIIIIIIIII
000000000000148C:  IIIIIIIIIIIIIIIIIIII
00000000000014A0:  IIIIIIIIIIIIIIIIIIII
00000000000014B4:  IIIIIIIIIIIIIIIIIIII
00000000000014C8:  IIIIIIIIIIIIIIIIIIII
00000000000014DC:  IIIIIIIIIIIIIIIIIIII
00000000000014F0:  IIIIIIIIIIIIIIIIIIII
0000000000001504:  IIIIIIIIIIIIIIIIIIII
0000000000001518:  IIIIIIIIIIIIIIIIIIII
000000000000152C:  IIIIIIIIIIIIIIIIIIII
0000000000001540:  IIIIIIIIIIIIIIIIIIII
0000000000001554:  IIIIIIIIIIIIIIIIIIII
0000000000001568:  IIIIIIIIIIIIIIIIIIII
000000000000157C:  IIIIIIIIIIIIIIIIIIII
0000000000001590:  IIIIIIIIIIIIIIIIIIII
00000000000015A4:  IIIIIIIIIIIIIIIIIIII
00000000000015B8:  IIIIIIIIIIIIIIIIIIII
00000000000015CC:  IIIIIIIIIIIIIIIIIIII
00000000000015E0:  IIIIIIIIIIIIIIIIIIII
00000000000015F4:  IIIIIIIIIIIIIIIIIIII
0000000000001608:  IIIIIIIIIIIIIIIIIIII
000000000000161C:  IIIIIIIIIIIIIIIIIIII
0000000000001630:  IIIIIIIIIIIIIIIIIIII
0000000000001644:  IIIIIIIIIIIIIIIIIIII
0000000000001658:  IIIIIIIIIIIIIIIIIIII
000000000000166C:  IIIIIIIIIIIIIIIIIIII
0000000000001680:  IIIIIIIIIIIIIIIIIIII
0000000000001694:  IIIIIIIIIIIIIIIIIIII
00000000000016A8:  IIIIIIIIIIIIIIIIIIII
00000000000016BC:  IIIIIIIIIIIIIIIIIIII
00000000000016D0:  IIIIIIIIIIIIIIIIIIII
00000000000016E4:  IIIIIIIIIIIIIIIIIIII
00000000000016F8:  IIIIIIIIIIIIIIIIIIII
000000000000170C:  IIIIIIIIIIIIIIIIIIII
0000000000001720:  IIIIIIIIIIIIIIIIIIII
0000000000001734:  IIIIIIIIIIIIIIIIIIII
0000000000001748:  IIIIIIIIIIIIIIIIIIII
000000000000175C:  IIIIIIIIIIIIIIIIIIII
0000000000001770:  IIIIIIIIIIIIIIIIIIII
0000000000001784:  IIIIIIIIIIIIIIIIIIII
0000000000001798:  IIIIIIIIIIIIIIIIIIII
00000000000017AC:  IIIIIIIIIIIIIIIIIIII
00000000000017C0:  IIIIIIIIIIIIIIIIIIII
00000000000017D4:  IIJJJJJJJJJJJJJJJJJJ
00000000000017E8:  JJJJJJJJJJJJJJJJJJJJ
00000000000017FC:  JJJJJJJJJJJJJJJJJJJJ
0000000000001810:  JJJJJJJJJJJJJJJJJJJJ
0000000000001824:  JJJJJJJJJJJJJJJJJJJJ
0000000000001838:  JJJJJJJJJJJJJJJJJJJJ
000000000000184C:  JJJJJJJJJJJJJJJJJJJJ
0000000000001860:  JJJJJJJJJJJJJJJJJJJJ
0000000000001874:  JJJJJJJJJJJJJJJJJJJJ
0000000000001888:  JJJJJJJJJJJJJJJJJJJJ
000000000000189C:  JJJJJJJJJJJJJJJJJJJJ
00000000000018B0:  JJJJJJJJJJJJJJJJJJJJ
00000000000018C4:  JJJJJJJJJJJJJJJJJJJJ
00000000000018D8:  JJJJJJJJJJJJJJJJJJJJ
00000000000018EC:  JJJJJJJJJJJJJJJJJJJJ
0000000000001900:  JJJJJJJJJJJJJJJJJJJJ
0000000000001914:  JJJJJJJJJJJJJJJJJJJJ
0000000000001928:  JJJJJJJJJJJJJJJJJJJJ
000000000000193C:  JJJJJJJJJJJJJJJJJJJJ
0000000000001950:  JJJJJJJJJJJJJJJJJJJJ
0000000000001964:  JJJJJJJJJJJJJJJJJJJJ
0000000000001978:  JJJJJJJJJJJJJJJJJJJJ
000000000000198C:  JJJJJJJJJJJJJJJJJJJJ
00000000000019A0:  JJJJJJJJJJJJJJJJJJJJ
00000000000019B4:  JJJJJJJJJJJJJJJJJJJJ
00000000000019C8:  JJJJJJJJJJJJJJJJJJJJ
00000000000019DC:  JJJJJJJJJJJJJJJJJJJJ
00000000000019F0:  JJJJJJJJJJJJJJJJJJJJ
0000000000001A04:  JJJJJJJJJJJJJJJJJJJJ
0000000000001A18:  JJJJJJJJJJJJJJJJJJJJ
0000000000001A2C:  JJJJJJJJJJJJJJJJJJJJ
0000000000001A40:  JJJJJJJJJJJJJJJJJJJJ
0000000000001A54:  JJJJJJJJJJJJJJJJJJJJ
0000000000001A68:  JJJJJJJJJJJJJJJJJJJJ
0000000000001A7C:  JJJJJJJJJJJJJJJJJJJJ
0000000000001A90:  JJJJJJJJJJJJJJJJJJJJ
0000000000001AA4:  JJJJJJJJJJJJJJJJJJJJ
0000000000001AB8:  JJJJJJJJJJJJJJJJJJJJ
0000000000001ACC:  JJJJJJJJJJJJJJJJJJJJ
0000000000001AE0:  JJJJJJJJJJJJJJJJJJJJ
0000000000001AF4:  JJJJJJJJJJJJJJJJJJJJ
0000000000001B08:  JJJJJJJJJJJJJJJJJJJJ
0000000000001B1C:  JJJJJJJJJJJJJJJJJJJJ
0000000000001B30:  JJJJJJJJJJJJJJJJJJJJ
0000000000001B44:  JJJJJJJJJJJJJJJJJJJJ
0000000000001B58:  JJJJJJJJJJJJJJJJJJJJ
0000000000001B6C:  JJJJJJJJJJJJJJJJJJJJ
0000000000001B80:  JJJJJJJJJJJJJJJJJJJJ
0000000000001B94:  JJJJJJJJJJJJJJJJJJJJ
0000000000001BA8:  JJJJJJJJJJJJJJJJJJJJ
0000000000001BBC:  JJ

OFFSET TABLE:

Row - Offset
0 (0x0) - 96 (0x60)

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

I've removed the hexaxdecimal content of the actual page dump to keep my post under the 30,000 character limit.  As you can see from the page dump above, the primary page in my example does not contain the first 3 columns, A, B, and C - they are stored in the row overflow region, shown next, with Record Type = BLOB_FRAGMENT:

PAGE: (1:319456)

BUFFER:

BUF @0x0000000203A19240

bpage = 0x0000000170186000          bhash = 0x0000000000000000          bpageno = (1:319456)
bdbid = 2                           breferences = 0                     bcputicks = 0
bsampleCount = 0                    bUse1 = 950                         bstat = 0x10b
blog = 0x1212121c                   bnext = 0x0000000000000000

PAGE HEADER:

Page @0x0000000170186000

m_pageId = (1:319456)               m_headerVersion = 1                 m_type = 3
m_typeFlagBits = 0x0                m_level = 0                         m_flagBits = 0x8000
m_objId (AllocUnitId.idObj) = 178834m_indexId (AllocUnitId.idInd) = 7936
Metadata: AllocUnitId = 2233785426895831040
Metadata: PartitionId = 1152921515708121088                              Metadata: IndexId = 0
Metadata: ObjectId = 1013578649     m_prevPage = (0:0)                  m_nextPage = (0:0)
pminlen = 0                         m_slotCnt = 3                       m_freeCnt = 5048
m_freeData = 3166                   m_reservedCnt = 0                   m_lsn = (60:220956:430)
m_xactReserved = 0                  m_xdesId = (0:0)                    m_ghostRecCnt = 0
m_tornBits = 0                      DB Frag ID = 1

Allocation Status

GAM (1:2) = ALLOCATED               SGAM (1:3) = NOT ALLOCATED
PFS (1:315432) = 0x41 ALLOCATED  50_PCT_FULL                             DIFF (1:6) = NOT CHANGED
ML (1:7) = NOT MIN_LOGGED

DATA:

Slot 0, Offset 0x60, Length 1014, DumpStyle BYTE

Record Type = BLOB_FRAGMENT         Record Attributes =                 Record Size = 1014

Memory Dump @0x000000000DBAA060

0000000000000000:  ..ö....>......AAAAAA
0000000000000014:  AAAAAAAAAAAAAAAAAAAA
0000000000000028:  AAAAAAAAAAAAAAAAAAAA
000000000000003C:  AAAAAAAAAAAAAAAAAAAA
0000000000000050:  AAAAAAAAAAAAAAAAAAAA
0000000000000064:  AAAAAAAAAAAAAAAAAAAA
0000000000000078:  AAAAAAAAAAAAAAAAAAAA
000000000000008C:  AAAAAAAAAAAAAAAAAAAA
00000000000000A0:  AAAAAAAAAAAAAAAAAAAA
00000000000000B4:  AAAAAAAAAAAAAAAAAAAA
00000000000000C8:  AAAAAAAAAAAAAAAAAAAA
00000000000000DC:  AAAAAAAAAAAAAAAAAAAA
00000000000000F0:  AAAAAAAAAAAAAAAAAAAA
0000000000000104:  AAAAAAAAAAAAAAAAAAAA
0000000000000118:  AAAAAAAAAAAAAAAAAAAA
000000000000012C:  AAAAAAAAAAAAAAAAAAAA
0000000000000140:  AAAAAAAAAAAAAAAAAAAA
0000000000000154:  AAAAAAAAAAAAAAAAAAAA
0000000000000168:  AAAAAAAAAAAAAAAAAAAA
000000000000017C:  AAAAAAAAAAAAAAAAAAAA
0000000000000190:  AAAAAAAAAAAAAAAAAAAA
00000000000001A4:  AAAAAAAAAAAAAAAAAAAA
00000000000001B8:  AAAAAAAAAAAAAAAAAAAA
00000000000001CC:  AAAAAAAAAAAAAAAAAAAA
00000000000001E0:  AAAAAAAAAAAAAAAAAAAA
00000000000001F4:  AAAAAAAAAAAAAAAAAAAA
0000000000000208:  AAAAAAAAAAAAAAAAAAAA
000000000000021C:  AAAAAAAAAAAAAAAAAAAA
0000000000000230:  AAAAAAAAAAAAAAAAAAAA
0000000000000244:  AAAAAAAAAAAAAAAAAAAA
0000000000000258:  AAAAAAAAAAAAAAAAAAAA
000000000000026C:  AAAAAAAAAAAAAAAAAAAA
0000000000000280:  AAAAAAAAAAAAAAAAAAAA
0000000000000294:  AAAAAAAAAAAAAAAAAAAA
00000000000002A8:  AAAAAAAAAAAAAAAAAAAA
00000000000002BC:  AAAAAAAAAAAAAAAAAAAA
00000000000002D0:  AAAAAAAAAAAAAAAAAAAA
00000000000002E4:  AAAAAAAAAAAAAAAAAAAA
00000000000002F8:  AAAAAAAAAAAAAAAAAAAA
000000000000030C:  AAAAAAAAAAAAAAAAAAAA
0000000000000320:  AAAAAAAAAAAAAAAAAAAA
0000000000000334:  AAAAAAAAAAAAAAAAAAAA
0000000000000348:  AAAAAAAAAAAAAAAAAAAA
000000000000035C:  AAAAAAAAAAAAAAAAAAAA
0000000000000370:  AAAAAAAAAAAAAAAAAAAA
0000000000000384:  AAAAAAAAAAAAAAAAAAAA
0000000000000398:  AAAAAAAAAAAAAAAAAAAA
00000000000003AC:  AAAAAAAAAAAAAAAAAAAA
00000000000003C0:  AAAAAAAAAAAAAAAAAAAA
00000000000003D4:  AAAAAAAAAAAAAAAAAAAA
00000000000003E8:  AAAAAAAAAAAAAA

Slot 1, Offset 0x464, Length 1014, DumpStyle BYTE

Record Type = BLOB_FRAGMENT         Record Attributes =                 Record Size = 1014

Memory Dump @0x000000000DBAA464

0000000000000000:  ..ö...I.......BBBBBB
0000000000000014:  BBBBBBBBBBBBBBBBBBBB
0000000000000028:  BBBBBBBBBBBBBBBBBBBB
000000000000003C:  BBBBBBBBBBBBBBBBBBBB
0000000000000050:  BBBBBBBBBBBBBBBBBBBB
0000000000000064:  BBBBBBBBBBBBBBBBBBBB
0000000000000078:  BBBBBBBBBBBBBBBBBBBB
000000000000008C:  BBBBBBBBBBBBBBBBBBBB
00000000000000A0:  BBBBBBBBBBBBBBBBBBBB
00000000000000B4:  BBBBBBBBBBBBBBBBBBBB
00000000000000C8:  BBBBBBBBBBBBBBBBBBBB
00000000000000DC:  BBBBBBBBBBBBBBBBBBBB
00000000000000F0:  BBBBBBBBBBBBBBBBBBBB
0000000000000104:  BBBBBBBBBBBBBBBBBBBB
0000000000000118:  BBBBBBBBBBBBBBBBBBBB
000000000000012C:  BBBBBBBBBBBBBBBBBBBB
0000000000000140:  BBBBBBBBBBBBBBBBBBBB
0000000000000154:  BBBBBBBBBBBBBBBBBBBB
0000000000000168:  BBBBBBBBBBBBBBBBBBBB
000000000000017C:  BBBBBBBBBBBBBBBBBBBB
0000000000000190:  BBBBBBBBBBBBBBBBBBBB
00000000000001A4:  BBBBBBBBBBBBBBBBBBBB
00000000000001B8:  BBBBBBBBBBBBBBBBBBBB
00000000000001CC:  BBBBBBBBBBBBBBBBBBBB
00000000000001E0:  BBBBBBBBBBBBBBBBBBBB
00000000000001F4:  BBBBBBBBBBBBBBBBBBBB
0000000000000208:  BBBBBBBBBBBBBBBBBBBB
000000000000021C:  BBBBBBBBBBBBBBBBBBBB
0000000000000230:  BBBBBBBBBBBBBBBBBBBB
0000000000000244:  BBBBBBBBBBBBBBBBBBBB
0000000000000258:  BBBBBBBBBBBBBBBBBBBB
000000000000026C:  BBBBBBBBBBBBBBBBBBBB
0000000000000280:  BBBBBBBBBBBBBBBBBBBB
0000000000000294:  BBBBBBBBBBBBBBBBBBBB
00000000000002A8:  BBBBBBBBBBBBBBBBBBBB
00000000000002BC:  BBBBBBBBBBBBBBBBBBBB
00000000000002D0:  BBBBBBBBBBBBBBBBBBBB
00000000000002E4:  BBBBBBBBBBBBBBBBBBBB
00000000000002F8:  BBBBBBBBBBBBBBBBBBBB
000000000000030C:  BBBBBBBBBBBBBBBBBBBB
0000000000000320:  BBBBBBBBBBBBBBBBBBBB
0000000000000334:  BBBBBBBBBBBBBBBBBBBB
0000000000000348:  BBBBBBBBBBBBBBBBBBBB
000000000000035C:  BBBBBBBBBBBBBBBBBBBB
0000000000000370:  BBBBBBBBBBBBBBBBBBBB
0000000000000384:  BBBBBBBBBBBBBBBBBBBB
0000000000000398:  BBBBBBBBBBBBBBBBBBBB
00000000000003AC:  BBBBBBBBBBBBBBBBBBBB
00000000000003C0:  BBBBBBBBBBBBBBBBBBBB
00000000000003D4:  BBBBBBBBBBBBBBBBBBBB
00000000000003E8:  BBBBBBBBBBBBBB

Slot 2, Offset 0x868, Length 1014, DumpStyle BYTE

Record Type = BLOB_FRAGMENT         Record Attributes =                 Record Size = 1014

Memory Dump @0x000000000DBAA868

0000000000000000:   ..ö...2_......CCCCCC
0000000000000014:   CCCCCCCCCCCCCCCCCCCC
0000000000000028:   CCCCCCCCCCCCCCCCCCCC
000000000000003C:   CCCCCCCCCCCCCCCCCCCC
0000000000000050:   CCCCCCCCCCCCCCCCCCCC
0000000000000064:   CCCCCCCCCCCCCCCCCCCC
0000000000000078:   CCCCCCCCCCCCCCCCCCCC
000000000000008C:   CCCCCCCCCCCCCCCCCCCC
00000000000000A0:   CCCCCCCCCCCCCCCCCCCC
00000000000000B4:   CCCCCCCCCCCCCCCCCCCC
00000000000000C8:   CCCCCCCCCCCCCCCCCCCC
00000000000000DC:   CCCCCCCCCCCCCCCCCCCC
00000000000000F0:   CCCCCCCCCCCCCCCCCCCC
0000000000000104:   CCCCCCCCCCCCCCCCCCCC
0000000000000118:   CCCCCCCCCCCCCCCCCCCC
000000000000012C:   CCCCCCCCCCCCCCCCCCCC
0000000000000140:   CCCCCCCCCCCCCCCCCCCC
0000000000000154:   CCCCCCCCCCCCCCCCCCCC
0000000000000168:   CCCCCCCCCCCCCCCCCCCC
000000000000017C:   CCCCCCCCCCCCCCCCCCCC
0000000000000190:   CCCCCCCCCCCCCCCCCCCC
00000000000001A4:   CCCCCCCCCCCCCCCCCCCC
00000000000001B8:   CCCCCCCCCCCCCCCCCCCC
00000000000001CC:   CCCCCCCCCCCCCCCCCCCC
00000000000001E0:   CCCCCCCCCCCCCCCCCCCC
00000000000001F4:   CCCCCCCCCCCCCCCCCCCC
0000000000000208:   CCCCCCCCCCCCCCCCCCCC
000000000000021C:   CCCCCCCCCCCCCCCCCCCC
0000000000000230:   CCCCCCCCCCCCCCCCCCCC
0000000000000244:   CCCCCCCCCCCCCCCCCCCC
0000000000000258:   CCCCCCCCCCCCCCCCCCCC
000000000000026C:   CCCCCCCCCCCCCCCCCCCC
0000000000000280:   CCCCCCCCCCCCCCCCCCCC
0000000000000294:   CCCCCCCCCCCCCCCCCCCC
00000000000002A8:   CCCCCCCCCCCCCCCCCCCC
00000000000002BC:   CCCCCCCCCCCCCCCCCCCC
00000000000002D0:   CCCCCCCCCCCCCCCCCCCC
00000000000002E4:   CCCCCCCCCCCCCCCCCCCC
00000000000002F8:   CCCCCCCCCCCCCCCCCCCC
000000000000030C:   CCCCCCCCCCCCCCCCCCCC
0000000000000320:   CCCCCCCCCCCCCCCCCCCC
0000000000000334:   CCCCCCCCCCCCCCCCCCCC
0000000000000348:   CCCCCCCCCCCCCCCCCCCC
000000000000035C:   CCCCCCCCCCCCCCCCCCCC
0000000000000370:   CCCCCCCCCCCCCCCCCCCC
0000000000000384:   CCCCCCCCCCCCCCCCCCCC
0000000000000398:   CCCCCCCCCCCCCCCCCCCC
00000000000003AC:   CCCCCCCCCCCCCCCCCCCC
00000000000003C0:   CCCCCCCCCCCCCCCCCCCC
00000000000003D4:   CCCCCCCCCCCCCCCCCCCC
00000000000003E8:   CCCCCCCCCCCCCC