¿como evitar los hot blocks?

Hola Gustavo,

Que tal si probamos con codigo.

Sesion 1:

use tempdb
go

DROP TABLE dbo.t1
GO

CREATE TABLE dbo.t1 (
transaccion_id INT NOT NULL IDENTITY PRIMARY KEY,
dt DATETIME NOT NULL DEFAULT(GETDATE()),
contador VARCHAR(25) NOT NULL,
[id] INT NOT NULL,
CONSTRAINT UQ_transaccion_contador_id UNIQUE (contador, id)
)
GO

INSERT INTO dbo.t1 (contador, id) VALUES('contador 1', 1)
GO

Antes de ejecutar esta parte, favor usar un tiempo no lejano en el futuro
para que ambas sesiones ejecuten este codigo al mismo tiempo.

DECLARE @i INT

SET @i = 1

WAITFOR TIME '13:15:00'

SET TRANSACTION ISOLATION LEVEL READ COMMITTED

WHILE @i <= 1000
BEGIN
BEGIN TRANSACTION

INSERT INTO dbo.t1 (
contador,
[id]
)
SELECT 'contador 1', MAX(id) + 1
FROM dbo.t1 AS c
WHERE contador = 'contador 1'

COMMIT TRANSACTION

SET @i = @i + 1
END

SET TRANSACTION ISOLATION LEVEL READ COMMITTED
GO

Session 2

use tempdb
go

DECLARE @i INT

SET @i = 1

WAITFOR TIME '13:15:00'

SET TRANSACTION ISOLATION LEVEL READ COMMITTED

WHILE @i <= 1000
BEGIN
BEGIN TRANSACTION

INSERT INTO dbo.t1 (
contador,
[id]
)
SELECT 'contador 1', MAX(id) + 1
FROM dbo.t1 AS c
WHERE contador = 'contador 1'

COMMIT TRANSACTION

SET @i = @i + 1
END

SET TRANSACTION ISOLATION LEVEL READ COMMITTED
GO

Si creen que el nivel READ COMMITTED no es suficiente, entonces cambienlo en
ambas sessiones y vean los resultados.


AMB

"Gux (MVP)" wrote:

"Alfredo Novoa" wrote:

> wrote:
>
> >Hola Antonio, a mi me parece correcto usar la tabla numeradora y los
> >bloqueos, a la larga es lo mas eficiente que podes hacer y seguro. Si haces
> >un Max sobre la tabla y esta tiene millones de registros no va a ser tan
> >rapido como hacer un update sobre la tabla numeradora de unos pocos
> >registros.
>
> ¿Por que?
>
> Para eso están los índices.

Exacto.

Si hay una consulta que usa funciones agregadas (mi libre traducción de
"aggregate" :-)) considerar el uso de un índice no-clustered. Estos índices
incluyen una fila con el valor de índice para cálculos agregados, por lo que
SQL Server no necesita acceder a la tabla real para hacer el cálculo de la
función.


Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/p...o.larriera
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.



"Alfredo Novoa" wrote:

>
> Hola Maxi,
>
> On Mon, 5 May 2008 10:53:28 -0300, "Maxi"
> wrote:
>
> >Hola Antonio, a mi me parece correcto usar la tabla numeradora y los
> >bloqueos, a la larga es lo mas eficiente que podes hacer y seguro. Si haces
> >un Max sobre la tabla y esta tiene millones de registros no va a ser tan
> >rapido como hacer un update sobre la tabla numeradora de unos pocos
> >registros.
>
> ¿Por que?
>
> Para eso están los índices.
>
> >aplicaciones por el costo a nivel performance que tiene eso, ademas de que
> >estarias haciendo un select y si dos hacen el mismo Max y no consideras
> >otras cosas a nivel bloqueo podria darles el mismo numero)
>
> ¿Que más habría que considerar?
>
>
>
> Saludos
>

Hola Gux,

On Mon, 5 May 2008 08:44:00 -0700, Gux (MVP)
wrote:

Mi comentario era para aportar algo al tema de cómo tener buen rendimiento en
consultas que usan aggregates. No considero el SELECT MAX como la mejor
opción disponible para todos los casos.

Hombre, yo tampoco. Ni creo que nadie.

Pero es una solución bastante práctica y sencilla.


Saludos

Gracias por el código Alejandro. Intentaré probarlo en cuanto esté en una
máquina con SQL instalado.

Seré curioso, antes de probar tu código: El isolation level no debería ser
SERIALIZABLE ?

Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/p...o.larriera
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.



"Alejandro Mesa" wrote:

Hola Gustavo,

Que tal si probamos con codigo.

Sesion 1:

use tempdb
go

DROP TABLE dbo.t1
GO

CREATE TABLE dbo.t1 (
transaccion_id INT NOT NULL IDENTITY PRIMARY KEY,
dt DATETIME NOT NULL DEFAULT(GETDATE()),
contador VARCHAR(25) NOT NULL,
[id] INT NOT NULL,
CONSTRAINT UQ_transaccion_contador_id UNIQUE (contador, id)
)
GO

INSERT INTO dbo.t1 (contador, id) VALUES('contador 1', 1)
GO

Antes de ejecutar esta parte, favor usar un tiempo no lejano en el futuro
para que ambas sesiones ejecuten este codigo al mismo tiempo.

DECLARE @i INT

SET @i = 1

WAITFOR TIME '13:15:00'

SET TRANSACTION ISOLATION LEVEL READ COMMITTED

WHILE @i <= 1000
BEGIN
BEGIN TRANSACTION

INSERT INTO dbo.t1 (
contador,
[id]
)
SELECT 'contador 1', MAX(id) + 1
FROM dbo.t1 AS c
WHERE contador = 'contador 1'

COMMIT TRANSACTION

SET @i = @i + 1
END

SET TRANSACTION ISOLATION LEVEL READ COMMITTED
GO

Session 2

use tempdb
go

DECLARE @i INT

SET @i = 1

WAITFOR TIME '13:15:00'

SET TRANSACTION ISOLATION LEVEL READ COMMITTED

WHILE @i <= 1000
BEGIN
BEGIN TRANSACTION

INSERT INTO dbo.t1 (
contador,
[id]
)
SELECT 'contador 1', MAX(id) + 1
FROM dbo.t1 AS c
WHERE contador = 'contador 1'

COMMIT TRANSACTION

SET @i = @i + 1
END

SET TRANSACTION ISOLATION LEVEL READ COMMITTED
GO

Si creen que el nivel READ COMMITTED no es suficiente, entonces cambienlo en
ambas sessiones y vean los resultados.


AMB

"Gux (MVP)" wrote:

> "Alfredo Novoa" wrote:
>
> > wrote:
> >
> > >Hola Antonio, a mi me parece correcto usar la tabla numeradora y los
> > >bloqueos, a la larga es lo mas eficiente que podes hacer y seguro. Si haces
> > >un Max sobre la tabla y esta tiene millones de registros no va a ser tan
> > >rapido como hacer un update sobre la tabla numeradora de unos pocos
> > >registros.
> >
> > ¿Por que?
> >
> > Para eso están los índices.
>
> Exacto.
>
> Si hay una consulta que usa funciones agregadas (mi libre traducción de
> "aggregate" :-)) considerar el uso de un índice no-clustered. Estos índices
> incluyen una fila con el valor de índice para cálculos agregados, por lo que
> SQL Server no necesita acceder a la tabla real para hacer el cálculo de la
> función.
>
>
> Gustavo Larriera, Microsoft MVP
> https://mvp.support.microsoft.com/p...o.larriera
> Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
>
>
>
> "Alfredo Novoa" wrote:
>
> >
> > Hola Maxi,
> >
> > On Mon, 5 May 2008 10:53:28 -0300, "Maxi"
> > wrote:
> >
> > >Hola Antonio, a mi me parece correcto usar la tabla numeradora y los
> > >bloqueos, a la larga es lo mas eficiente que podes hacer y seguro. Si haces
> > >un Max sobre la tabla y esta tiene millones de registros no va a ser tan
> > >rapido como hacer un update sobre la tabla numeradora de unos pocos
> > >registros.
> >
> > ¿Por que?
> >
> > Para eso están los índices.
> >
> > >aplicaciones por el costo a nivel performance que tiene eso, ademas de que
> > >estarias haciendo un select y si dos hacen el mismo Max y no consideras
> > >otras cosas a nivel bloqueo podria darles el mismo numero)
> >
> > ¿Que más habría que considerar?
> >
> >
> >
> > Saludos
> >

Gux,

Te lo dejo de prueba, veras lo que pasa cuando usas SERIALIZABLE .


AMB

"Gux (MVP)" wrote:

Gracias por el código Alejandro. Intentaré probarlo en cuanto esté en una
máquina con SQL instalado.

Seré curioso, antes de probar tu código: El isolation level no debería ser
SERIALIZABLE ?

Gustavo Larriera, Microsoft MVP
https://mvp.support.microsoft.com/p...o.larriera
Este mensaje se proporciona tal como es, sin garantías de ninguna clase.



"Alejandro Mesa" wrote:

> Hola Gustavo,
>
> Que tal si probamos con codigo.
>
> Sesion 1:
>
> use tempdb
> go
>
> DROP TABLE dbo.t1
> GO
>
> CREATE TABLE dbo.t1 (
> transaccion_id INT NOT NULL IDENTITY PRIMARY KEY,
> dt DATETIME NOT NULL DEFAULT(GETDATE()),
> contador VARCHAR(25) NOT NULL,
> [id] INT NOT NULL,
> CONSTRAINT UQ_transaccion_contador_id UNIQUE (contador, id)
> )
> GO
>
> INSERT INTO dbo.t1 (contador, id) VALUES('contador 1', 1)
> GO
>
> Antes de ejecutar esta parte, favor usar un tiempo no lejano en el futuro
> para que ambas sesiones ejecuten este codigo al mismo tiempo.
>
> DECLARE @i INT
>
> SET @i = 1
>
> WAITFOR TIME '13:15:00'
>
> SET TRANSACTION ISOLATION LEVEL READ COMMITTED
>
> WHILE @i <= 1000
> BEGIN
> BEGIN TRANSACTION
>
> INSERT INTO dbo.t1 (
> contador,
> [id]
> )
> SELECT 'contador 1', MAX(id) + 1
> FROM dbo.t1 AS c
> WHERE contador = 'contador 1'
>
> COMMIT TRANSACTION
>
> SET @i = @i + 1
> END
>
> SET TRANSACTION ISOLATION LEVEL READ COMMITTED
> GO
>
> Session 2
>
> use tempdb
> go
>
> DECLARE @i INT
>
> SET @i = 1
>
> WAITFOR TIME '13:15:00'
>
> SET TRANSACTION ISOLATION LEVEL READ COMMITTED
>
> WHILE @i <= 1000
> BEGIN
> BEGIN TRANSACTION
>
> INSERT INTO dbo.t1 (
> contador,
> [id]
> )
> SELECT 'contador 1', MAX(id) + 1
> FROM dbo.t1 AS c
> WHERE contador = 'contador 1'
>
> COMMIT TRANSACTION
>
> SET @i = @i + 1
> END
>
> SET TRANSACTION ISOLATION LEVEL READ COMMITTED
> GO
>
> Si creen que el nivel READ COMMITTED no es suficiente, entonces cambienlo en
> ambas sessiones y vean los resultados.
>
>
> AMB
>
> "Gux (MVP)" wrote:
>
> > "Alfredo Novoa" wrote:
> >
> > > wrote:
> > >
> > > >Hola Antonio, a mi me parece correcto usar la tabla numeradora y los
> > > >bloqueos, a la larga es lo mas eficiente que podes hacer y seguro. Si haces
> > > >un Max sobre la tabla y esta tiene millones de registros no va a ser tan
> > > >rapido como hacer un update sobre la tabla numeradora de unos pocos
> > > >registros.
> > >
> > > ¿Por que?
> > >
> > > Para eso están los índices.
> >
> > Exacto.
> >
> > Si hay una consulta que usa funciones agregadas (mi libre traducción de
> > "aggregate" :-)) considerar el uso de un índice no-clustered. Estos índices
> > incluyen una fila con el valor de índice para cálculos agregados, por lo que
> > SQL Server no necesita acceder a la tabla real para hacer el cálculo de la
> > función.
> >
> >
> > Gustavo Larriera, Microsoft MVP
> > https://mvp.support.microsoft.com/p...o.larriera
> > Este mensaje se proporciona tal como es, sin garantías de ninguna clase.
> >
> >
> >
> > "Alfredo Novoa" wrote:
> >
> > >
> > > Hola Maxi,
> > >
> > > On Mon, 5 May 2008 10:53:28 -0300, "Maxi"
> > > wrote:
> > >
> > > >Hola Antonio, a mi me parece correcto usar la tabla numeradora y los
> > > >bloqueos, a la larga es lo mas eficiente que podes hacer y seguro. Si haces
> > > >un Max sobre la tabla y esta tiene millones de registros no va a ser tan
> > > >rapido como hacer un update sobre la tabla numeradora de unos pocos
> > > >registros.
> > >
> > > ¿Por que?
> > >
> > > Para eso están los índices.
> > >
> > > >aplicaciones por el costo a nivel performance que tiene eso, ademas de que
> > > >estarias haciendo un select y si dos hacen el mismo Max y no consideras
> > > >otras cosas a nivel bloqueo podria darles el mismo numero)
> > >
> > > ¿Que más habría que considerar?
> > >
> > >
> > >
> > > Saludos
> > >

Hola Alfredo,

Te embuyas a participar en la prueba del codigo que atache en mi post?


AMB

"Alfredo Novoa" wrote:

Hola Maxi,

On Mon, 5 May 2008 10:53:28 -0300, "Maxi"
wrote:

>Hola Antonio, a mi me parece correcto usar la tabla numeradora y los
>bloqueos, a la larga es lo mas eficiente que podes hacer y seguro. Si haces
>un Max sobre la tabla y esta tiene millones de registros no va a ser tan
>rapido como hacer un update sobre la tabla numeradora de unos pocos
>registros.

¿Por que?

Para eso están los índices.

>aplicaciones por el costo a nivel performance que tiene eso, ademas de que
>estarias haciendo un select y si dos hacen el mismo Max y no consideras
>otras cosas a nivel bloqueo podria darles el mismo numero)

¿Que más habría que considerar?



Saludos